Yesterday I spent a fun couple of hours trying to figure out what
kernel support is required for booting with a root=LABEL=xxx kernel
command line parameter.
The “standard” way to specify the root partition is passing a kernel
command line parameter such as “root=/dev/hda1”. RedHat, YellowDog and
possibly other distributions switched a few years ago to use
“root=LABEL=xxx”. Rather than telling the kernel to use e.g. the first
partition on the first IDE disk (/dev/hda1), we tell it to use the
partition that has a label of ‘xxx’, regardless of where it’s
located. How is it implemented, though?
- The kernel starts booting, and loads an initrd (initial ram
disk). Normally, no initrd is required for a Linux kernel to
boot. However, an initrd *is* required for root=LABEL=xxx support,
since as we’ll soon see, the initrd is what actually does the work. - The kernel runs the ‘linuxrc’ script in the initrd. This script is
interpreted by the ‘nash’ interpreter. One of the stages in the linux
script is creation of the root device, via a nash directive. - When the ‘createRootDev’ nash directive is called, and the
root=XXX kernel command line parameter starts with LABEL=xxx, nash
builds a translation table of labels to partitions. It does this by- parsing the output of /proc/partitions to know which partitions
are recognized on the machine. - for each partition in /proc/partitions, open it as a raw device
and look for an ext2/3 or xfs file system. If such a file system is
found, get the label from the s_volume_name member of the
superblock, and add this (label, partition) pair to the translation
table.
- parsing the output of /proc/partitions to know which partitions
- Once the table is built, find the (major, minor) pair of the root
partition in it based on its label. - Create a device file with these (major, minor) numbers, and mount
it. - Use pivot_root to make it the current root.
- At this stage the linuxrc ends, and boot continues, with the fs
that has the label xxx mounted as the root fs.
At first, I kept looking for the code that deals with LABEL in the RH
kernel sources, and couldn’t find it. This was particularly annoying
since I distinctly remember seeing it a couple of weeks ago. After an
hour or so of digging, a light dawned on me, that I’m probably not
looking in the right place. I opened up the nash code in emacs, and
immediately found the code dealing with labels.
Muli Ben-Yehuda's journal 
consistent disk ordering
Isnt there any other way to get consistent disk ordering rather than
using labels. Why can’t, say, have the disk names as labels and use
internal mapping to actual disk device(sda, sdb listings in /proc/partitions would all be labels while internally we can have different names that are allowed to jump around). This way a user does not have to bother about labels.
Still remember the first time disk ordering bit me. I added a a few
disks to my box and suddenly my root disk sdb became sdm. Ignorant of
it all, I happily initialized all new ‘disk names’ that I could see
… and then it was the usual story 😦
Nice summary though …
Comment by jnagal — May 5, 2004 @ 7:23 AM |
Re: consistent disk ordering
What happens when you take this disk and then plug it in to a different computer? what happens when you then plug it in into this one? how does the kernel know to give it its “old” name back? In general, resource naming is hard problem, and the common solution is 128bit UUID. Maybe that’s what we should use… and as a matter of fact, that’s the direction 2.6 is going in, with udev and (major,minor) becoming an opaque cookie between kernel and user space.
Thanks…
Comment by mulix — May 5, 2004 @ 10:42 PM |
Re: consistent disk ordering
Where should it be stored? what happens when I repartition/format the disk?
Ithink uuid is currently being used in some places … lvm and disk multipath identification comes to mind.
Anyway, its an interesting problem. I need to find what all is happening in this area.
Thanks!
Comment by jnagal — May 5, 2004 @ 10:50 PM
Gentoo does it a different way
There’s a program called ‘findfs’ which is in the e2fsprogs package. You pass it a filesystem label or UUID and it gives back the device node for the partition whose filesystem has that label.
Gentoo’s latest initramfs (initrd replacement, cpio format instead of ext2) appears to use this. It adds very little code and sounds like a cleaner solution than Red Hat’s.
I hope it works. I’m about to try it. I’m using it to run Gentoo off a USB portable hard drive, after booting off a CD.
Comment by Anonymous — October 23, 2005 @ 5:24 AM |