Muli Ben-Yehuda's journal

May 5, 2004

technical musings – how does root=LABEL=xxx really work?

Filed under: Uncategorized — Muli Ben-Yehuda @ 4:43 PM

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

Advertisements

4 Comments »

  1. 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 | Reply

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

      • 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

  2. 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 | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: