mke2fs asks for input when formatting over a partition table

Here also is a screenshot of my chosen partitioning prior to beginning the install.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1361951

This is what Gparted shows had been done after a reboot.

BTW I just reformatted that partition to ext4 and ran a check via Gparted which showed the partition being OK, and smart status via GNOME Disk Utility shows the drive being OK.

Installation completes successfully if partitions are created prior to performing the installation, so I think it would be reasonable to set a milestone for Beta 2 or even Final as long as we mention this in the release notes.

I just tested this in a VM and manual partioning worked just fine.

Lance, can you post the ubiquity logs up?

I assume the attached logs are incomplete?

I filed the bug report using ubuntu-bug ubiquity while the installer still appeared to be trying to create the / partition. I could not find a way to kill the process before filing the bug report.

I've since wiped that failed install but I'll reproduce and see if I can find anything else.

Oddly I tried once last night and then once more this AM to reproduce this using the same DVD, same hardware, same installation steps, etc and couldn't reproduce so for now I suppose we can only wait and see if anyone has the same issue.

Hi, have had this same issue with the install procedure for 14.10 64-bit desktop (daily build 9 Oct 2014) freezing while reformating.

Followed the work around above (ie. reformating via gparted) and the install procedure has continued.

I have not found a reliable way to reproduce this - sometimes the reformatting proceeds as expected and sometimes it just never seems to proceed beyond displaying "Creating ext4 filesystem for / in partition #1 of SCSI2 (0,0,0) (sda) ...........". I did poke around a bit after the most recent freeze and someone might be able to see something at the end of the partman log:

parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 995
parted_server: Opening infifo
/lib/partman/commit.d/50format_ext3: Try to create file system for /var/lib/partman/devices/=dev=sda/374194831360-394593831423
/lib/partman/commit.d/50format_ext3: IN: PARTITION_INFO =dev=sda 374194831360-394593831423
parted_server: Read command: PARTITION_INFO
parted_server: command_partition_info()
parted_server: Opening outfifo
parted_server: command_partition_info: info for partition with id 374194831360-394593831423
parted_server: partition_with_id(374194831360-394593831423)
parted_server: OUT: OK

parted_server: command_partition_info: partition found
parted_server: OUT: 13 374194831360-394593831423 20399000064 logical ext4 /dev/sda13

parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 996
parted_server: Opening infifo
/bin/partman: IN: QUIT
parted_server: Read command: QUIT
parted_server: Quitting

With the 20141016 image the freeze appears to happen later in the process - actually just a graphical thing I think - see attached screenshot. So in order to quit the install and format the partition with Gparted instead of being able to click on Quit I just logged out and then logged back in. The end of the partman log looks similar:

parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 1921
parted_server: Opening infifo
/lib/partman/commit.d/50format_ext3: Try to create file system for /var/lib/partman/devices/=dev=sda/374596435968-394995436031
/lib/partman/commit.d/50format_ext3: IN: PARTITION_INFO =dev=sda 374596435968-394995436031
parted_server: Read command: PARTITION_INFO
parted_server: command_partition_info()
parted_server: Opening outfifo
parted_server: command_partition_info: info for partition with id 374596435968-394995436031
parted_server: partition_with_id(374596435968-394995436031)
parted_server: OUT: OK

parted_server: command_partition_info: partition found
parted_server: OUT: 13 374596435968-394995436031 20399000064 logical ext4 /dev/sda13

parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 1922
parted_server: Opening infifo

I could not produce this bug: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1361951

In my case, everything was just fine. However, I must say that in my case, there is only one Hard Drive, not 2 Hard Drives as in the bug report:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1361951/comments/2

So maybe the bug appears when there is 2 Hard Drives instead of 1 ?

Also, I installed it inside a Virtual Machine where there was a previous installation so I had to 'delete' the previous partitions, re-created new partitions (root and swap) and then installed the system. All was fine and worked like a charm.

In summary, everything is just fine and I couldn't produce the bug :)

Note: I added the above note to the ISO Tracker!

According to comment #9 one other person has encountered this, but it's not easily or consistently reproducible.

So far I've only been able to reproduce it if 3 criteria are met:

(1) The partition selected for change must contain a previously installed OS.
(2) The selected partition must be a logical partition.
(3) The selected partition must be in the double digits, eg; sda13 or sda15 - so sdx10 or higher.

But even then it is not 100% reproducible. I even tried setting up a blank physical hard drive with 1 primary partition, a logical swap, and enough (8) logical partitions to extend to sda13 but could not reproduce it.

I've checked the effected hard drive with fdisk -lu for any irregularities and found none.

So I think we can only wait and see what happens, then follow up during the 15.04 dev cycle. It is easily worked around by reformatting with Gparted if it is encountered so even once confirmed it's a low priority bug.

When I tried to re-produce this bug, I had a previously installed Ubuntu GNOME Utopic Unicorn RC and when I tried to do the manual installation, I removed/deleted the old partitions and created new ones. Then, installed and everything was just fine.

It seems this is a hard to re-produce bug and I was trying to find out whether it is fixed or not so we won't mentioned that on Ubuntu GNOME 14.10 Release Notes but since it affects only one user as of this very moment, I will keep it on the release notes and will not remove it. Only time will tell whether it affects more users or not.

Thanks!

Status changed to 'Confirmed' because the bug affects multiple users.

Is it only the installer that freezes or the whole system? Can you go to a command prompt and check with ps if mkfs or mke2fs are still running?

Only ubiquity appears to freeze so I should be able to try that. Don't hold your breath though because it's not consistently reproducible. Sometimes it works as expected and other times it freezes using the same exact partitions, same process, etc. It should prove to be a real challenge :^(

Neither ps or top really show anything of interest, see screenshot. But top does show ubiquity itself is running. I'll also attach logs from that attempt.

Here's the partman log from that last attempt which was BTW done with Ubuntu Utopic i386 final.

And var/log/installer/debug

And /installer/dm

And /version

Just thinking out loud :^)

I seem to recall some time ago being able to collect more detailed info if I started the live DVD with a boot parameter like "ubiquity-maybe" but I didn't keep notes and I'm unsure what the actual boot parameter is - would something like that help at all?

On 30/10/14 07:44, Erick Brunzell wrote:
> Just thinking out loud :^)
>
> I seem to recall some time ago being able to collect more detailed info
> if I started the live DVD with a boot parameter like "ubiquity-maybe"
> but I didn't keep notes and I'm unsure what the actual boot parameter is
> - would something like that help at all?
https://wiki.ubuntu.com/DebuggingUbiquity#Deeper_debugging_of_partman

It sounds like the mkfs works then and ubiquity freezes after for some reason. You might just double check with a full ps since it likely won't show up in top if it is hung.

I'm curious where to add those two additional lines in /etc/rsyslog.conf??? This is what it looks like out_of_box:

# /etc/rsyslog.conf Configuration file for rsyslog.
#
# For more information see
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html
#
# Default logging rules can be found in /etc/rsyslog.d/50-default.conf

#################
#### MODULES ####
#################

$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog # provides kernel logging support
#$ModLoad immark # provides --MARK-- message capability

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

# Enable non-kernel facility klog messages
$KLogPermitNonKernelFacility on

###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# Filter duplicated messages
$RepeatedMsgReduction on

#
# Set the default permissions for all log files.
#
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog

#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

I'm thinking just at the very end add:

# Added to collect additional debug info
$SystemLogRateLimitInterval 0
$SystemLogRateLimitBurst 0

Does that make sense?

Also I studied man ps a bit and after a bit of experimentation I'd think ps -aux should suffice to show all processes, does that seem right?

Thanks in advance.

Lance,
  it really doesnt matter where you add them, anywhere is fine.

`ps -aux` will be fine, though the '-' is somewhat redundant if you are going to be typing it a lot. `ps aux` should do

OK, finally got to this. I saved ps aux to white.text and I'll attach that as well as other applicable logs. I'll try to read them more closely when I'm in a more comfortable environment for my tired old eyes. You should probably know that the live USB booted directly to the install dialog after applying the debug-ubiquity boot parameter so I clicked on Quit to get to the live desktop before actually starting the installation process.

This is it for now, but since I used a live USB instead of a DVD any addirtional logs needed should hopefully be saved.

Looks like mkfs is still running:

root 22613 0.0 0.1 5088 2460 ? S 15:48 0:00 mkfs.ext4 /dev/sda10

Or at least it's still consuming memory.

I noticed this in the syslog:

Nov 1 15:48:08 ubuntu partman: mke2fs 1.42.10 (18-May-2014)
Nov 1 15:48:08 ubuntu partman: Found a dos partition table in /dev/sda10

It seems you have something that looks like a dos partition table in /dev/sda10. I'm guessing that mke2fs is printing that warning and then asking if you want to continue, and it never gets any input since it isn't actually connected to a tty. partman-ext3 probably needs to add a -F.

As a workaround, dd if=/dev/zero of=/dev/sda10 count=1 should clear it out.

Hi,

I had the same issue when I tried to install Kubuntu 14.10 over the old 14.04 installation. The workaround I found ist quite simple. I chose not the default file system (ext4) but btrfs for the "root partition" and the installation succeeded without any further issues. I guess, the issue is somehow related to ext4 and to the amount and structure of all partitions on the disk.

I had the same issue. It was clean installation as replacement of windows 7 on Lenovo T440s. First instalation cycle was ok but there was something bad with parttiions, I thought it was because I wanted to keep untouched partition for Intel Rapid Start Technology and recreated only some partitions but it was https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1387654 Next two installation cycles was frozen on partition creation (I completely removed and recreated partitions). Third cycle was ok.

Just happened (somewhat late in the process) with Ubuntu GNOME 20150318 i386. Can't just quit the installation at that point, must just restart live DVD, then format with Gparted, and then install.

I think I found the fix:

Installer was freezing during installation ( ubuntu-gnome 15.04 USB ).

I jumped over to a tty and checked the process list: $ ps -ef --forest

The process that was stalled was: mkfs.ext4 /dev/sde1

I kill -HUP it's pid, and then ran the command by hand: and I get a prompt:

$ sudo mkfs.ext4 /dev/sde1
mke2fs 1.42.12 (29-Aug-2014)
/dev/sde1 contains a ext4 file system
        last mounted on / on Wed May 6 06:10:18 2015
Proceed anyway? (y,n)

Looks like ext4 added a check that will need to disabled with a -F (?? is that safe ??) OR have an expect script handle the prompt.

tl;dr mke2fs is prompting to confirm if existing ext4 partition detected. Prompt is not handled, causing install to hang.

-Lance

Lance Rushing, you're my hero!

Can confirm this was a problem for me and following his steps fixed it. It appears that if any partitions exist on the disk at all this issues will come up (I happened to have had an msdos partition, which differs from the existing ext4 described by Lance).

I had a machine that was frozen by this for over 24 hours, and after I got sick of waiting it went through a few reboots before I luckly stumbled on this.

FYI this was installing 15.04

With the infos of Lance (#39) that bug can be "easily" fixed now ?

I still get it on daily 2015-10-09, it seems they forgot to add -F to the command so it will not prompt if you want to format or not... :-/ It should be quite easy to fix than...

Assigning to myself; fix is simple but it also needs to be upstreamed, so I'll do both.

Thank you very very much Mathieu !

This isn't a matter of just passing -F to mkfs. That message is a red herring, and only happens because it's being run interactively on the command-line.

I've tried a number of different alternatives, between ext2, ext3 and ext4, and I am completely unable to reproduce the bug. I expect it is an issue specific to a mix of the kernel and the specific device. Has anyone been able to get this to happen in a virtual machine?

I am able to reproduce this error when installing kubuntu using the non-manual option use entire disk and also use entire disk with lvm. I am using the 64 bit installation straight to disk.

The first related bug I found, which links to this bug is here https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1447600

Being able to reproduce once is unfortunate, but can you reproduce this every time you try to install? If so, have you tried to use the exact same steps on a different machine, or on a different disk, with the same results?

The issue that I have here is that while I appreciate that this issue happens in the wild; I'm completely unable to reproduce it with the various different formatting methods I tried -- I tried full disk, but this rewrites the partition tables so it doesn't matter even if you had data on a partition previously. I tried 'reinstall' (which I understand just formats the pre-existing partitions), and 'something else' (using a manual partitioning, I tried with ext2, ext3 and ext4, etc.).

Given that I'm unable to reproduce this with the various options above, the only thing I can think of by now is that there is some piece of the picture missing. Is the installer booted in EFI? Are you certain that the disks aren't nearly failing and that would explain the issues (especially if it sometimes works, sometimes doesn't, with the exact same process)?

If you can reproduce this *every single try* using a set of precise instructions, please comment here on the bug and set the bug back to New so we can look into these instructions and debug why they cause a failure.

For me it happen every time when I choose 'something else' because the ssd is already partitioned like that:

- sda1 Netrunner 14 x64 ext4 (root + home)
- sda2 Data ext4 (my data)
- sda3 Windows 7 ntfs
- sda4 Extended partition
   - sda5 Test ext4 (here is where I want to install the latest Ubuntu version - root + home)
   - sda6 Swap

The installation fail when Ubiquity try to format sda5 "/".
I hope that can help.

It has happened every time I tried to do a something else install on a real machine. Unfortunately it's impractical for me to reproduce this for you because I don't have an unlimited supply of real machines.

The original bug I wrote was closed as a duplicate of this one. But reproducing the problem was very straight forward.

I had a machine with 3 partitions - /, /home, and swap. I selected the something else install and told it to formate / and leave /home alone. Then it just sat there forever when I pressed continue. No actual formatting took place.

This is the bug I opened which just says what I said in #49 above. The first related bug I found, which links to this bug is here https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1447600

I changed the status back to New because this just occured performing a Vivid install for upgrade testing (see attached screenshot compilation). I'll try to add more info ASAP but I'd refer you to my comment #13 for now regarding the ability to reproduce this bug.

I'd have to amend that though because you can see from these newest screenshots that I was working on /dev/sda8 so rather than saying those criteria "must" exist I think it's more accurate to say that the freeze is "more likely" to occur if those criteria exist.

However the one criteria that absolutely must be met is that the existing partition must contain either an existing OS or data because once the installation is Quit and the partition is reformatted using Gparted the installation can be completed as desired.

I suspect that reports of ubiquity freezes during anything other than manual partitioning are not duplicates of this bug so new bug reports should be filed.

This freeze always displays "Creating ext4 filesystem for / in partition #1 of SCSI2 (0,0,0) (sda) ..........." either on the screen shown in these screenshots or on the later screen as shown in this screenshot:

https://launchpadlibrarian.net/183255225/Screenshot%20from%202014-08-26%2022%3A26%3A27.png

Sorry I haven't found a sure fire way to reproduce this bug. Sometimes it happens and other times it doesn't.

This problem is still happening right now in the 15.10 installer in a virtual machine. Exact same symptoms.

With this I guess we might have enough data to try some more things -- it may be that this is happening in a very specific case with extended partitions, or some different partition table I haven't tried yet. Marking Triaged/Medium.

During Wily final iso testing last night I experienced my first ever such freeze while reformatting a primary partition as shown in the attached side-by-side screenshots. I included the gnome-clock at the top so you can see it's an actual freeze, the first shot was probably 10 to 15 minutes into the process and the next is more than 30 minutes later.

Just to give an idea of how random this freeze may be, I've performed that identical test on the same partition dozens of times in the past and this is the first time it's frozen with a primary partition like that. It's much more likely to occur on a logical partition in the double digits.

I sas re-installing a 15.04 x64 ISO image earlier and I had the above freezing problem with ubiquity.
I was reusing my existing partition structure, keeping the /home partition but formatting the others.

I found that removing a /var partition and formatting / and /usr partitions allowed the installer to move to the copying files sections of the install.

It's odd that it seems so infrequent for others. It happens every time for me. I specifically set up my partitions into / and /home so that I wouldn't have to wipe /home every time, but this has resulted in me never being able to install using the Something Else method.

I was having the same issue with 15.10 install media but resolved it by booting into the live session, opening a terminal, using fdisk to create a new GPT table, making one giant partition, formatting it, then proceeding with install. Install went off without a hitch.

Any news on this bug ?
The next version is a LTS, that have to be fixed.

Reproduction is pretty simple: use fdisk or parted to create a partition table in the partition, then mke2fs whinges that the partition table is there. It needs the -F switch to not do that.

No, it was unclear which precise set of circumstances caused mke2fs to not be happy. I tried a bunch of different alternatives from comments here when I said I could not reproduce it, that's because I hadn't hit the right set of circumstances: it's definitely not just randomly using fdisk or parted to create a partition table, people don't go around doing that themselves: they were hitting an issue related to the general partitioning scheme, either as done by us or as done by Windows, or even by something else (and in fact, is probably simply because of how the extended partitions work).

Still, regardless of the reason, there was never a question that adding -F would work; I just like to really understand what is happening before applying fixes rather than blindly doing something and hoping it will work.

This bug was fixed in the package partman-ext3 - 84ubuntu2

---------------
partman-ext3 (84ubuntu2) xenial; urgency=medium

  * Always force formatting the filesystem, unless it's already mounted or
    otherwise appears to be in use. (LP: #1361951)

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 12 Nov 2015 09:24:04 -0500

Thank you a lot Mathieu !
If I may it will be awesome if you can take a look at this one ;-)

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1218702

It might also be identifying a FAT boot sector as an MBR.

I'm not sure if this is related, but...

I get:

“Creating ext4 system for /home in partition #1 of Encrypted volume (sda3_crypt)...”

and then my installation hangs forever,

when I:

1) create partitions using gparted (onto a non-UEFI system with a gpt formatted drive) prior to attempting to install Ubuntu 15.10 or 16.04;
2) then use the “something else” option presented by the Ubuntu 15.10 or 16.04 installer to create LUKS-encrypted volumes on sda2 and sda3; and
3) then attempt to install boot (/boot) into non-encrypted sda1, root (/) into LUKS-encrypted sda2, and home (/home) into LUKS-encrypted sda3.

The above is reproducible 100% of the time on every computer that I own as well as on virtualbox and QEMU/KVM.

However, my installation completes just fine when I:

1) create partitions using gparted (onto a non-UEFI system with a gpt formatted drive) prior to attempting to install Ubuntu 15.10 or 16.04;
2) then use the “something else” option presented by the Ubuntu 15.10 or 16.04 installer to create one LUKS-encrypted volume on sda2; and
3) then install boot (/boot) into non-encrypted sda1, and root (/) into LUKS-encrypted sda2.

That is, at least for me, attempting to install into home (/home) into a separate LUKS-encrypted volume results in the error.

NOTE: In neither of the above situations do I attempt to create a swap volume. Rather, I skip creating a swap partition in both, otherwise installation will hang for another reason. In the second of the two situations, after the initial installation has completed, I either create a swap file in sda2 or create a separate LUKS-encrypted swap volume.

Please see Bug #1523194 for more details.

Launchpad Janitor (janitor) wrote on 2015-11-11 that

"This bug was fixed in the package partman-ext3 - 84ubuntu2"

If the bug was fixed, then how am I still able to reproduce it everytime I try to install the software on my laptop?

I have tried installing over half a dozen times. I am currently into my 36th hour waiting for this particular and latest install to finish. If the bug has been fixed, why is it still included in releases offered for download?

The only release I have found that works correctly is 16.04 alpha.

It was fixed on or about November 12, 2015 so prior images will still be affected. That would include Wily which was released in October and also 14.04.3.

It's fixed in partman-ext3 - 84ubuntu2 and as you can see in the link, it's only in Ubuntu 16.04 (Xenial)

https://launchpad.net/ubuntu/+source/partman-ext3

That said it will be great if the fix can be backported, at least for Ubuntu 14.04.3

@ Mathieu Trudel-Lapierre, would it be possible to upgrade ubiquity in the Trusty dailies so we could get the upgraded partman-ext3? It may not be as easy as it sounds because there have been numerous changes besides this that may not be appropriate for use with Trusty,.

Just FYI to all interested the change dropped here:

ubiquity (2.21.39) xenial; urgency=medium

  * Automatic update of included source packages: partman-efi 62ubuntu3,
    partman-ext3 84ubuntu2, partman-xfs 57, preseed 1.64ubuntu4, apt-setup
    1:0.104ubuntu1, flash-kernel 3.0~rc.4ubuntu57, hw-detect 1.114ubuntu1,
    netcfg 1.135ubuntu1, partman-btrfs 18ubuntu1, preseed 1.68ubuntu1,
    user-setup 1.63ubuntu1, base-installer 1.158ubuntu1, grub-installer
    1.128ubuntu1, partman-target 98ubuntu1, yaboot-installer 1.1.36ubuntu1,
    choose-mirror 2.65ubuntu2.
  * Add support for disabling Secure Boot in prepare screen.

 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 21 Dec 2015 16:41:39 -0500

partman-basicfilesystems needs the same fix: it runs mke2fs to format the ext2 /boot partition when you choose to do an encrypted install.

I confirm the issu when trying to install 16.04 LTS from a pendrive.
I chose Something Else and tried to create an ext2 boot partition, an ext4 system partition, a swap partition and a home partition.
It hangs while creating ext2 file system, as described by Eric Brunzell.
Tried for three times, same issue.
Then used GParted to manually create the partitions.
When chose Something Else, I only had to modify the partitions to assign mount points.
This time it worked.

Status changed to 'Confirmed' because the bug affects multiple users.

Please:

1. Report to (http://bugs.debian.org)
2. Paste the new report link here.
3. Set this bug status for "partman-basicfilesystems" back to "confirmed".

Thank you.

Debian has already fixed it in version 123, please merge.

I think you have the wrong email address.

On Wed, 31 Aug 2016 at 13:25 Phillip Susi <email address hidden> wrote:

> Debian has already fixed it in version 123, please merge.
>
>
> ** Changed in: partman-basicfilesystems (Ubuntu)
> Status: Incomplete => Triaged
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1447600).
> https://bugs.launchpad.net/bugs/1361951
>
> Title:
> mke2fs asks for input when formatting over a partition table
>
> Status in partman-basicfilesystems package in Ubuntu:
> Triaged
> Status in partman-ext3 package in Ubuntu:
> Fix Released
>
> Bug description:
> I'm testing an Ubuntu GNOME Utopic 20140826 i386 image and after
> selecting Something else and creating two partitions on a blank 80 GB
> (primary / about 77500mb and logical swap about 2500mb) shortly after
> the installation begins it freezes with the bottom of the window
> saying, "Creating ext4 filesystem for / in partition #1 of SCSI2
> (0,0,0) (sda) ...........".
>
> I've repeated this twice just in case the first attempt was a fluke,
> and the first time I waited well over an hour. I'm filing this report
> with the installer seemingly still attempting to run. I'd gladly
> repeat the test choosing to kill the installation before filing if I
> knew how.
>
> I'm attaching an actual screenshot of what the screen displays while
> frozen.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 14.10
> Package: ubiquity 2.19.2
> ProcVersionSignature: Ubuntu 3.16.0-10.15-generic 3.16.1
> Uname: Linux 3.16.0-10-generic i686
> ApportVersion: 2.14.6-0ubuntu2
> Architecture: i386
> CasperVersion: 1.343
> CurrentDesktop: GNOME
> Date: Tue Aug 26 22:27:21 2014
> InstallCmdLine: file=/cdrom/preseed/ubuntu-gnome.seed boot=casper
> initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity
> LiveMediaBuild: Ubuntu-GNOME 14.10 "Utopic Unicorn" - Alpha i386
> (20140826)
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: ubiquity
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/partman-basicfilesystems/+bug/1361951/+subscriptions
>
--

Sent from my mobile: please excuse brevity and typos

Found same issue while trying to install debian.
On TTY 4 (ctr+Alt+F4) i found:

'partman: Found a dos partition table on /devb/sda8'. Debian is installed via UNetBootIn from USB

It used mke2fs 1.42.12 (29-aug-2014)

Is it fixed now ?