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

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.

This is breaking every system i've got installed with this preseed when upgrading:
http://linux.dell.com/git/?p=ubuntu-fid.git;a=blob;f=framework/preseed/dell.seed;h=8e25903a98297a3f08bd088e085d2674dacbaeb9;hb=HEAD

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

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.

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

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.

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.

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.

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.

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.

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!

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

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

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

Copied lucid-proposed to maverick.

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

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

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.

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