mkinitrd and root=LABEL not working

slackuser46 · 09-23-2008, 04:53 PM

Hello,

I am trying to make a initrd so I can get root=LABEL= to work. This is what I have done so far:
1. Installed slackware 12.1
2. Installed mkinitrd-1.3.2-i486-3.tgz
3. downloaded and compiled kernel 2.6.26.5 (no modules)
4. # mkinitrd
Nothing found at location /boot/initrd-tree, so we will create an
initrd directory structure there... done.

Now cd to /boot/initrd-tree and install some modules in your
module directory (lib/modules/2.6.26.5). Then see init
for more information (there are a few other files to edit).
Finally, run mkinitrd again once the initrd-tree is ready,
and /boot/initrd.gz will be created from it.

5. I don't need any modules as everything is compiled into my
kernel so I rerun mkiinitrd and get:
# mkinitrd
2984 blocks
/boot/initrd.gz created.
Be sure to run lilo again if you use it.

I changed my grub menu to add initrd=initrd.gz and changed
root=LABEL=usb2 and rebooted. I get VFS errors:
VFS: cannot open root device "LABEL=usb2" or unknown-block(0,0)
Please append a correct "root=" boot option
kernel panic - not syncing VFS uanble to mount root fs on unknown-block(0,0)
I look in /boot/initrd-tree/bin and
sbin and no sign of udev. Isn't udev what handles booting
by the LABEL or id stuff?

Thanks,

Bruce Hill · 09-23-2008, 05:21 PM

Welcome to LQ!

You didn't post your mkinitrd command for us to check. I don't really see
why you want an initrd image. I don't use GrUB, but with LiLO there is no
need for an initrd image for "root= label" to work properly.

Use this mkinitrd command generator script to generate a proper command.

raconteur · 09-23-2008, 06:05 PM

I think it is pretty safe to assume the mkinitrd was completed properly, the tree was created correctly and the compressed image also appears to be OK, especially since no modules were added to it.

So... the problem appears to be grub configuration.

I found this at http://csciwww.etsu.edu/nielsen/4417...ons-labels.txt

---

A sample Grub configuration stanza might look as follows:

title Red Hat Linux (2.4.9-24)
root (hd0,6)
kernel /vmlinuz-2.4.9-24 ro root=LABEL=/
initrd /initrd-2.4.9-24.img

A common problem is to have the 'root=LABEL=/' component be incorrect
with respect to the actual label, or with the contents of /etc/fstab; e.g.,
# head /etc/fstab
...
LABEL=/ / ext3 defaults 1 1
...

To discover which partition is labelled '/', use the 'e2label' program
to check each partition; e.g.,
# e2label /dev/hda7
/

In the grub.conf stanza above, note that we define the 'root'
directive twice: once with the line 'root (hd0,6)' and again
on the kernel line. In actuality, the first definition is
overwritten by the second, but I personally like to leave it
in place, as it serves as documentation for which partition
should be labelled '/'.

---

Ok, all that being said... why use the label option?
I usually try to just help folks and not make any judgements about the technique, and I'm not trying to be judgemental in this case, I am just curious about why you want or need to use the label option.

hth

slackuser46 · 09-23-2008, 06:31 PM

Quote:

Originally Posted by Bruce Hill

Welcome to LQ!

You didn't post your mkinitrd command for us to check. I don't really see
why you want an initrd image. I don't use GrUB, but with LiLO there is no
need for an initrd image for "root= label" to work properly.

Use this mkinitrd command generator script to generate a proper command.

I did actually. The command was:
# mkinitrd
# mkinitrd

The first mkinitrd made the initrd-tree.
The second mkinitrd made the initrd.gz file.
I even tried:
# mkinitrd -w 15 as I am booting from a usb hard drive.

I will look at the tool when I get back to my slackware install.

Thanks,

slackuser46 · 09-23-2008, 06:44 PM

Quote:

Originally Posted by raconteur

I think it is pretty safe to assume the mkinitrd was completed properly, the tree was created correctly and the compressed image also appears to be OK, especially since no modules were added to it.

So... the problem appears to be grub configuration.

title Red Hat Linux (2.4.9-24)
root (hd0,6)
kernel /vmlinuz-2.4.9-24 ro root=LABEL=/
initrd /initrd-2.4.9-24.img

A common problem is to have the 'root=LABEL=/' component be incorrect
with respect to the actual label, or with the contents of /etc/fstab; e.g.,
# head /etc/fstab

To discover which partition is labelled '/', use the 'e2label' program
to check each partition; e.g.,
# e2label /dev/hda7
/

Ok, all that being said... why use the label option?
I usually try to just help folks and not make any judgements about the technique, and I'm not trying to be judgemental in this case, I am just curious about why you want or need to use the label option.

hth

Not a problem. I didn't take your comment negatively.

my menu.lst looks like:
title Linux on (/dev/sda1) 2.6.26.5 HP 7700
root (hd0,0)
kernel /boot/vmlinuz-2.6.26.5 root=LABEL=usb2 initrd /boot/initrd.gz ro rootdelay=12 pci=conf1

my /etc/fstab:
LABEL=usb2 / auto defaults 1 1
aufs / aufs defaults 0 0 # AutoUpdate
devpts /dev/pts devpts gid=5,mode=620 0 0 # AutoUpdate
proc /proc proc defaults 0 0 # AutoUpdate
sysfs /sys sysfs defaults 0 0 # AutoUpdate

# e2label /dev/hda7
usb2

The device is labeled correctly. grub 0.97 is what I use not lilo. I have been told that in order for root=LABEL to work correctly I must have a initrd. Apparently if you don't have a initrd udev starts to late to handle finding the drive.

What I have is an external USB drive to I carry from PC to PC. Every PC is different and so my root= has to change to match the PC. I am getting tired of having to manually change root= a dozen or times a day. I need root=LABEL= or something to free me so I don't have to change anything.

Thanks,

Bruce Hill · 09-23-2008, 06:50 PM

Is your path to the USB device correct?

Code:

root=LABEL=usb2

I tried to use grub when I first started with Linux, but it was
too complicated for me; so no grub man page on this LAN to read.

If you make an initrd, why not follow the directions? You have no
need to do it all manually -- read "man mkinitrd" and/or use the
script I posted -- make it easy on yourself. That script has an
option for things if you use "-i" for interactive.

onebuck · 09-23-2008, 07:10 PM

Hi,

Quote:

Originally Posted by slackuser46

I did actually. The command was:
# mkinitrd
# mkinitrd

The first mkinitrd made the initrd-tree.
The second mkinitrd made the initrd.gz file.
I even tried:
# mkinitrd -w 15 as I am booting from a usb hard drive.

I will look at the tool when I get back to my slackware install.

Thanks,

You should read the '/boot/README.initrd' to get a better understanding of how to create a initrd.

Code:

excerpt from '/boot/README.initrd';

2.  Why do I need an initrd?

The usual reason to use an initrd is because you need to load kernel
modules before mounting the root partition.  Usually these modules are
required to support the filesystem used by the root partition (ext3,
reiserfs, xfs), or perhaps the controller that the hard drive is attached
to (SCSI, RAID, etc).  Essentially, there are so many different options
available in modern Linux kernels that it isn't practical to try to ship
many different kernels to try to cover everyone's needs.  It's a lot more
flexible to ship a generic kernel and a set of kernel modules for it.

3.  How do I build the initrd?

The easiest way to make the initrd is to use the mkinitrd script included
in Slackware's mkinitrd package.  We'll walk through the process of
upgrading to the generic 2.6.24.5-smp Linux kernel using the packages
found in Slackware's slackware/a/ directory.

First, make sure the kernel, kernel modules, and mkinitrd package are
installed (the current version numbers might be a little different, so
this is just an example):
First, make sure the kernel, kernel modules, and mkinitrd package are
installed (the current version numbers might be a little different, so
this is just an example):

  installpkg kernel-generic-2.6.24.5_smp-i486-1.tgz
  installpkg kernel-modules-2.6.24.5_smp-i486-1.tgz
  installpkg mkinitrd-1.3.2-i486-2.tgz

Change into the /boot directory:

  cd /boot

Now you'll want to run "mkinitrd".  I'm using reiserfs for my root
filesystem, and since it's an IDE system the reiserfs module will be
the only one I need to load:

  mkinitrd -c -k 2.6.24.5-smp -m reiserfs

This should do two things.  First, it will create a directory
/boot/initrd-tree containing the initrd's filesystem.  Then it will
create an initrd (/boot/initrd.gz) from this tree.  If you wanted to,
you could make some additional changes in /boot/initrd-tree/ and
then run mkinitrd again without options to rebuild the image.  That's
optional, though, and only advanced users will need to think about that.

Here's another example:  Build an initrd image using Linux 2.6.24.5-smp
kernel modules for a system with an ext3 root partition on /dev/hdb3.

  mkinitrd -c -k 2.6.24.5-smp -m ext3 -f ext3 -r /dev/hdb3

The resulting initrd will automatically load the mbcache and jbd modules
used by the ext3 module.

To automatically use the current root filesystem and kernel, you can
simply use:

  mkinitrd -m ext3

4.  Now that I've built an initrd, how do I use it?

Bruce Hill · 09-23-2008, 07:25 PM

Quote:

Originally Posted by onebuck

You should read the '/boot/README.initrd' to get a better understanding of how to create a initrd.

onebuck,

If you would read "man mkinitrd" you will see the way he did it
is proper if you desire to build an initrd manually:

Quote:

mingdao@silas:~$ man mkinitrd
<snip>
If run without options, mkinitrd will rebuild an initrd image using the contents of the $SOURCE_TREE directory, or, if that directory does
not exist it will be created and populated, and then mkinitrd will exit. These options are handy for building an initrd mostly by hand.
After creating /boot/initrd-tree/, you can add modules and edit files by hand, and then rerun mkinitrd to create the initrd.

We can't force everyone to do things the way we do, or the
way we think is best. I agree and have suggested he do it
The Slackware Way (TM), but as you and I know, that is one
of the beautiful things about Slack -- it's flexible.

slackuser46 · 09-23-2008, 08:52 PM

Quote:

Originally Posted by onebuck

Hi,

You should read the '/boot/README.initrd' to get a better understanding of how to create a initrd.

Code:

excerpt from '/boot/README.initrd';

2.  Why do I need an initrd?

The usual reason to use an initrd is because you need to load kernel
modules before mounting the root partition.  Usually these modules are
required to support the filesystem used by the root partition (ext3,
reiserfs, xfs), or perhaps the controller that the hard drive is attached
to (SCSI, RAID, etc).  Essentially, there are so many different options
available in modern Linux kernels that it isn't practical to try to ship
many different kernels to try to cover everyone's needs.  It's a lot more
flexible to ship a generic kernel and a set of kernel modules for it.

3.  How do I build the initrd?

The easiest way to make the initrd is to use the mkinitrd script included
in Slackware's mkinitrd package.  We'll walk through the process of
upgrading to the generic 2.6.24.5-smp Linux kernel using the packages
found in Slackware's slackware/a/ directory.

First, make sure the kernel, kernel modules, and mkinitrd package are
installed (the current version numbers might be a little different, so
this is just an example):
First, make sure the kernel, kernel modules, and mkinitrd package are
installed (the current version numbers might be a little different, so
this is just an example):

  installpkg kernel-generic-2.6.24.5_smp-i486-1.tgz
  installpkg kernel-modules-2.6.24.5_smp-i486-1.tgz
  installpkg mkinitrd-1.3.2-i486-2.tgz

Change into the /boot directory:

  cd /boot

Now you'll want to run "mkinitrd".  I'm using reiserfs for my root
filesystem, and since it's an IDE system the reiserfs module will be
the only one I need to load:

  mkinitrd -c -k 2.6.24.5-smp -m reiserfs

This should do two things.  First, it will create a directory
/boot/initrd-tree containing the initrd's filesystem.  Then it will
create an initrd (/boot/initrd.gz) from this tree.  If you wanted to,
you could make some additional changes in /boot/initrd-tree/ and
then run mkinitrd again without options to rebuild the image.  That's
optional, though, and only advanced users will need to think about that.

Here's another example:  Build an initrd image using Linux 2.6.24.5-smp
kernel modules for a system with an ext3 root partition on /dev/hdb3.

  mkinitrd -c -k 2.6.24.5-smp -m ext3 -f ext3 -r /dev/hdb3

The resulting initrd will automatically load the mbcache and jbd modules
used by the ext3 module.

To automatically use the current root filesystem and kernel, you can
simply use:

  mkinitrd -m ext3

4.  Now that I've built an initrd, how do I use it?

Thank you for the information. I actually did read that. However when I compile my kernel I don't use modules. Everything is compiled in (no =m in my .config).

I will try the mkinitrd -m ext3 tomorrow and see if it works. Seeing as ext2 and ext3 are compiled into the kernel I don't think it will matter but I will try it.

Thanks,

duryodhan · 09-23-2008, 10:48 PM

If you have compiled everything in, you don't need a initrd.

Can you just try doing root=/dev/sdxi for testing ? If that works then there is some problem with your syntax for LABEL= .. I have never used it so I would never know ..

gnashley · 09-24-2008, 02:06 AM

"note that we define the 'root'
directive twice: once with the line 'root (hd0,6)' and again
on the kernel line. In actuality, the first definition is
overwritten by the second,"

this is not correct. The first directive is to the bootloader grub and is not 'seen' by the kernel at all.

This may have changed, but the last I knew, you needed to have an initrd with devmapper on board in order to use LABEL. There was a thread her in the recent past about using LABEL. You might try searching for it.

keefaz · 09-24-2008, 07:52 AM

Quote:

kernel panic - not syncing VFS uanble to mount root fs on unknown-block(0,0)

It is not 100% sure that the error comes from the root=LABEL option, though

I would try this on menu.lst:

Code:

title Linux on (/dev/sda1) 2.6.26.5 HP 7700
root (hd0,0)
kernel /boot/vmlinuz-2.6.26.5 root=/dev/hda7 ro rootdelay=12 pci=conf1
initrd /boot/initrd.gz

If it still can not boot the root partition, then the error is not caused by root=LABEL

Bruce Hill · 09-24-2008, 08:20 AM

Quote:

Originally Posted by slackuser46

What I have is an external USB drive to I carry from PC to PC. Every PC is different and so my root= has to change to match the PC. I am getting tired of having to manually change root= a dozen or times a day. I need root=LABEL= or something to free me so I don't have to change anything.

Thanks,

Thinking of this, I wonder if different PC configurations
are going to throw this off. For instance, this box has
three SATA hard drives (/dev/sda, /dev/sdb, and /dev/sdc) in
addition to a SATA DVD+/-RW (/dev/sr0), which itself might be
picked up as /dev/sdx on a particular system.

Not having used GrUB, maybe this point is moot; or maybe this
has to do with the reasons for an initrd.

Also, I'm not up on (or enthustiastic about) udev, but perhaps
you might need the UUID of the USB drive passed to boot.

Forgive my rambling if this is all a waste of your time and off
in left field somewhere (my PC position).

keefaz · 09-24-2008, 08:50 AM

I find this is a clear explanation as how root=LABEL works:
http://mulix.livejournal.com/84768.html

slackuser46 · 09-24-2008, 10:02 AM

Quote:

Originally Posted by Bruce Hill

Thinking of this, I wonder if different PC configurations
are going to throw this off. For instance, this box has
three SATA hard drives (/dev/sda, /dev/sdb, and /dev/sdc) in
addition to a SATA DVD+/-RW (/dev/sr0), which itself might be
picked up as /dev/sdx on a particular system.

Not having used GrUB, maybe this point is moot; or maybe this
has to do with the reasons for an initrd.

Also, I'm not up on (or enthustiastic about) udev, but perhaps
you might need the UUID of the USB drive passed to boot.

Forgive my rambling if this is all a waste of your time and off
in left field somewhere (my PC position).

That is the problem I am trying to solve. Right now I have to manually change the root= to match the hardware. Sometimes I need root=/dev/sda1, sometimes I need root=/dev/sdb1 or even root=/dev/sdf1. I never know what I need what I try to boot. This is why getting root=LABEL to work would be a huge benefit for me.