Bug 183120 - nash init script use of vgchange too restrictive
nash init script use of vgchange too restrictive
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-26 10:13 EST by Peter Trenholme
Modified: 2008-04-10 17:07 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-10 17:07:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Trenholme 2006-02-26 10:13:53 EST
Description of problem: The nash init script hard-codes the volume group name to
be activated, thus making it impossible to for t a volume group with a different
name. Leaving the name out of the command will activate all volume groups, an
easy fix to impliment.


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


How reproducible: Allways


Steps to Reproduce:
1. Change the name of you boot logical volume.
2. Change grub.conf to use the new name.
3. Attempt to boot.
  
Actual results: New volume group is found, but not activated. Kernel panic results.


Expected results: Normal boot


Additional info: Simple to fix by removing the volume group name from the
vgchange line in the nash init script.

Comment: Why is "lvm vgchange" used instead of "vgchange?"
Comment 1 Peter Jones 2006-02-27 10:35:16 EST
This won't actually work -- leaving it unrestricted means we'll try to bring up
clustered VGs and the like, which will fail.  What's the problem you're actually
trying to solve?
Comment 2 Peter Trenholme 2006-02-28 10:22:55 EST
As I tried to say, I want to be able to boot to a specific volume group (from
GRUB, but that's probably irrelevant), and to be able to change the volume group
names "on the fly" without breaking (or needing to recreate) initrd.

The specific circumstance was a HD failure rendering a partition unreadable, so
the drive wouldn't mount properly. Since other partitions on that drive
contained a FC4  root, we installed a new drive and restored the FC4 from the
backup. But the backups weren't current, so I "fixed" the bad drive. But now I
had two drives, both containing "VolGrp00," and lvm would only "see" one of
these. (By the way, vgscan didn't even report the "duplicate" VG name as an
error.) Renaming the VG of the newer (booting) VG made the older VG visible (and
bootable), but left the newer one unbootable. Changing the vgchange line in init
fixed that problem, and (since I thought the solution fairly easy to implement)
I reported the problem and solution as a bug. (Perhaps a "suggestion for
improvement" would have been a better label.)

Why would a failure to activate other VGs be of any significance? If they cannot
be activated during a boot, they are not be likely to (or, in fact, can not) be
needed during the boot process.

If you think that only activating the VG need for the boot is necessary, then
can you change mkrootdev (for example) to do the activation for the specific
device used by /boot instead of putting it in init?  (I make that suggestion
because, with my current setup, there are at least three "/" directories on my
hard drives, and the boot process seems to be able to figure out which of those
"/" directories needs to be used for a specific boot. I presume the information
comes from the "kernel" line in grub.conf, but I don't really know.  But it
seems clear that the boot process must be "aware" of the actual "/" location to
use for a specific boot, and that location would [I'm guessing here] include the
LV information.)
Comment 3 Christian Iseli 2007-01-22 05:18:30 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 4 Danny L. Schuh 2007-04-19 14:26:26 EDT
This still applies to at least RHEL4.  The mkinitrd script adds this to the
initrd's init script.

I consistantly add drives to systems to work on them via a usb-ide/sata drive
bay.  I recently tried to do this on my own system, which when I loaded, I used
the default LVM naming scheme "VolGroup00".  This causes a conflict with
multiple VGs on the same system (which is reported in syslog, not stderr.)  To
remedy this problem, I needed to rename my VG.  I may submit another bug that
you can't do this from the linux rescue image, but that's off topic.  After
renaming the VG, you must edit the initrd, or it will kernel panic when it can't
mount the root partition.  This is because mkinitrd hardcodes the VG name in the
init script.

lines 736-739 of /sbin/mkinitrd from mkinitrd-4.2.1.8-1
    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

The logic of the init script does a vgscan right before this.  It's output could
be captured and awk'd to make all VGs available:.
Comment 5 Paul Jenner 2007-06-29 14:56:25 EDT
This is causing a new install of F7 to fail to boot for me.

I have an existing LVM2 VG VolGroup01 which contains swap and data file systems.
During the F7 install, I created a new LVM2 VG VolGroup00 which contains the
root filesystem.

On boot, both VGs are found but only LVs on VolGroup01 are activated - and so
the root filesystem cannot then be found or mounted.

If I boot with an alternate root filesystem, everything works fine and I am able
to mount the new root filesystem.

I am currently investigating why the VG on which the root filesystem resides is
not activated in the initrd. I will add more detail then.
Comment 6 Paul Jenner 2007-07-05 16:15:04 EDT
Confirmed in F7.

Tested with a kernel upgrade that mkinitrd builds and initrd that is missing the
Volume Group for the root silesystem fromvgchange command line in nash init file.

I will take a look what is happening but could someone bump the product on this
bug to F7? 
Comment 7 Bug Zapper 2008-04-03 22:08:48 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 8 Paul Jenner 2008-04-05 16:19:38 EDT
I worked around the issue I was seeing in F7 with the root VG not being added to
initrd for activation by mkinitrd by changing /etc/fstab to mount / based on LVM
device path  (/dev/VolGroup00/Root00) instead of label (LABEL=/1). After this
change, mkinitrd "found" the root VG and added it to initrd for activation.

I will file a separate bug if I ever track down the problem.
Comment 9 John Poelstra 2008-04-10 17:07:52 EDT
Thanks for your update.

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