Red Hat Bugzilla – Bug 153237
Create post-installation backups of lvm2 metadata
Last modified: 2013-02-08 06:46:34 EST
+++ This bug was initially created as a clone of Bug #153215 +++
I don't know if cloning is the best way to handle this issue, but please see bug
#153215 for the details.
Anaconda needs to create backups of the metadata into the installed filesystem's
/etc/lvm/backup after it's finished doing the lvm2 configuration.
[Run vgcfgbackup -f for each volume group, or copy the files from
/etc/lvm/backup to the equivalent on the installed system]
This should be fixed in lvm2-2.01.08-2.0
The new lvm2 package does not fix problem of the missing backups - only an
anaconda change can do that - has that been done?
e.g. adding the vgcfgbackup step mentioned above
Or setting the environment variable before the installer runs any lvm2 commands
We don't do this with, for example, the partition table the PVs sit on. In what
way does LVM differ in a way that causes this to be an installer issue?
Let's try another tack.
LVM2 expects to use /etc/lvm. You're running it in an artificial environment in
the installer without adjusting the location of that directory - you're writing
to the *wrong* /etc/lvm and then throwing the contents away after running the
commands that have updated it.
When you run rpm from the installer, you specify a non-default location for the
rpm database so the installed system's database gets updated.
You need to do the same with lvm2 by setting that environment variable to tell
it to use /<system>/etc/lvm.
Alternatively, you carry out equivalent steps yourself, or else we hard-code
into 'lvm' how to recognise it's being run by the installer and where the real
/etc/lvm directory is so it can use it.
The "real" lvm directory doesn't exist. It hasn't been created yet.
And you still haven't answered the question from comment #6. Why is lvm special
in this regard? What makes it different from *every* other analogous concept in
Threatening to do things without being prepared to justify why they're needed is
not a very good strategy here. Please don't do that any more.
Peter, can you make your question a little bit clearer?
Different from what? Can you give some examples?
I think it (comment#5 solution b) _is_ very similar to rpm --root.
This problem has come up again twice recently in different contexts.
Firstly the limited lvm2 recovery facilities on the rescue disk.
If your root filesystem is on lvm2, then we need to put recent metadata backups
somewhere accessibly to the recovery disk and outside the root filesystem - this
currently means /boot.
Secondly in clustered environments (without a shared root) you only get a
metadata backup on the node you run the lvm command on, meaning if you need to
use one of the backups you have to search every node to find the most recent one.
So I've changed my mind about adding this to anaconda: we're better off doing it
in the initscripts while booting, to ensure the metadata backups are up-to-date
every time we boot.
The clustered problem can't be solved properly until the activation code rewrite
is completed, but taking fresh backups each time a machine is booted will help.
So 3 changes:
(1) vgscan/vgchange -ay/vgs/vgdisplay should always check that the existing
backup of each VG they process is up-to-date and fix it if it isn't. [silently
continuing if it can't e.g. read-only filesystem] Make sure the commands in the
initscripts will always run code this for every VG (clustered or otherwise)
*after* the root filesystem is remounted read-write.
(2) Add new code to maintain N backups of a VG holding the root filesystem in
(3) Move the 'vgchange -ay' check down into the library 'lvchange -ay' code so
that clvmd will run it.
Needs reassessing to take account of things like dracut and other anaconda changes in the last 5 years.