Created attachment 414648 [details] suggested patch Description of problem: The mkinitrd script is not taking into account command_names or prefix from LVM's configuration. These 2 parameters can modify the output of an LVM command, and therefore the parsing can go wrong. Major example is on the latest version : copying the LVM config file has been replace by dumping it (lvm dumpconfig). The result is a corrupted config file (each line starts with dumpconfig) ... and the machine won't manage to boot. I believe the easiest would be to force the removal of such parameter with the --config option in order to force the default behavior. Example, line 1599 : /sbin/lvm.static dumpconfig --config 'log{command_names=0 prefix=" "}' > $MNTIMAGE/etc/lvm/lvm.conf Version-Release number of selected component (if applicable): How reproducible: mkinitrd-5.1.19.6-61.el5_5.1.i386 Steps to Reproduce: 1. run the command manually and check its output for command_names and prefix /sbin/lvm.static dumpconfig --config 'log{command_names=1 prefix="lala"}' Actual results: The initrd image created my mkinitrd contains a lvm.conf with garbage because the original lvm.conf has changed command_names and prefix defaults. Expected results: To work either with defaults or not. Additional info: This bug is a consequence of the https://bugzilla.redhat.com/show_bug.cgi?id=517868
Flavio, does command_names or prefix affect orher invocations of lvm.static that are made from mkinitrd? I can see that they change the output of vgdisplay and lvs which are used in mkinitrd but I'm not sure if parsing will go wrong in all cases.
Hi Alexander, Yes, it does.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
*** Bug 748733 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > *** Bug 748733 has been marked as a duplicate of this bug. *** With the Beta 1.0 tree the duplicate bug is not happening anymore. Systems can boot fine.
# rpm -q mkinitrd mkinitrd-5.1.19.6-75.el5 # grep lvm.static /sbin/mkinitrd local vg=$(lvm.static lvs --config 'log{command_names=0 prefix=" "}' --ignorelockingfailure --noheadings -o vg_name /dev/$slavedev 2>/dev/null) local vg=$(lvm.static lvs --config 'log{command_names=0 prefix=" "}' --ignorelockingfailure --noheadings -o vg_name $1 2>/dev/null) for device in $(lvm.static vgdisplay --config 'log{command_names=0 prefix=" "}' --ignorelockingfailure -v $vg 2>/dev/null | sed -n 's/PV Name//p'); do vg=$(lvm.static lvs --config 'log{command_names=0 prefix=" "}' --ignorelockingfailure --noheadings -o vg_name $rootdev 2>/dev/null) for pv in $(lvm.static vgdisplay --config 'log{command_names=0 prefix=" "}' --ignorelockingfailure -v $vg 2>/dev/null | sed -n 's/PV Name//p'); do inst /sbin/lvm.static "$MNTIMAGE/bin/lvm" /sbin/lvm.static dumpconfig --config 'log{command_names=0 prefix=" "}' > $MNTIMAGE/etc/lvm/lvm.conf Update /etc/lvm/lvm.conf and set command_names=1, prefix="---" # lvs lvs---LV VG Attr LSize Origin Snap% Move Log Copy% Convert lvs---LogVol00 VolGroup00 -wi-ao 37,91G lvs---LogVol01 VolGroup00 -wi-ao 1,97G # pvs pvs---PV VG Fmt Attr PSize PFree pvs---/dev/vda2 VolGroup00 lvm2 a-- 39,88G 0 # vgs vgs---VG #PV #LV #SN Attr VSize VFree vgs---VolGroup00 1 2 0 wz--n- 39,88G 0 Rebuild the initrd.img: # mkinitrd -f /boot/initrd-2.6.18-300.el5.img $(uname - lvm.conf from the newly generated initrd.img contains: log { verbose=0 syslog=1 overwrite=0 level=0 indent=1 command_names=1 prefix="---" } Reboot: ... skip ... Scanning logical volumes vgscan---Reading all physical volumes. This may take a while... vgscan---Found volume group "VolGroup00" using metadata type lvm2 Activating logical volumes vgchange---2 logical volume(s) in volume group "VolGroup00" now active Trying to resume from /dev/VolGroup00/LogVol01 No suspend signature on swap, not resuming. Creating root device. Mounting root filesystem. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. Setting up other filesystems. Setting up new root fs no fstab.sys, mounting internal defaults Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys type=1404 audit(1323258909.670:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 type=1403 audit(1323258909.866:3): policy loaded auid=4294967295 ses=4294967295 INIT: version 2.86 booting Welcome to Red Hat Enterprise Linux Server Press 'I' to enter interactive startup. Setting clock (localtime): Wed Dec 7 11:55:10 EST 2011 [ OK ] Starting udev: [ OK ] Loading default keymap (us): [ OK ] Setting hostname dhcp70-168.rhts.eng.bos.redhat.com: [ OK ] Setting up Logical Volume Management: vgchange---2 logical volume(s) in volume group "VolGroup00" now active [ OK ] Checking filesystems Checking all file systems. [/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/VolGroup00/LogVol00 /dev/VolGroup00/LogVol00: clean, 34450/9942016 files, 588135/9936896 blocks [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/vda1 /boot: clean, 34/26104 files, 16145/104388 blocks [ OK ] Remounting root filesystem in read-write mode: [ OK ] Mounting local filesystems: [ OK ] Enabling local filesystem quotas: [ OK ] Enabling /etc/fstab swaps: [ OK ] INIT: Entering runlevel: 3 I'm able to login into the system. Moving to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0157.html