Bug 164423 - mkinitrd hard codes init script to only activate root volume group
mkinitrd hard codes init script to only activate root volume group
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: initscripts (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
Depends On:
  Show dependency treegraph
Reported: 2005-07-27 16:15 EDT by Jeremy Charles
Modified: 2009-03-11 12:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-11 12:44:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeremy Charles 2005-07-27 16:15:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Red Hat/1.0.6-1.4.1 Firefox/1.0.6

Description of problem:
When I run mkinitrd, it detects the volume group that the root filesystem is on and hard codes the "init" script in the initial ramdisk to activate only that volume group.

This causes a failure when /etc/rc.d/rc.sysinit attempts to mount filesystems found on other volume groups, resulting in a root shell rather than a successful boot.

It would be preferential if mkinitrd would omit the volume group name in the call to vgchange and simply allow vgchange to default to activating all known volume groups.  Here's a suggested fix:

--- /sbin/mkinitrd      2005-03-17 14:29:24.000000000 -0600
+++ /tmp/mkinitrd.new   2005-07-27 13:19:02.000000000 -0500
@@ -728,7 +728,7 @@
     echo "echo Scanning logical volumes" >> $RCFILE
     echo "lvm vgscan --ignorelockingfailure" >> $RCFILE
     echo "echo Activating logical volumes" >> $RCFILE
-    echo "lvm vgchange -ay --ignorelockingfailure $root_vg" >> $RCFILE
+    echo "lvm vgchange -ay --ignorelockingfailure" >> $RCFILE

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Create two volume groups:  vg00 and vg01

2.  Place the root file system on a logical volume within vg00

3.  Create a logical volume and file system within vg01.

4.  Configure /etc/fstab to mount the file system in vg01.  For example:
/dev/vg01/lvfoo      /opt/foo   ext3    defaults        1 2

5)  Run /sbin/mkinitrd to re-create the initial ramdisk

6)  Reboot the system.  Notice that boot fails because /dev/vg01/lvfoo has not yet been activate.


Actual Results:  I ended up having to enter the root password to obtain a shell with "(Repair filesystem)" in the prompt.

Expected Results:  The system should have booted, mounting /dev/vg01/lvfoo on /opt/foo.

Additional info:
Comment 1 Jeremy Charles 2005-07-28 21:45:02 EDT
Alternate suggested solution:  I would be perfectly happy if rc.sysinit would
activate the remaining volume groups before trying to mount filesystems from them.  

I guess the real problem is that neither initrd nor rc.sysinit activates the
non-root volume groups before trying to mount file systems on them.
Comment 2 Aleksandar Milivojevic 2006-02-09 11:51:36 EST
This bug just made my system unbootable (kernel panic, can't find init).

I have two volume groups.  The volume group "sys" contains partitions with the
operating system and swap.  The volume group "backup" is used by one application
for some temporary storage (absolutely not needed for booting).

The initrd script created with old mkinitrd-4.1.18-2 activates both volume
groups.  The console output suggests that activation order was backup and than
sys.  Looking into the /dev/mapper directory seems to confirm this (order of
assignment of minor numbers):

# ls -l /dev/mapper/
total 0
brw-------  1 root root 253,  0 Feb  8 09:00 backup-data
crw-------  1 root root  10, 63 Feb  8 09:00 control
brw-------  1 root root 253,  1 Feb  8 09:00 sys-root
brw-------  1 root root 253,  2 Feb  8 09:00 sys-srv

After update to U2, the new initrd image created by mkinitrd- activates
only the sys volume group, and subsequent mount of root file system fails. 
Actually, from the output, it seems like it has mounted *something*, but that
*something* doesn't seem to be my root file system.  I can see "EXT3-fs: mounted
filesystem with ordered data mode." message, and then kernel panics with "can't
find init" (or something like that).

My guess is that it mounted whatever got minor number "1" (probably my
/dev/sys/srv logical volume that contains /srv file system, since if backup
volume group is not present, it would get minor number 1).  However, I haven't
had time to recreate initrd image by hand to be able to confirm this.

Downgrading to mkinitrd-4.1.18-2 and recreating initrd images solved the
problem, and my system is bootable again.

BTW, I also had possibly related problem on one of my other boxes (also sys and
backup volume groups, but activated in more logical order, first sys then
backup).  Initrd images created by mkinitrd- would not activate backup
volume group, however devices in /dev/mapper and /dev/backup were not created
when backup volume group was activated after the fact!?  It was kinda strange. 
Possibly also bug somewhere in udev and/or lvm2?
Comment 3 Aleksandar Milivojevic 2006-04-03 15:38:29 EDT
I've just realized that the new kernel-2.6.9-34.EL depends on broken
mkinitrd-  Shouldn't mkinitrd be fixed before kernel that specifically
depends on it is released?  Anyhow, I've updated the kernel by using --nodeps. 
Tested.  Seems all works good for now.
Comment 4 Peter Jones 2007-08-10 16:38:19 EDT
rc.sysinit should be activating these; if mkinitrd activates other VGs, it'll
fail in the presence of clustered VGs.
Comment 5 Bill Nottingham 2007-08-10 17:17:48 EDT
initscripts already has:

    if [ -x /sbin/lvm.static ]; then
            action $"Setting up Logical Volume Management:" /sbin/lvm.static
vgchange -a y --ignorelockingfailure

If this is happneing before init rus, that's a mkinitrd issue of some sort.
Comment 6 Peter Jones 2007-08-10 17:22:16 EDT
It's not before init runs.  From the initial report:

Actual Results:  I ended up having to enter the root password to obtain a shell
with "(Repair filesystem)" in the prompt.
Comment 7 Brian J. Murrell 2009-02-27 10:47:30 EST
There is another problem here.

What if volume groups are located on devices which are not available when the initrd does it's vgscan.

What if say, /etc/sysconfig/modules/*.modules loads a block device driver and the device on that has a volume group?  vgscan needs to be run again to find it, so that the vgchange - a y in rc.sysinit can enable it.
Comment 8 Bill Nottingham 2009-03-11 12:44:48 EDT
vgchange should handle the run without vgscan fine.

In any case, the code exists in rc.sysinit, and has existed ever since RHEL 4 was released. Given that it works for me and many other users, I'm going to close this - if you have a reliable way to reproduce, please reopen. (Sorry about the delay.)

Note You need to log in before you can comment on or make changes to this bug.