Installer crashed when trying to partition 4k/4k sector hard disks

I'm unlikely to be able to debug this without a traceback. Does the same crash by any chance happen in a desktop installation? If so then it might be possible to get a core dump; if we're extra-lucky apport might be able to process it, but even without that the core dump or /var/crash/ file would probably be useful.

Thanks, Colin. I'll try out a desktop installation and see if I'm able to get anything more useful for you.

Attaching the crash file from /var/crash/ . The desktop installation failed in the same way (i.e. installer appeared to get 'stuck' when trying to create filesystems on 4k/4k disks).

#0 __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1517
No locals.
#1 0x00007fd654bfd197 in memcpy (__len=3108864, __src=0x64ee40, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:52
No locals.
#2 linux_write (dev=0x649380, buffer=0x64ee40, start=288, count=<optimized out>) at ../../libparted/arch/linux.c:1927
        arch_specific = 0x649dd0
        ex_status = <optimized out>
        diobuf = 0x7fd653476000
        diobuf_start = <optimized out>
        __PRETTY_FUNCTION__ = "linux_write"
        write_length = 3108864
#3 0x00007fd654bfab60 in ped_geometry_write (geom=<optimized out>, buffer=<optimized out>, offset=32, count=<optimized out>) at ../../libparted/cs/geom.c:392
        exception_status = <optimized out>
        real_start = <optimized out>
        __PRETTY_FUNCTION__ = "ped_geometry_write"
#4 0x00007fd654c0c3a9 in fat_table_write (ft=ft@entry=0x649d20, fs=fs@entry=0x64e440, table_num=table_num@entry=0) at ../../../../libparted/fs/fat/table.c:159
        fs_info = <optimized out>
        __PRETTY_FUNCTION__ = "fat_table_write"
#5 0x00007fd654c0c432 in fat_table_write_all (ft=0x649d20, fs=fs@entry=0x64e440) at ../../../../libparted/fs/fat/table.c:177
        fs_info = 0x64a540
        i = <optimized out>
#6 0x00007fd654c0e9cf in fat_create (geom=0x64b2b8, fat_type=<optimized out>, timer=<optimized out>) at ../../../../libparted/fs/fat/fat.c:393
        fs = 0x64e440
        fs_info = 0x64a540
        table_size = <optimized out>
#7 0x00007fd654bf4f92 in ped_file_system_create (geom=0x64b2b8, type=0x7fd654e5bb40 <fat32_type>, timer=0x64e400) at ../../libparted/filesys.c:534
        fs = <optimized out>
        __PRETTY_FUNCTION__ = "ped_file_system_create"
#8 0x0000000000403983 in ?? ()
No symbol table info available.
#9 0x000000000040ba85 in ?? ()
No symbol table info available.
#10 0x000000000040f3b7 in ?? ()
No symbol table info available.
#11 0x0000000000402b71 in ?? ()
No symbol table info available.
#12 0x00007fd65484676d in __libc_start_main (main=0x402990, argc=1, ubp_av=0x7fffb0cbc8a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffb0cbc898) at libc-start.c:226
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -8111426171978694122, 4205428, 140736159533216, 0, 0, 8111279010564489750, 8125274207676744214}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x40f5c0,
              0x7fffb0cbc8a8}, data = {prev = 0x0, cleanup = 0x0, canceltype = 4257216}}}
        not_first_call = <optimized out>
#13 0x0000000000402b9d in ?? ()
No symbol table info available.
#14 0x00007fffb0cbc898 in ?? ()
No symbol table info available.
#15 0x000000000000001c in ?? ()
No symbol table info available.
#16 0x0000000000000001 in ?? ()
No symbol table info available.
#17 0x00007fffb0cbdc6b in ?? ()
No symbol table info available.
#18 0x0000000000000000 in ?? ()
No symbol table info available.

Ah. The problem is that libparted doesn't have 4K sector support for FAT; and isn't going to get it because most filesystem creation code has been removed upstream. We need to use something like mkfs.msdos instead.

This is also going to require creating a udeb from dosfstools, so that mkfs.msdos is available.

This bug was fixed in the package dosfstools - 3.0.13-1ubuntu2

---------------
dosfstools (3.0.13-1ubuntu2) raring; urgency=low

  * Add dosfstools-udeb package, mainly so that we can use mkdosfs in d-i
    instead of deprecated and semi-broken libparted code (LP: #1065281).
 -- Colin Watson <email address hidden> Thu, 17 Jan 2013 20:09:57 +0000

This bug was fixed in the package partman-basicfilesystems - 76ubuntu2

---------------
partman-basicfilesystems (76ubuntu2) raring; urgency=low

  * Use mkdosfs to create FAT filesystems, since libparted cannot handle
    doing that on non-512-sector disks (LP: #1065281).
 -- Colin Watson <email address hidden> Thu, 17 Jan 2013 23:05:24 +0000

Hello Kent, or anyone else affected,

Accepted dosfstools into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/dosfstools/3.0.12-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Kent, or anyone else affected,

Accepted dosfstools into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/dosfstools/3.0.13-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Tested with today's 13.04 server image which contained the following:

/pool/main/d/dosfstools/dosfstools_3.0.13-1ubuntu2_amd64.deb
/pool/main/p/partman-basicfilesystems/partman-basicfilesystems_76ubuntu2_all.udeb

We ended up with the same symptoms and an identical segfault:

parted_server[14042]: segfault at 1f59000 ip 00007fde7758bea7 sp 00007ff564bf5c0 error 4 in libparted.so.0.0.1[7fde77575000+6400]

I'll try and grab another coredump. Do we need the actual udeb in the build for this to work?

Turns out the image is getting respun later today to add the missing udeb. I'll try again this afternoon.

You need the actual udeb. That said, I question whether that's actually
an identical segfault because the code path that triggered the previous
one is no longer present.

I just tested the re-spun image 20130118.1 and verified that the dosfsutils udeb is getting loaded.

Unfortunately, the installer still failed in the same spot with the identical segfault message.

Attaching dmesg, partman, and syslog logs.

Based on Colin's comments, the latest crash (although it looks the same) most likely isn't identical since we are now seeing some additional messages logged prior to the crash that we didn't see before (sdb is the 4k sector disk in question):

Jan 18 17:07:30 kernel: [ 354.999903] FAT-fs (sdb1): logical sector size too small for device (logical sector size = 512)
Jan 18 17:07:30 kernel: [ 355.000367] isofs_fill_super: bread failed, dev=sdb1, iso_blknum=17, block=-2147483648
Jan 18 17:07:30 kernel: [ 355.015595] isofs_fill_super: bread failed, dev=sdb2, iso_blknum=17, block=-2147483648
Jan 18 17:07:30 kernel: [ 355.030905] isofs_fill_super: bread failed, dev=sdb3, iso_blknum=17, block=-2147483648
Jan 18 17:07:30 kernel: [ 355.072466] FAT-fs (sdb1): logical sector size too small for device (logical sector size = 512)
Jan 18 17:07:30 kernel: [ 355.072966] isofs_fill_super: bread failed, dev=sdb1, iso_blknum=17, block=-2147483648
Jan 18 17:07:30 kernel: [ 355.088324] isofs_fill_super: bread failed, dev=sdb2, iso_blknum=17, block=-2147483648
Jan 18 17:07:30 kernel: [ 355.102969] isofs_fill_super: bread failed, dev=sdb3, iso_blknum=17, block=-2147483648
Jan 18 17:07:35 kernel: [ 360.214278] Adding 134059004k swap on /dev/sdb3. Priority:-1 extents:1 across:134059004k

Made some on-the-fly changes to 50format_basicfilesystems per Colin's request.

http://paste.ubuntu.com/1546211/

Attaching new syslog

This bug was fixed in the package partman-efi - 25ubuntu4

---------------
partman-efi (25ubuntu4) raring; urgency=low

  * Depend on dosfstools-udeb for the changes in 25ubuntu3.
 -- Colin Watson <email address hidden> Fri, 18 Jan 2013 18:54:03 +0000

Much better progress with the image from today (2012.01.21). The installer will no longer crash / hang when trying to partition an Advanced Format disk in EFI mode. The installation itself completed all the way to the end.

Another problem exists, however...

The problem now is that, upon reboot, we can't boot the operating system. There's no option in the EFI boot menu to boot Ubuntu. I thought that maybe we'd be able to add the entry in by hand (at least) to get the OS booted, however, there are no files on the disk to point the boot menu to.

Attaching dmesg, syslog, and partman. These were captured at the end of the installation, but right before rebooting for the first time.

Attaching dmesg, syslog, and partman. These were captured at the end of the installation, but right before rebooting for the first time.

Could I have a raw dump of the first megabyte of the disk, extracted using dd, as well as a raw dump of the first megabyte of /dev/sdb1? It looks as though perhaps libparted and efibootmgr are disagreeing over what makes a valid GPT, and I'm going to need to walk through it by hand.

Attaching dumps. First MB of sdb, followed by first MB of sdb1

Ah, I've tracked this down to efibootmgr not supporting 4K-logical-sector disks. Fortunately, Fedora has a patch for this, which I'll backport.

Perhaps somebody at Dell could nudge Matt Domsch and/or Stuart Hayes about applying this patch, or similar, and issuing a new upstream release? You can find it here:

  http://pkgs.fedoraproject.org/cgit/efibootmgr.git/tree/efibootmgr-0.5.4-support-4k-sectors.patch

This bug was fixed in the package efibootmgr - 0.5.4-3ubuntu2

---------------
efibootmgr (0.5.4-3ubuntu2) raring; urgency=low

  * Apply Fedora patch (efibootmgr-0.5.4-support-4k-sectors.patch) to
    support non-512-byte logical sectors (LP: #1065281).
 -- Colin Watson <email address hidden> Wed, 23 Jan 2013 12:41:28 +0000

Colin: I've subscribed Matt to this bug and will email him requesting that he incorporate that in a new upstream release.

Jordan Hargrave now owns efibootmgr. I've asked him about incorporating this patch.

Kent: Could you please retry with the raring server image I built this afternoon (20130123.1)? I believe it should be better now.

The patches have already been in upstream efibootmgr for 2 years.
http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=efibootmgr.git;a=summary

I could cut a new release though.

@ Colin,

Tested the 20130123.1 build. I got a little bit farther with this one, but, still couldn't boot the OS.

Yesterday, there wasn't even an "Ubuntu" boot entry in the EFI boot menu.

Today, I'm able to see the "ubuntu" entry in the menu, but, selecting it brings me to a "Boot Failed" screen.

I'll get another dump of the disk info first thing in the morning and send it over.

Jordan: Thanks, that would be helpful.

Kent: Sigh, not again. In that case, in addition to the previous dumps,
I'd like the installer logs (syslog and partman) again, and a full copy
of the EFI System Partition. Thanks.

Attaching the logs and 1M dumps for sdb and sdb1.

The efi system partition copy is here, as it turned out to be rather large:

http://people.canonical.com/~kentb/efiboot.img.bz2

Thanks - I'll investigate that. I should have asked earlier, but could I also get a screenshot of the "Boot Failed" screen? I'd like to get a sense of which layer in the stack is emitting it.

For 13.10, I confirmed that the new grub2 packages allow us to fully boot into the operating system (yay!!).

This is true for both LVM and non-LVM auto-partitioning options.

Thanks for all of your help, Colin.

I'll also test what fixes are present for 12.04.

I tried today's build of 12.04, which seemed to have the two fixes committed yesterday.

The installer completed OK, but, it appears that the EFI boot entry somehow didn't get set..In other words, the server couldn't find anything to boot from and, upon further inspection, there was no 'ubuntu' entry available in the EFI boot menu.

I ran out of time today to dive into this, but, I'll try again on Monday and gather up logs if the problem persists.

It probably isn't worth retesting 12.04 until I've backported the grub2
change, at least.

Hello Kent, or anyone else affected,

Accepted grub2 into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/grub2/1.99-21ubuntu3.11 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

grub2-signed (1.20) saucy; urgency=low

  * Rebuild against grub-efi-amd64 2.00-19ubuntu1.

 -- Colin Watson <email address hidden> Thu, 19 Sep 2013 11:01:28 +0100

Tested today's 12.04 builds that contain what appears to be the bulk of the grub2 version 1.99-21ubuntu3.11 packages.

Install completes without crashing, but, I still end up with no 'ubuntu' entry in the EFI boot menu. I can navigate to the grubx64.efi file on the hard disk via EFI boot menu, though and attempt to boot from file that way.

I'm then dropped to a grub command prompt and from there I can boot the OS.

This particular partitioning scheme (Use entire disk without LVM) left me with a 5GB EFI system partition and a 137GB Swap partition once the OS booted up.

Looks like there are some other fixes being queued up so I'll hold off further testing until I see those go out.

I tried today's build (Oct 4th) and realized that partman-base hasn't had its fixes ported to precise yet (whoops), which means the 1TB disk is still only showing up as 125GB. The efibootmgr stuff also needs to be ported (I think).

I'll wait until those fixes get pushed into 12.04 before continuing further testing.

This bug was fixed in the package partman-auto - 101ubuntu2.1

---------------
partman-auto (101ubuntu2.1) precise; urgency=low

  * Bump EFI partition size range to 512-1024MB, in line with Debian; 100MB
    is too small on a disk with 4KiB logical sectors (LP: #1065281).
 -- Colin Watson <email address hidden> Thu, 12 Sep 2013 13:58:05 +0100

Hello Kent, or anyone else affected,

Accepted partman-auto into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/partman-auto/101ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Wait, what? Why does it need to be 512 MB now? I already thought that 100 MB was absurdly large.

Hello Kent, or anyone else affected,

Accepted partman-base into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/partman-base/153ubuntu6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Note that this is still missing the last currently-known piece, namely efibootmgr. I'll review James' branch for that by tomorrow at the latest.

Hello Kent, or anyone else affected,

Accepted efibootmgr into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/efibootmgr/0.5.4-2ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Tomorrow's precise daily build should finally be worth testing for this.

Collin, rather than waste more disk space why not fix the real bug in mkdosfs ( in that it fails to switch to fat16 at < 133 MB )?

Please note that my first name contains only one "l", not two.

I don't consider it important - 4k/4k sector hard disks used on UEFI
systems are not going to be so uncomfortably tiny that it makes much of
a difference in practice, and it's much more important to get this
high-priority bug fixed so that OEMs can deliver systems that actually
*boot* properly rather than going round again on the details. If you
want to get into this could you please take it to a separate bug?

Oh, so the size increase only applies for 4k drives? I suppose that's ok then, I was just worried that half a gig was significant on a 16 gb ssd.

Tried with today's Precise Server Build.

The good:
1) No installer crashes.
2) Disk is prooperly detected as 1TB in size
3) I have an ubuntu entry to boot from in the EFI boot menu

The bad:
Dropped to a grub prompt at boot time. I can, however, boot the OS manually by providing grub with the path to the vmlinuz and initrd on the disk

Attaching the full set of logs from /var/log/installer

Link to logs: https://bugs.launchpad.net/ubuntu/+source/partman-basicfilesystems/+bug/1065281/+attachment/3912823/+files/installer-logs-11-19-13.tgz

Hello Kent, or anyone else affected,

Accepted ubiquity into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/ubiquity/2.10.28 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Aha, got it: the efidisk module is working but the FAT file system support isn't quite right, so it's just the EFI System Partition that GRUB has trouble reading. The missing commit is this one, which is in 2.00 thus explaining why this works in more recent releases:

  http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=daa59f47f6818d2a2c90526be5b2b38a11770dc1

Doing a full boot loader test is awkward due to the involvement of a signed image, but I've confirmed the bug with grub-fstest and grub-mount, and built versions of those tools with that patch which can successfully read all the files under /EFI/ubuntu/. I'll prepare a backport.

Hello Kent, or anyone else affected,

Accepted grub2 into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/grub2/1.99-21ubuntu3.14 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Kent, or anyone else affected,

Accepted grub2-signed into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/grub2-signed/1.9~ubuntu12.04.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

With today's Precise Server image I can now boot the Operating System!

I do, however, see one seemingly minor error pop up as soon as I select Ubuntu in the gru menu:

error: efidisk write error

Press any key to continue....

The system will boot up after about 10 seconds.

I'm wondering if it is similar to what I filed against 14.04. Error message is a little different, but, the behavior is the same (i.e. the system will boot by itself approximately 10 seconds after the error message pops up):

https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1253443

We may need to deal with this at some point, but it can safely be
ignored for now; any writes will just be for the environment block,
which isn't critical functionality (and is already documented as missing
in some profiles).

This bug was fixed in the package partman-efi - 25ubuntu1.2

---------------
partman-efi (25ubuntu1.2) precise; urgency=low

  * Pass "-s 1" to mkdosfs if the logical sector size is not equal to 512
    bytes, since mkdosfs has trouble with cluster calculations otherwise
    (LP: #1065281).
 -- Colin Watson <email address hidden> Wed, 18 Sep 2013 14:00:33 +0100

The verification of the Stable Release Update for partman-efi has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package partman-base - 153ubuntu6

---------------
partman-base (153ubuntu6) precise-proposed; urgency=low

  * Use the device's logical sector size throughout rather than
    PED_SECTOR_SIZE_DEFAULT (LP: #1065281).
 -- James M Leddy <email address hidden> Fri, 08 Nov 2013 17:57:33 +0000

This bug was fixed in the package efibootmgr - 0.5.4-2ubuntu1.1

---------------
efibootmgr (0.5.4-2ubuntu1.1) precise; urgency=low

  * Apply Fedora patch (efibootmgr-0.5.4-support-4k-sectors.patch) to
    support non-512-byte logical sectors (LP: #1065281).
 -- James M Leddy <email address hidden> Wed, 13 Nov 2013 15:59:21 +0000

This bug was fixed in the package ubiquity - 2.10.28

---------------
ubiquity (2.10.28) precise; urgency=low

  * Automatic update of included source packages: partman-
    basicfilesystems 71ubuntu3.4. (LP: #978032)

ubiquity (2.10.27) precise; urgency=low

  * Automatic update of included source packages: netcfg 1.68ubuntu14.1
    (LP: #901700), partman-auto 101ubuntu2.2 (LP: #1197766, #1065281),
    partman-base 153ubuntu6 (LP: #1065281), partman-basicfilesystems
    71ubuntu3.3 (LP: #978032, #1215458), partman-btrfs 8ubuntu1.1 (LP:
    #978032), partman-efi 25ubuntu1.2 (LP: #1065281), partman-ext3
    67ubuntu1.1 (LP: #978032).
 -- Dmitrijs Ledkovs <email address hidden> Tue, 03 Dec 2013 18:04:05 +0000

This bug was fixed in the package grub2 - 1.99-21ubuntu3.14

---------------
grub2 (1.99-21ubuntu3.14) precise; urgency=low

  * Handle FAT filesystems on non-512B disks (LP: #1065281).
  * Probe FusionIO devices (LP: #1237519).
  * On Linux, read partition start offsets from sysfs if possible
    (LP: #1237519).

grub2 (1.99-21ubuntu3.13) precise; urgency=low

  * Revamp hidden timeout handling by adding a new timeout_style environment
    variable and a corresponding GRUB_TIMEOUT_STYLE configuration key for
    grub-mkconfig. This controls hidden-timeout handling more simply than
    the previous arrangements, and pressing any hotkeys associated with menu
    entries during the hidden timeout will now boot the corresponding menu
    entry immediately (LP: #1178618). As part of merging this, radically
    simplify /etc/grub.d/30_os-prober; if it finds other OSes it can now
    just set timeout_style=menu and make sure the timeout is non-zero.
  * Fix mismerge of GRUB_RECOVERY_TITLE option in 1.99-21ubuntu3.12.

grub2 (1.99-21ubuntu3.12) precise; urgency=low

  * debian/build-efi-images: Where possible, make use of the device path
    derived from the EFI Loaded Image Protocol to compute the prefix
    (LP: #1097570).
  * Add GRUB_RECOVERY_TITLE option, to allow the controversial "recovery
    mode" text to be customised (LP: #1240360).
 -- Colin Watson <email address hidden> Thu, 05 Dec 2013 16:53:48 +0000

This bug was fixed in the package grub2-signed - 1.9~ubuntu12.04.6

---------------
grub2-signed (1.9~ubuntu12.04.6) precise; urgency=low

  * Build against grub-efi-amd64 1.99-21ubuntu3.14 (LP: #1065281).
 -- Colin Watson <email address hidden> Fri, 06 Dec 2013 09:54:51 +0000

ubiquity got the necessary included source packages in trusty some time ago.

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".