Summary

Make GRUB 2's device identification reliable, so that we stop having to deal with boot loader problems when there are multiple disks.

Release Note

GRUB 2 now reliably identifies the device to which its boot code is written.

Rationale

This is the last piece needed to fix one of the largest classes of bugs open against the Ubuntu installer, which routinely causes a great deal of user frustration. Before GRUB 2, it was not really even theoretically fixable, but now we have a chance to do a proper job.

Design

Problem statement

GRUB installs its boot code to disk, usually to the MBR. It needs to install to the boot sector from which the computer will actually boot; we can't discover this without EDD (which is not always available), but usually the first hard disk is OK and for multiple-disk systems it's reasonable enough to ask the user. GRUB 2 fixed the problem where the boot sector code could not always find the rest of the boot loader code ("stage 1.5" in GRUB Legacy), at least in the case where it is installed in an MBR: it knows to look in the embedding area between the MBR and the first partition.

However, the remaining piece is that we need to remember which boot sector we installed GRUB to. The interface between GRUB 2's code and configuration file is not yet stable, and we need a reliable and safe way to upgrade the installed code. In Karmic, we store this information in grub-pc/install_devices in the debconf database, but only in the form of a traditional device name, e.g. /dev/sda. Simply remembering that we installed to /dev/sda is not sufficient because it is quite possible for the meaning of /dev/sda to change from boot to boot; this is particularly the case when removable devices are involved. The general problem here is not new to GRUB 2, although the precise manifestation is.

In most cases, we can and do use UUIDs to deal with this problem. However, UUIDs are a property of filesystems, not of disks or partitions. The MBR of a hard disk does not have a UUID. Disks do have some other stable identifiers, whose uniqueness is derived from either their hardware serial number or from the bus path taken to reach the disk. In this case, it seems most appropriate to use identifiers based on the hardware serial number, namely those in /dev/disk/by-id/, which uniquely identify a given physical disk, or a numbered partition on a given physical disk, but not any kind of logical construct on that disk (so they aren't suitable for filesystem mounting where you care much more about the contents).

GRUB core changes

Ensure that the GRUB utilities stop relying on /boot/grub/device.map. Nowadays this is principally an artifact for the purposes of the utilities, and relying on it simply means that we have to remember to update it across disk changes.

grub-pc maintainer script changes

If the directory /dev/disk/by-id exists (it should more or less always exist if you're using udev), then always store device names under /dev/disk/by-id/ in grub-pc/install_devices. (Use ata-* devices where possible, as those are stable across IDE<->libata changes. Fortunately, these happen to be first in alphabetical order ...)

It will not be suitable to actually display /dev/disk/by-id/ names to users, e.g. in the list of choices for that template. Instead, display either the traditional Linux device name, or (preferably) some kind of "friendly" name, including such things as the size of the disk. See d-i's partitioner for a partial model here.

On upgrade to the first version implementing this, if /dev/disk/by-id exists, ask again, possibly with different text. The reason for this is that their stored list of install devices might well be incorrect, and we want to make sure that we get it accurate as soon as we can store it accurately, and then store it accurately henceforth.

If ever it is discovered that the stored list of install devices includes a disk that no longer exists, ask the question again. This is probably because a disk was swapped out for a different one, and we almost certainly need new information on the state of the system.

grub-installer changes

Make grub-installer translate to /dev/disk/by-id when preseeding grub-pc/install_devices.

Test/Demo Plan

Install on a multiple-disk system, to various disks in different test iterations. Ensure that the system boots successfully. Ensure that reinstalling grub-pc reinstalls the boot sector to the appropriate place (test this by zeroing the MBR first and using a hex-dump tool to ensure that it is written back to the correct place; do not do this on a production system!).


CategorySpec

FoundationsTeam/GrubReliableDeviceIdentification (last edited 2009-11-26 16:56:06 by cjwatson)