Bug 153237 - Create post-installation backups of lvm2 metadata
Create post-installation backups of lvm2 metadata
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: LVM and device-mapper development team
: FutureFeature
Depends On: 153215
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-03 17:25 EDT by Ronny Buchmann
Modified: 2013-02-08 06:46 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-27 19:12:29 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 Ronny Buchmann 2005-04-03 17:25:02 EDT
+++ 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.
Comment 1 Alasdair Kergon 2005-04-04 12:34:34 EDT
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]
Comment 4 Jeremy Katz 2005-04-27 19:12:29 EDT
This should be fixed in lvm2-2.01.08-2.0
Comment 5 Alasdair Kergon 2005-04-28 08:41:21 EDT
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
Comment 6 Peter Jones 2005-05-04 15:45:16 EDT
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?
Comment 7 Alasdair Kergon 2005-05-05 17:24:11 EDT
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.
Comment 8 Alasdair Kergon 2005-05-05 17:29:02 EDT
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.
Comment 9 Peter Jones 2005-05-05 22:45:42 EDT
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.
Comment 10 Ronny Buchmann 2005-05-14 05:09:10 EDT
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. 
Comment 11 Alasdair Kergon 2005-05-16 10:03:10 EDT
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.
Comment 12 Alasdair Kergon 2005-05-16 10:12:17 EDT
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.
Comment 13 Alasdair Kergon 2010-04-27 09:56:21 EDT
Needs reassessing to take account of things like dracut and other anaconda changes in the last 5 years.

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