+++ 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 the OS? 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 /boot/lvm/. (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.