Robie Basak schreef op 23-01-2017 12:05:
On Sat, Jan 21, 2017 at 10:02:11AM +0100, Xen wrote:
The version of LVM that ships with 16.04 cannot handle duplicate
UUIDs.
If you so much as DD a disk to another drive and run a single LVM
command,
your running system will be ruined.
Is there a bug report on this somewhere, please, with detailed steps on
how to reproduce?
I have no clue, but they knew about this issue.
David Teigland of LVM (Red Hat) wrote:
"The handling of duplicate PVs has been entirely redone in recent
versions.
The problems you are having are well known and should now be fixed."
In reponse to my query and complaints ;-).
I then went on to change my sources.list to get for the moment 16.10
"main" as well and upgraded LVM2.
At that point I was able to "import" the duplicate VG using
"vgimportclone" which changes the UUIDs of the PV and VG and LVs, of the
PV and LVs, I wanted to say, as well as that of the VG itself.
Which was another thing that didn't work. You are supposed to use
vgimportclone after the import, but that even didn't work properly.
I mean after the duplication.
You're supposed to first do the "dd" and then run "vgimportclone" but
both failed in the sense that...
Well, whatever.
You catch the drift.
Sorry for writing such a long message again. LVM team (Red Had) has now
recognised, LVM2 has now recognised, LVM2 team has now recognised...
these issues and they are already fixed in newer versions, which is
probably why they recognise it now after the fact because I had already
asked back in the summer and got a negative reply then.
In any case the problems are apparently well known and have been fixed.
But the fixes are in 16.10 but not in 16.04 in that sense.
Perhaps you could say the intent of my message is to urge a newer
version for 16.04 as well, but that is up to you. I just wanted to state
the issues here.
I guess the reference here is:
https://www.redhat.com/archives/linux-lvm/2017-January/msg00011.html
I did not then mention the data corruption (yet) so Teigland didn't
actually respond to THAT. I mean to say that he responded to the issue
of LVM randomly changing whatever "backing device" it uses.
Whatever backing PV it uses.
However he suggests that the handling of duplicates has been entirely
redone.
Steps to reproduce would be simple:
1. DD your entire disk including partition table to another drive.
2. Run a single LVM command.
3. LVM will now -- sometimes -- -- often times -- start replacing the
backing device of your earlier partitions.
4. If this actually happens (it might also choose to stick to the old,
but maybe it always chooses the "higher" number (sdb over sda) so if you
are backing up to a "later attached" drive this will probably happen) --
you will get the data corruption I mention.
But I don't see much the point of writing a detailed bug report, sorry.
I also do not have the logs of the resulting fsck etc.
Also, since it is fixed, it would only be a bug against Ubuntu and not
LVM.
It would probably (very very likely I think) not be possible to
reproduce it with the newer versions (as long as it goes from 16.10, in
that sense).
So the only thing you can do to ascertain this yourself is to:
1. Do it with 16.04
2. Do it with 16.10
3. Notice the difference, or
1. DD to a higher-numbered disk
2. Run LVM command
3. See if anything happens.
If it starts replacing the PV you are currently using, you are probably
in trouble.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
