Bug 503116 - Some VGs are not activated at boot when lvm cache is not uptodate
Some VGs are not activated at boot when lvm cache is not uptodate
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2 (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: LVM and device-mapper development team
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-28 18:58 EDT by Takahiro Yasui
Modified: 2014-07-25 01:07 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-21 12:25:01 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 Takahiro Yasui 2009-05-28 18:58:03 EDT
Description of problem:
  At system boot, vgscan command needs to be called to update lvm cache,
  /etc/lvm/cache/.cache, to keep correct device information, but vgscan
  is called only from init script in initrd and the cache on rootfs is not
  updated because rootfs is not mounted yet.

  If the cache is not uptodate due to some reasons, such as lvm.conf udpate,
  device configuration change, some VGs are not recognized and activated
  by vgchange in rc.sysinit. Moreover, lvm commands, such as vgs and lvs
  will show wrong results even after system boot completed.

Version-Release number of selected component (if applicable):
  Any versions of initscripts in RHEL5

Expected results:
  vgscan is executed after rootfs is mounted and the cache is refreshed
  to keep correct device information. And VGs on all devices excluding
  filtered devices by lvm.conf are activated.

Additional info:
  vgscan was removed from rc.sysinit to fix bug 191879 in RHEL4.5.
Comment 1 Bill Nottingham 2009-05-28 21:43:09 EDT
Is there a reason the tools can't be able to handle an out of date cache when necessary? (Given that the system isn't read/write at that point, perhaps the proper solution is to link the cache to /dev/null.
Comment 2 Alasdair Kergon 2009-05-28 22:40:19 EDT
It depends how the tools are used...

If you don't specify a list of VGs in a command and the cache exists, it should use the cache to determine which devices to use - other devices will be ignored.  It's for initrd/initscripts to deal with that e.g. making the cache dir writable and retaining it across pivotroot, or having the dir empty.  (Its location can be overridden if that makes things easier to copy it about.)

Alternatively if you do specify a list of VGs and any of the VG names cannot be found, it will automatically rescan to search for it.

Ultimately, we should have both: the list of VGs to be activated at boot should be specified, and the cache files should be moved around so they are always writable and retained.

But as we get further along with the udev/upstart integration work, this will probably all end up changing anyway.
Comment 4 Milan Broz 2011-10-21 12:25:01 EDT
With change to reading list of block devices from udev cache becomes obsolete (not used), so in RHEL6.2 this should now work.

For RHEL5 we do not plan to change this functionality, administrator should run vgscan to update cache if you want vgchange without VG specified to run properly.

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