Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 164423 - mkinitrd hard codes init script to only activate root volume group
Summary: mkinitrd hard codes init script to only activate root volume group
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: initscripts
Version: 4.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Peter Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-27 20:15 UTC by Jeremy Charles
Modified: 2009-03-11 16:44 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-11 16:44:48 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jeremy Charles 2005-07-27 20:15:31 UTC
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
   fi
 fi


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

How reproducible:
Always

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-29 01:45:02 UTC
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 16:51:36 UTC
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-4.2.1.6-1 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-4.2.1.6-1 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 19:38:29 UTC
I've just realized that the new kernel-2.6.9-34.EL depends on broken
mkinitrd-4.2.1.6-1.  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 20:38:19 UTC
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 21:17:48 UTC
initscripts already has:

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

If this is happneing before init rus, that's a mkinitrd issue of some sort.

Comment 6 Peter Jones 2007-08-10 21:22:16 UTC
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 15:47:30 UTC
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 16:44:48 UTC
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.