Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/probe-for-root-filesystem

• Created: Date(2005-10-27T22:05:00Z) by JeffBailey2

• Contributors: JeffBailey2

• Packages affected:

Summary

Rationale

As of Ubuntu 5.10, the boot process relies on a kernel parameter to provide the device path for the root filesystem. This mechanism is subject to failure in the following scenarios:

1. The device containing the root filesystem moves to a different bus, driver, port, or otherwise is recognized by Linux as a "different" device
2. The device containing the root filesystem is relocated from one system to another (especially applicable to removable devices such as USB storage media)
3. The hardware detection process within Linux or early userspace changes in incompatible ways (such as changing the order in which devices on a bus are detected)

We should provide a mechanism which is not subject to these problems, while maintaining robustness in the common case (a device which doesn't move).

Use cases

Scott has this insane habit of swapping around devices but he is too lazy to fix mount points and boot bits around.

Scope

Make so that Scott doesn't need to change any bit at all.

Design

Use UUID to uniquely identify root partition and fall back to old behavior if UUID are not available.

UUID in this case is the "Unique Identifier" generated at filesystem creation time.

Implementation

• d-i requires changes to provide the new /dev/disks/by-uuid when possible as new root device.

`XXX: provide == add code to add virtual devices to /dev? does that require any kernel or grub change to detect file systems by UUID? Does the current kernel already support root=<uuid>? What has to be changed in the grub configuration? Please explain how the boot process works when using UUID, which parts have to be changed to make it work, and whether or not it breaks compatibility with already installed systems. Can I still boot my old Debian and Ubuntu installations when the new d-i installs a new grub with these features?`

jbailey Replies: udev 071 provides /dev/disks/by-uuid/ - specific details can be found in UdevRoadmap - No special changes beyond the udev update are required.. The kernel and grub itself do not change (outside of the requirements of UdevRoadmap). The "root=" value is passed as a kernel command line parameter and is only parsed by initramfs-tools, which can already handle this.

Code

• base-installer and bootloader-installers.

Data preservation and migration

• None

Outstanding issues

• Not all filesystem exports a UUID by default (hence "when possible" in the implementation).

XXX: in this case we just use the old method root=/dev/hdXX?

jbailey Replies: Exactly right. This should go under Implementation. This concept is an optimisation that is provided where possible.

Random comments/inputs

• What implications does this have for mass duplication of systems? In Ghost the filesystem is recreated on the target drive (and thus, I assume, a new UUID). How might this compare to mounting via the label instead? -- JayCamp

UUID needs to be unique on the same machine. LABEL are more prone to clashing and this idea has been discarded at BOF -- FabioMassimoDiNitto

XXX: So moving the hard drive to another machine will break? (i. e. root=/dev/XXX is required)?

jbailey Replies: This is more confusing than it needs to be. In any case where the UUID is actually unique, you may move it between machines. If at any time there is a conflict between them, your system will break in interesting ways. Luckily, "Universal Unique IDentifier" have a tendancy of being universally unique. =)

• RAID volumes actually have two UUIDs -- one for the RAID, and one for the filesystem on them. We should either support both, or synchronize them.

This is no problem at all. The root UUID is required at installer time and encoded in the bootloader as root=/dev/discs/by-uuid so there is no problem at all to get the right one.