ProbeForRootFilesystem

Differences between revisions 4 and 5
⇤ ← Revision 4 as of 2005-11-02 19:13:16 →
Size: 1954
Editor: 130-127-132-200
Comment:
← Revision 5 as of 2005-11-03 01:06:06 → ⇥
Size: 2727
Editor: 209
Comment: Give a proper cleanup
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
Scott has this insane habit of swapping around devices but he is too lazy to fix mount points and boot bits around.
Line 17: Line 19:

Make so that Scott doesn't need to change any bit at all.
Line 20: Line 24:
Use UUID to uniquely identify root partition and fall back to old behavior if UUID are not available.
Line 22: Line 28:
 * One possibility for this is the 'search' command in grub2  * d-i requires changes to provide the new /dev/disks/by-uuid when possible as new root device.
Line 24: Line 30:
 * Implement d-i bits to propagate UUID information for FS that supports this feature down the path so that whenever possible we will mount via UUID otherwise use classic system.
Line 29: Line 34:
 * d-i/partman/fstab  * base-installer and bootloader-installers.
Line 37: Line 42:
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.  * None

== 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

 * 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.

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: The device containing the root filesystem moves to a different bus, driver, port, or otherwise is recognized by Linux as a "different" device The device containing the root filesystem is relocated from one system to another (especially applicable to removable devices such as USB storage media) 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.

Implementation

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

    • 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

Code

  • base-installer and bootloader-installers.

Data preservation and migration

  • None

Outstanding issues

  • None

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

  • 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.

BoF agenda and discussion

ProbeForRootFilesystem (last edited 2008-08-06 16:24:45 by localhost)