auto-resize install renders previous system with separate /boot unbootable

Bug #462961 reported by Martin Pitt
58
This bug affects 12 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Fix Released
Medium
Loïc Minier
Karmic
Fix Released
Medium
Loïc Minier

Bug Description

Binary package hint: ubiquity

During Karmic final install testing, I first did a manual partitioning with a 200 MB /boot (/dev/vda1) and a ~ 5 GB / (/dev/vda5), no swap. In the next round, I tried the auto-resize mode, which resized /dev/vda5 to 2.7 GB, and created a new /dev/vda6 for / and /dev/vda7 for swap.

/dev/vda1 * 1 24 192748+ 83 Linux
/dev/vda2 25 729 5662912+ 5 Extended
/dev/vda5 25 364 2731018+ 83 Linux
/dev/vda6 365 705 2739051 83 Linux
/dev/vda7 706 729 192748+ 82 Linux swap / Solaris

The newly installed system boots fine, but when I try to boot the previous one in grub2, it just fails with "error: You need to load the kernel first".

I think this is due to "search" and "linux" lines having the same UUID (that of the old root partition, 3534fc...). search should instead have the UUID of the old /boot partition (4b294e...). When I manually walk though the commands in grub, it says "error: file not found" in the "linux ..." step.

ProblemType: Bug
Architecture: i386
Date: Wed Oct 28 23:32:02 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Package: ubiquity (not installed)
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: ubiquity
Uname: Linux 2.6.31-14-generic i686
XsessionErrors:
 (gnome-settings-daemon:1224): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:1224): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:1282): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:1303): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

Related branches

Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :

The original grub.cfg from the old install was correct (/boot/grub/grub.cfg on vda5):

### BEGIN /etc/grub.d/10_linux ###
menuentry "Ubuntu, Linux 2.6.31-14-generic" {
        recordfail=1
        if [ -n ${have_grubenv} ]; then save_env recordfail; fi
 set quiet=1
 insmod ext2
 set root=(hd0,1)
 search --no-floppy --fs-uuid --set 4b294ec9-0fb3-44bd-bc61-7f35ccb52534
 linux /vmlinuz-2.6.31-14-generic root=UUID=3534fcb7-8b25-4b97-8643-59b566d177d7 ro quiet splash
 initrd /initrd.img-2.6.31-14-generic
}

However, the one from the new install put the wrong UUID into the search line:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "Ubuntu, Linux 2.6.31-14-generic (on /dev/vda5)" {
        insmod ext2
        set root=(hd0,5)
        search --no-floppy --fs-uuid --set 3534fcb7-8b25-4b97-8643-59b566d177d7
        linux /boot/vmlinuz-2.6.31-14-generic root=UUID=3534fcb7-8b25-4b97-8643-59b566d177d7 ro quiet splash
        initrd /boot/initrd.img-2.6.31-14-generic

Revision history for this message
Martin Pitt (pitti) wrote :
Revision history for this message
Martin Pitt (pitti) wrote :

Confirmed that after changing root= to (hd0,1), the UUID in search line, and dropping the "/boot" prefix in linux/initrd in the grub editor, it boots the old system.

affects: ubiquity (Ubuntu) → os-prober (Ubuntu)
Revision history for this message
Loïc Minier (lool) wrote :

I'll try to reproduce then try this patch which should use the /boot device reported by os-prober to generate the new grub menuentry instead of the root device.

Revision history for this message
Loïc Minier (lool) wrote :

I can reproduce the issue and the proposed fix only fixes set root + search by UUID parts, not pathnames.

affects: os-prober (Ubuntu) → grub2 (Ubuntu)
Changed in grub2 (Ubuntu):
status: New → Triaged
Revision history for this message
Loïc Minier (lool) wrote :

I have a fix for /boot as well

Changed in grub2 (Ubuntu):
importance: Undecided → Medium
assignee: nobody → Loïc Minier (lool)
milestone: none → karmic-updates
Revision history for this message
Loïc Minier (lool) wrote :
Loïc Minier (lool)
Changed in grub2 (Ubuntu Karmic):
status: Triaged → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote :

Thanks Loic! I fixed up the patch to apply, and uploaded to https://launchpad.net/~pitti/+archive/ppa for easier testing. I installed that on my test system, called update-grub2, and now grub.cfg is correct and I can boot the old system.

grub-common's postinst should probably call update-grub2 on updates to this version.

Revision history for this message
Colin Watson (cjwatson) wrote :

grub-pc always calls update-grub on update.

Revision history for this message
Loïc Minier (lool) wrote :

I pushed a fixed package to -proposed and my PPA and tested it from there with the /boot on separate partition case; would like to test the other case of the old system having no separate /boot partition when it's in -proposed.

Revision history for this message
Martin Pitt (pitti) wrote :

Accepted grub2 into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 1.97~beta4-1ubuntu4

---------------
grub2 (1.97~beta4-1ubuntu4) karmic-proposed; urgency=low

  * New patch, 969_os_prober_separate_boot, fixes wrong kernel/initrd
    pathnames and wrong partition UUID/GRUB path when generating menuentries
    from os-prober output of a detected system with a separate /boot; thanks
    Colin Watson; LP: #462961.

 -- Loic Minier <email address hidden> Thu, 29 Oct 2009 02:30:35 +0000

Changed in grub2 (Ubuntu Karmic):
status: Fix Committed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

Copied karmic-proposed to lucid.

Changed in grub2 (Ubuntu Karmic):
status: Fix Released → Fix Committed
Changed in grub2 (Ubuntu):
milestone: karmic-updates → none
status: Fix Committed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

I restored my test install from the original report to the karmic final packages and confirmed that this breaks grub.cfg, and the previous installation with separate /boot does not boot.

Now I upgraded to the proposed packages, and confirm that both installations now boot.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 1.97~beta4-1ubuntu4

---------------
grub2 (1.97~beta4-1ubuntu4) karmic-proposed; urgency=low

  * New patch, 969_os_prober_separate_boot, fixes wrong kernel/initrd
    pathnames and wrong partition UUID/GRUB path when generating menuentries
    from os-prober output of a detected system with a separate /boot; thanks
    Colin Watson; LP: #462961.

 -- Loic Minier <email address hidden> Thu, 29 Oct 2009 02:30:35 +0000

Changed in grub2 (Ubuntu Karmic):
status: Fix Committed → Fix Released
tags: added: iso-testing
Revision history for this message
wild.ideas (wild-ideas) wrote :

Martin, et al, please take a look at Bug 551790 -- it appears that the fix for this has not gotten into Lucid or Maverick (or has regressed). 551790 has been 'confirmed', but it's not assigned to anyone...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.