postinst has errors with grub-probe that cause the system to stop booting

Bug #508173 reported by Mario Limonciello on 2010-01-15
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OEM Priority Project
High
Unassigned
grub2 (Ubuntu)
Medium
Colin Watson
Lucid
Medium
Colin Watson

Bug Description

Binary package hint: grub2

Setting up grub-pc (1.98~20100101-1ubuntu2) ...
/usr/sbin/grub-probe: error: Cannot stat `(hd0'
Invalid device `(hd0'.
Try ``/usr/sbin/grub-setup --help'' for more information.
/usr/sbin/grub-probe: error: Cannot stat `3)'
Invalid device `3)'.
Try ``/usr/sbin/grub-setup --help'' for more information.

In /var/cache/debconf/config.dat:

Name: grub-pc/install_devices
Template: grub-pc/install_devices
Value: (hd0,3)
Owners: grub-pc
Flags: seen
Variables:
 CHOICES = /dev/sda

ProblemType: Bug
Architecture: i386
Date: Fri Jan 15 22:21:16 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100113)
NonfreeKernelModules: wl
Package: grub-pc 1.98~20100101-1ubuntu2
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-10.14-generic
SourcePackage: grub2
Tags: lucid
Uname: Linux 2.6.32-10-generic i686

Mario Limonciello (superm1) wrote :
Mario Limonciello (superm1) wrote :

It appears that after this grub update I was no longer able to boot the system. Booting a live stick and reinstalling grub to that partition fixed the problem.

summary: - postinst as errors with grub-probe
+ postinst has errors with grub-probe that cause the system to stop
+ booting
Jerone Young (jerone) wrote :

This is effecing machines trying to upgrade from 9.10 to 10.04. As well as 10.04 dell factory installs.

Colin Watson (cjwatson) wrote :

You can almost certainly work around this by preseeding /dev/sda3 rather than (hd0,3), and in fact I strongly recommend making this change to your preseed file; we are in the process of deprecating the (hdX,Y) names for most purposes other than manual exploration at the GRUB rescue prompt.

Nevertheless, this is still a bug in how we're handling preseeding following recent changes.

Changed in grub2 (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
Colin Watson (cjwatson) wrote :

(Yes, I realise that the previous comment is no help for upgrades ...)

Colin Watson (cjwatson) wrote :

I may be able to figure the bug out without this, but an upgrade log with DEBCONF_DEBUG=developer set in the environment would be helpful. Cursory examination doesn't show a code path for which this is possible on upgrades (the intent is that if you're upgrading from something not explicitly understood, then you'll get a question; although I should also enhance the "explicitly understood" bit to cover the case of installing to a partition on a single-disk system like this), but perhaps I've missed something.

Out of interest, why are you installing GRUB to a partition? This is unreliable in some quite fundamental ways and if you can manage to avoid doing this it would be a good idea.

Mario Limonciello (superm1) wrote :

Sorry for the extended delay in response here. As soon as you asked for that information, I tried to reproduce it again on 10.04 a2 upgrade through to current daily but couldn't anymore. Due to other extenuating circumstances I wasn't able to run a full dist-upgrade from a 9.10 install with (hd0,3) preseeded until now.

I've made the change to install to install to the device node for the 10.04 based installs, so there shouldn't be any worries for those machines going forward.

Regarding why we're installing to the partition in the first place, it's because the MBR that's on the drive isn't a true DOS MBR, but something unique and specific to the factory processes. By the time it gets to the customer site and they break the electronic seal (press a key at the EULA on boot) it will begin behaving like a standard DOS MBR, referring to the active partition. Installing grub to the MBR would prevent this behavior.

So regarding my results from a 9.10 -> 10.04 upgrade, I just tried today from a fresh 9.10 install from an image preseeded with (hd0,3). Rather than it making a poor choice and behaving improperly, I was instead offered a dialog to choose where to install grub to. It appears to let me select where to install grub to. I'm sure this dialog will be rather shocking to anyone who received a system like this though, as they may have no idea that they were booting off the third partition. I'll attach a screenshot of this behavior to show.

Jerone Young (jerone) on 2010-03-25
Changed in oem-priority:
importance: Undecided → High
Changed in grub2 (Ubuntu):
status: New → Confirmed
Colin Watson (cjwatson) wrote :

I'm afraid it doesn't look like I'll be able to debug this without a DEBCONF_DEBUG=developer log; is it at all practicable to provide one? Thanks.

Changed in grub2 (Ubuntu Lucid):
status: Confirmed → Incomplete
Jerone Young (jerone) on 2010-04-26
Changed in oem-priority:
status: New → Incomplete
Mario Limonciello (superm1) wrote :

I'm attaching the requested log.

1) Factory installed 9.10
2) export DEBCONF_DEBUG=developer
3) update-manager -d
4) Attaching term.log from up to when that dialog came up.

Colin Watson (cjwatson) wrote :

Thanks. I've committed a fix which should deal with this, and will propose it for an SRU shortly since it's now too late to get this into Lucid.

Changed in grub2 (Ubuntu Lucid):
importance: Undecided → Medium
status: Incomplete → Fix Committed

Accepted grub2 into lucid-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
Jerone Young (jerone) on 2010-04-29
Changed in oem-priority:
status: Incomplete → Fix Committed
Mario Limonciello (superm1) wrote :

I can confirm the updated grub worked properly for an upgrade.

I reran the above test scenario activating lucid-proposed before starting.

Martin Pitt (pitti) on 2010-04-30
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 1.98-1ubuntu6

---------------
grub2 (1.98-1ubuntu6) lucid-proposed; urgency=low

  * When migrating from the old grub-pc/install_devices scheme, check if the
    old value indicated installation to a single partition on a single disk.
    In that case, if there is only one disk present and it has a matching
    partition number, then we can install to that partition without asking
    (LP: #508173).
 -- Colin Watson <email address hidden> Wed, 28 Apr 2010 15:48:02 +0100

Changed in grub2 (Ubuntu Lucid):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Copied lucid-proposed to maverick.

Changed in grub2 (Ubuntu):
status: Fix Committed → Fix Released
Changed in grub2 (Ubuntu Lucid):
status: Fix Released → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 1.98-1ubuntu6

---------------
grub2 (1.98-1ubuntu6) lucid-proposed; urgency=low

  * When migrating from the old grub-pc/install_devices scheme, check if the
    old value indicated installation to a single partition on a single disk.
    In that case, if there is only one disk present and it has a matching
    partition number, then we can install to that partition without asking
    (LP: #508173).
 -- Colin Watson <email address hidden> Wed, 28 Apr 2010 15:48:02 +0100

Changed in grub2 (Ubuntu Lucid):
status: Fix Committed → Fix Released
Emmet Hikory (persia) wrote :

Installation of this update in a GPT environment resulted in an unbootable machine: see bug #576662

tags: added: verification-failed
removed: verification-done
Emmet Hikory (persia) on 2010-05-06
tags: added: regression-update
Colin Watson (cjwatson) wrote :

The code added in this update was guarded such that it would not have been run on upgrade from Lucid release, therefore I suspect that any rerun of grub-install would have caused a problem and that it wasn't intrinsically related to this update. We should certainly investigate but I'm not sure it legitimately counts as a failed verification here.

Jerone Young (jerone) on 2010-05-18
Changed in oem-priority:
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Setting verification back to -done, since bug 576662 was closed as invalid.

tags: added: verification-done
removed: regression-update verification-failed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers