ProbeForRootFilesystem

Differences between revisions 2 and 3
Revision 2 as of 2005-11-01 17:17:32
Size: 1550
Editor: 209
Comment: Draft
Revision 3 as of 2005-11-01 20:33:41
Size: 1721
Editor: 209
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/foo  * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/probe-for-root-filesystem
Line 36: Line 36:
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.

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

Scope

Design

Implementation

  • One possibility for this is the 'search' command in grub2
  • 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.

Code

  • d-i/partman/fstab

Data preservation and migration

  • None

Outstanding issues

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.

BoF agenda and discussion

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