Problem with UUID, vgscan, vgcfgrestore
Hi,
I've a LVM of 8 physical volumes that I've created with LVM 0.9.1 beta 2. I've the know problem that vgscan reports that it can't find my VG. So I upgraded to LVM 0.9.1 beta 6 (tools and kernel) and runned on each physical disk a vgcfgrestore. Unfortunately I didn't solve the problem. Attached is the output of the commands vgdisplay -v and a pvdata -U for each physical disk. Debug logs a very huge so I won't attach them.
Thanks
Quoted 6 lines · Diederick van Dijk
I've a LVM of 8 physical volumes that I've created with LVM 0.9.1 beta 2. I've the know problem that vgscan reports that it can't find my VG. So I upgraded to LVM 0.9.1 beta 6 (tools and kernel) and runned on each physical disk a vgcfgrestore. Unfortunately I didn't solve the problem. Attached is the output of the commands vgdisplay -v and a pvdata -U for each physical disk. Debug logs a very huge so I won't attach them.
OK, I have figured out why vgcfgrestore doesn't work properly with broken UUIDs. It is because vgcfgrestore only restores the backup VGDA data to each disk separately. This means it is not possible to have consistent UUIDs generated for all PVs in a VG when vgcfgrestore is run.
You can try the following (experimental) procedure to fix the UUIDs:
Check each PV with "pvdata -PP /dev/hdX" to ensure it has a valid UUID assigned. Also get the PV numbers (starting with 1) for each of the PVs. Finally, check the pv_uuidlist_on_disk.base for each PV. It will normally be 6144, but it does not have to be.
for each PV (in PV# order)
dd if=/dev/hdX bs=1 skip=44 count=128 >> /tmp/uuids
This should create a file /tmp/uuids which has all of the PV UUIDs in it. Make sure there are as many UUIDs in the file ("od -a /tmp/uuids" is good) as you have PVs (8 in your case).
Now, we want to write the UUID list back to the PVs so vgscan is happy:
for each PV (in any order)
dd if=/tmp/uuids of=/dev/hdX bs=1 seek=<pv_uuidlist_on_disk.base for hdX>
example:
dd if=/tmp/uuids of=/dev/hda2 bs=1 seek=6144
Now vgscan should be able to detect all of the disks and work properly.
Cheers, Andreas
Signature · 3 lines
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- DogbertQuoted 27 lines · you
Quoted 6 lines · Diederick van Dijk
I've a LVM of 8 physical volumes that I've created with LVM 0.9.1 beta 2. I've the know problem that vgscan reports that it can't find my VG. So I upgraded to LVM 0.9.1 beta 6 (tools and kernel) and runned on each physical disk a vgcfgrestore. Unfortunately I didn't solve the problem. Attached is the output of the commands vgdisplay -v and a pvdata -U for each physical disk. Debug logs a very huge so I won't attach them.
OK, I have figured out why vgcfgrestore doesn't work properly with broken UUIDs. It is because vgcfgrestore only restores the backup VGDA data to each disk separately. This means it is not possible to have consistent UUIDs generated for all PVs in a VG when vgcfgrestore is run.
You can try the following (experimental) procedure to fix the UUIDs:
Check each PV with "pvdata -PP
/dev/hdX" to ensure it has a valid UUID assigned. Also get the PV numbers (starting with 1) for each of the PVs. Finally, check the pv_uuidlist_on_disk.base for each PV. It will normally be 6144, but it does not have to be.for each PV (in PV# order)
dd if=/dev/hdX bs=1 skip=44 count=128 >> /tmp/uuidsThis should create a file
/tmp/uuidswhich has all of the PV UUIDs in it. Make sure there are as many UUIDs in the file ("od -a/tmp/uuids" is good) as you have PVs (8 in your case).
Quoted 5 lines
Now, we want to write the UUID list back to the PVs so vgscan is happy:
for each PV (in any order)
dd if=/tmp/uuids of=/dev/hdX bs=1 seek=<pv_uuidlist_on_disk.base for
hdX>
Unfortunately this doesn't work. I get on of=/dev/hda2 an invalid argument. Can you write to a partition with dd ? Or has it to be a disk such as /dev/hda ?
Quoted 7 lines
example:
dd if=/tmp/uuids of=/dev/hda2 bs=1 seek=6144Now vgscan should be able to detect all of the disks and work properly.
Cheers, Andreas
Quoted 23 lines · Diederick van Dijk
Quoted 22 lines · you
Quoted 6 lines · Diederick van Dijk
I've a LVM of 8 physical volumes that I've created with LVM 0.9.1 beta 2. I've the know problem that vgscan reports that it can't find my VG. So I upgraded to LVM 0.9.1 beta 6 (tools and kernel) and runned on each physical disk a vgcfgrestore. Unfortunately I didn't solve the problem. Attached is the output of the commands vgdisplay -v and a pvdata -U for each physical disk. Debug logs a very huge so I won't attach them.
You can try the following (experimental) procedure to fix the UUIDs:
Check each PV with "pvdata -PP
/dev/hdX" to ensure it has a valid UUID assigned. Also get the PV numbers (starting with 1) for each of the PVs. Finally, check the pv_uuidlist_on_disk.base for each PV. It will normally be 6144, but it does not have to be.for each PV (in PV# order)
dd if=/dev/hdX bs=1 skip=44 count=128 >>/tmp/uuidsThis should create a file
/tmp/uuidswhich has all of the PV UUIDs in it. Make sure there are as many UUIDs in the file ("od -a/tmp/uuids" is good) as you have PVs (8 in your case).
Quoted 8 lines
Quoted 4 lines
Now, we want to write the UUID list back to the PVs so vgscan is happy:
for each PV (in any order)
dd if=/tmp/uuids of=/dev/hdX bs=1 seek=<pv_uuidlist_on_disk.base for hdX>Unfortunately this doesn't work. I get on of=/dev/hda2 an invalid argument. Can you write to a partition with dd ? Or has it to be a disk such as
/dev/hda?
Should work fine writing to /dev/hda2. The only thing that _may_ be an issue is that we are not writing aligned sectors to the disk, but under Linux even the "raw" disk devices are buffered I/O. I just tested the above commands under 2.2.18 and it worked fine and my VG is still alive.
Can you send the exact command-line you are using? Also useful would be pvdata -PP for each disk in the VG. If you are sure you are using the correct command-line for dd, you could try running it under "strace" to see where it is getting -EINVAL from.
Cheers, Andreas
Signature · 3 lines
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- DogbertQuoted 40 lines · you
Quoted 26 lines · Diederick van Dijk
Quoted 25 lines · you
Quoted 7 lines · Diederick van Dijk
I've a LVM of 8 physical volumes that I've created with LVM 0.9.1 beta 2. I've the know problem that vgscan reports that it can't find my VG. So I upgraded to LVM 0.9.1 beta 6 (tools and kernel) and runned on each physical disk a vgcfgrestore. Unfortunately I didn't solve the problem. Attached is the output of the commands vgdisplay -v and a pvdata -U for each physical disk. Debug logs a very huge so I won't attach them.
You can try the following (experimental) procedure to fix the UUIDs:
Check each PV with "pvdata -PP
/dev/hdX" to ensure it has a valid UUID assigned. Also get the PV numbers (starting with 1) for each of the PVs. Finally, check the pv_uuidlist_on_disk.base for each PV. It will normally be 6144, but it does not have to be.for each PV (in PV# order)
dd if=/dev/hdX bs=1 skip=44 count=128 >>/tmp/uuidsThis should create a file
/tmp/uuidswhich has all of the PV UUIDs in it. Make sure there are as many UUIDs in the file ("od -a/tmp/uuids" is good) as you have PVs (8 in your case).Now, we want to write the UUID list back to the PVs so vgscan is happy:
Quoted 7 lines
Quoted 3 lines
for each PV (in any order)
dd if=/tmp/uuids of=/dev/hdX bs=1 seek=<pv_uuidlist_on_disk.base for
hdX>Unfortunately this doesn't work. I get on of=/dev/hda2 an invalid argument. Can you write to a partition with dd ? Or has it to be a disk such as
/dev/hda?Should work fine writing to
/dev/hda2. The only thing that _may_ be an issue is that we are not writing aligned sectors to the disk, but under Linux even the "raw" disk devices are buffered I/O. I just tested the above commands under 2.2.18 and it worked fine and my VG is still alive.
Quoted 6 lines
Can you send the exact command-line you are using? Also useful would be pvdata -PP for each disk in the VG. If you are sure you are using the correct command-line for dd, you could try running it under "strace" to see where it is getting
-EINVALfrom.Cheers, Andreas
Ok Andreas,
My current system is on kernel 2.4.2 with LVM support build into the kernel. So I booted with a 2.2.18 kernel with no LVM support what so ever and the dd commands worked fine. Then I booted with the 2.4.2 kernel again and did a vgscan and this worked too ! I checked the UUID's on the PV's with pvdata -U /dev/hdxx and the UUID lists are now as they have to be. If guess that LVM support in the kernel and dd were in conflict. To check that I will boot with a 2.4.2 kernel without LVM support and try the dd dd commands later on.
Thanks from a happy Diederick
Quoted 51 lines · you
Quoted 41 lines · you
Quoted 27 lines · Diederick van Dijk
Quoted 26 lines · you
Quoted 7 lines · Diederick van Dijk
I've a LVM of 8 physical volumes that I've created with LVM 0.9.1 beta 2. I've the know problem that vgscan reports that it can't find my VG. So I upgraded to LVM 0.9.1 beta 6 (tools and kernel) and runned on each physical disk a vgcfgrestore. Unfortunately I didn't solve the problem. Attached is the output of the commands vgdisplay -v and a pvdata -U for each physical disk. Debug logs a very huge so I won't attach them.
You can try the following (experimental) procedure to fix the UUIDs:
Check each PV with "pvdata -PP
/dev/hdX" to ensure it has a valid UUID assigned. Also get the PV numbers (starting with 1) for each of the PVs. Finally, check the pv_uuidlist_on_disk.base for each PV. It will normally be 6144, but it does not have to be.for each PV (in PV# order)
dd if=/dev/hdX bs=1 skip=44 count=128 >>/tmp/uuidsThis should create a file
/tmp/uuidswhich has all of the PV UUIDs in it. Make sure there are as many UUIDs in the file ("od -a/tmp/uuids" is good) as you have PVs (8 in your case).Now, we want to write the UUID list back to the PVs so vgscan is happy:
Quoted 7 lines
Quoted 3 lines
for each PV (in any order)
dd if=/tmp/uuids of=/dev/hdX bs=1 seek=<pv_uuidlist_on_disk.base
for hdX>Unfortunately this doesn't work. I get on of=/dev/hda2 an invalid argument. Can you write to a partition with dd ? Or has it to be a disk such as
/dev/hda?Should work fine writing to
/dev/hda2. The only thing that _may_ be an issue is that we are not writing aligned sectors to the disk, but under Linux even the "raw" disk devices are buffered I/O. I just tested the above commands under 2.2.18 and it worked fine and my VG is still alive.Quoted 6 lines
Can you send the exact command-line you are using? Also useful would be pvdata -PP for each disk in the VG. If you are sure you are using the correct command-line for dd, you could try running it under "strace" to see where it is getting
-EINVALfrom.Cheers, Andreas
Ok Andreas,
Quoted 8 lines
My current system is on kernel 2.4.2 with LVM support build into the kernel. So I booted with a 2.2.18 kernel with no LVM support what so ever and the dd commands worked fine. Then I booted with the 2.4.2 kernel again and did a vgscan and this worked too ! I checked the UUID's on the PV's with pvdata -U
/dev/hdxxand the UUID lists are now as they have to be. If guess that LVM support in the kernel and dd were in conflict. To check that I will boot with a 2.4.2 kernel without LVM support and try the dd dd commands later on.
Ok, I tested the dd commands with the 2.4.2 kernel without LVM support and had no success.
Thanks,
Diederick
Quoted 10 lines · Diederick van Dijk
Quoted 8 lines · Diederick van Dijk
My current system is on kernel 2.4.2 with LVM support build into the kernel. So I booted with a 2.2.18 kernel with no LVM support what so ever and the dd commands worked fine. Then I booted with the 2.4.2 kernel again and did a vgscan and this worked too ! I checked the UUID's on the PV's with pvdata -U
/dev/hdxxand the UUID lists are now as they have to be. If guess that LVM support in the kernel and dd were in conflict. To check that I will boot with a 2.4.2 kernel without LVM support and try the dd dd commands later on.
Quoted 2 lines
Ok, I tested the dd commands with the 2.4.2 kernel without LVM support and had no success.
Strange. I just tried (on a 2.4.2 kernel):
# dd if=/dev/hda2 bs=1 skip=44 count=128 of=/tmp/uuids 128+0 records in 128+0 records out # dd of=/dev/hda2 bs=1 seek=44 count=128 if=/tmp/uuids 128+0 records in 128+0 records out
It worked with no problems. Maybe there is something strange about the version of dd that you have? I have:
# dd --version dd (GNU fileutils) 4.0.35
Can you try running "strace dd of=/dev/hda2 bs=1 seek=6144 if=/tmp/uuids" and see where it gets the error from?
Cheers, Andreas
Signature · 3 lines
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- DogbertQuoted 23 lines · you
Quoted 10 lines · Diederick van Dijk
Quoted 8 lines · Diederick van Dijk
My current system is on kernel 2.4.2 with LVM support build into the kernel. So I booted with a 2.2.18 kernel with no LVM support what so ever and the dd commands worked fine. Then I booted with the 2.4.2 kernel again and did a vgscan and this worked too ! I checked the UUID's on the PV's with pvdata -U
/dev/hdxxand the UUID lists are now as they have to be. If guess that LVM support in the kernel and dd were in conflict. To check that I will boot with a 2.4.2 kernel without LVM support and try the dd dd commands later on.Quoted 2 lines
Ok, I tested the dd commands with the 2.4.2 kernel without LVM support and had no success.
Strange. I just tried (on a 2.4.2 kernel):
# dd if=/dev/hda2 bs=1 skip=44 count=128 of=/tmp/uuids 128+0 records in 128+0 records out # dd of=/dev/hda2 bs=1 seek=44 count=128 if=/tmp/uuids 128+0 records in 128+0 records out
Quoted 5 lines
It worked with no problems. Maybe there is something strange about the version of dd that you have? I have:
# dd --version dd (GNU fileutils) 4.0.35
]# dd --version
dd (GNU fileutils) 4.0p
Quoted 3 lines
Can you try running "strace dd of=/dev/hda2 bs=1 seek=6144 if=/tmp/uuids" and see where it gets the error from?
# strace dd of=/dev/hda2 bs=1 seek=6144 if=/etc/uuids
execve("/bin/dd", ["dd", "of=/dev/hda2", "bs=1", "seek=6144",
"if=/etc/uuids"],
[/* 25 vars */]) = 0
brk(0) = 0x8050848
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0
x40013000
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=33088, ...}) = 0
old_mmap(NULL, 33088, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=931668, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210\215"..., 4096) =
40
96
old_mmap(NULL, 946076, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001d000
mprotect(0x400fc000, 32668, PROT_NONE) = 0
old_mmap(0x400fc000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xde
000) = 0x400fc000
old_mmap(0x40101000, 12188, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANON
YMOUS, -1, 0) = 0x40101000
close(3) = 0
mprotect(0x4001d000, 913408, PROT_READ|PROT_WRITE) = 0
mprotect(0x4001d000, 913408, PROT_READ|PROT_EXEC) = 0
munmap(0x40014000, 33088) = 0
getpid() = 2928
brk(0) = 0x8050848
brk(0x8050880) = 0x8050880
brk(0x8051000) = 0x8051000
close(0) = 0
open("/etc/uuids", O_RDONLY|O_LARGEFILE) = 0
close(1) = 0
open("/dev/hda2", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 1
ftruncate64(0x1, 0x1800, 0, 0, 0x1) = -1 EINVAL (Invalid argument)
write(2, "dd: ", 4dd: ) = 4
write(2, "/dev/hda2", 9/dev/hda2) = 9
write(2, ": Invalid argument", 18: Invalid argument) = 18
write(2, "\n", 1
) = 1
_exit(1) = ?Thanks,
Diederick
Quoted 6 lines · Diederick van Dijk
]# dd --version
dd (GNU fileutils) 4.0p# strace dd of=/dev/hda2 bs=1 seek=6144 if=/etc/uuids open("/dev/hda2", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 1 ftruncate64(0x1, 0x1800, 0, 0, 0x1) = -1 EINVAL (Invalid argument)
Strange, it is trying to truncate the block device! You need to add the option "conv=notrunc" to "dd" so that it will not do this. It really shouldn't try truncating a block device, so maybe this is a bug? I don't know if "GNU fileutils 4.0p" is newer or older than "GNU fileutils 4.0.35". If you update to the latest fileutils and it still has this problem, I suggest submitting a bug report.
In any case, it is not so important because you already have your VG back, but good to know for future reference.
Cheers, Andreas
Signature · 3 lines
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- DogbertOh yes, this procedure has helped me too! I had the same problem and now I can use my VG with no single byte being lost. But from now on I'll start making backups of my data... :) Thanks!
Quoted 33 lines
Quoted 19 lines
OK, I have figured out why vgcfgrestore doesn't work properly with broken UUIDs. It is because vgcfgrestore only restores the backup VGDA data to each disk separately. This means it is not possible to have consistent UUIDs generated for all PVs in a VG when vgcfgrestore is run.
You can try the following (experimental) procedure to fix the UUIDs:
Check each PV with "pvdata -PP
/dev/hdX" to ensure it has a valid UUID assigned. Also get the PV numbers (starting with 1) for each of the PVs. Finally, check the pv_uuidlist_on_disk.base for each PV. It will normally be 6144, but it does not have to be.for each PV (in PV# order)
dd if=/dev/hdX bs=1 skip=44 count=128 >> /tmp/uuidsThis should create a file
/tmp/uuidswhich has all of the PV UUIDs in it. Make sure there are as many UUIDs in the file ("od -a/tmp/uuids" is good) as you have PVs (8 in your case).Quoted 5 lines
Now, we want to write the UUID list back to the PVs so vgscan is happy:
for each PV (in any order)
dd if=/tmp/uuids of=/dev/hdX bs=1 seek=<pv_uuidlist_on_disk.base for
hdX>Unfortunately this doesn't work. I get on of=/dev/hda2 an invalid argument. Can you write to a partition with dd ? Or has it to be a disk such as
/dev/hda?Quoted 4 lines
example:
dd if=/tmp/uuids of=/dev/hda2 bs=1 seek=6144
Quoted 8 lines
Quoted 3 lines
Now vgscan should be able to detect all of the disks and work properly.
Cheers, Andreas
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
--
------------------------------------------------------------------------
David Vidal R. ([email protected])
http://dvr.ismad.com
"Ein Computer ohne Windows ist wie ein Fisch ohne Fahrrad."
Thanks Andreas for providing this workaround.
The bug causing wrong UUID lists on the PVs has been fixed in LVM 0.9.1 Beta 4 but VGs created/configured with < Beta 4 this still hit us regularly.
It is likely the major reason for the upshowing
"vgscan doesn't find my VGs" problem.
If you send us compressed copies of your LVM metadata (VGDA) taken by
for each pv
do
of=basename $pv
dd if=$pv of=$of bs=1k count=1000;
bzip2 $of
done
this will help us to get a better understanding if the above assumption holds up. We can even provide a vgscan auto uuid update function to avoid that trouble once we know for sure.
Thanks,
Heinz -- The LVM Guy --
Quoted 53 lines · David Vidal Rodriguez
Oh yes, this procedure has helped me too! I had the same problem and now I can use my VG with no single byte being lost. But from now on I'll start making backups of my data... :) Thanks!
Quoted 33 lines
Quoted 19 lines
OK, I have figured out why vgcfgrestore doesn't work properly with broken UUIDs. It is because vgcfgrestore only restores the backup VGDA data to each disk separately. This means it is not possible to have consistent UUIDs generated for all PVs in a VG when vgcfgrestore is run.
You can try the following (experimental) procedure to fix the UUIDs:
Check each PV with "pvdata -PP
/dev/hdX" to ensure it has a valid UUID assigned. Also get the PV numbers (starting with 1) for each of the PVs. Finally, check the pv_uuidlist_on_disk.base for each PV. It will normally be 6144, but it does not have to be.for each PV (in PV# order)
dd if=/dev/hdX bs=1 skip=44 count=128 >> /tmp/uuidsThis should create a file
/tmp/uuidswhich has all of the PV UUIDs in it. Make sure there are as many UUIDs in the file ("od -a/tmp/uuids" is good) as you have PVs (8 in your case).Quoted 5 lines
Now, we want to write the UUID list back to the PVs so vgscan is happy:
for each PV (in any order)
dd if=/tmp/uuids of=/dev/hdX bs=1 seek=<pv_uuidlist_on_disk.base for
hdX>Unfortunately this doesn't work. I get on of=/dev/hda2 an invalid argument. Can you write to a partition with dd ? Or has it to be a disk such as
/dev/hda?Quoted 4 lines
example:
dd if=/tmp/uuids of=/dev/hda2 bs=1 seek=6144Quoted 8 lines
Quoted 3 lines
Now vgscan should be able to detect all of the disks and work properly.
Cheers, Andreas
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm--
------------------------------------------------------------------------
David Vidal R. ([email protected])
http://dvr.ismad.com
"Ein Computer ohne Windows ist wie ein Fisch ohne Fahrrad."
Quoted 4 lines
_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I'll send them tomorrow. You say that there are problems with VGs created with <beta4. My kernel is has beta2-lvm, and because of compiling errors in the newer beta6+-versions, I couldn't update the driver (tools are actually working). Is there a way to [sozusagen] update the on-disc structures in order to avoid conflicts with the new tools?
--
------------------------------------------------------------------------
David Vidal R. ([email protected])
Quoted 5 lines · David Vidal
I'll send them tomorrow. You say that there are problems with VGs created with <beta4. My kernel is has beta2-lvm, and because of compiling errors in the newer beta6+-versions, I couldn't update the driver (tools are actually working). Is there a way to [sozusagen] update the on-disc structures in order to avoid conflicts with the new tools?
It doesn't matter what version the kernel code is, as long as the tools are newer than beta2 you are OK. If the on-disk UUIDs are bad, then all you need to do is some sort of simple change (add a 1 PE LV and remove it), and the on-disk VGDA should be re-written with the correct UUIDs.
You can check the on-disk UUIDs with "pvdata -U" for each PV. They should all match.
Cheers, Andreas
Signature · 3 lines
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- DogbertQuoted 7 lines · Andreas Dilger
Quoted 5 lines · David Vidal
I'll send them tomorrow. You say that there are problems with VGs created with <beta4. My kernel is has beta2-lvm, and because of compiling errors in the newer beta6+-versions, I couldn't update the driver (tools are actually working). Is there a way to [sozusagen] update the on-disc structures in order to avoid conflicts with the new tools?
Quoted 8 lines
It doesn't matter what version the kernel code is, as long as the tools are newer than beta2 you are OK. If the on-disk UUIDs are bad, then all you need to do is some sort of simple change (add a 1 PE LV and remove it), and the on-disk VGDA should be re-written with the correct UUIDs.
You can check the on-disk UUIDs with "pvdata -U" for each PV. They should all match.
I am about to implement a vgscan option in order to support the recreation of the "invalid PV UUID list problem" in case a VG can't be found by vgscan any more.
What's your opinion (Andreas?) about it?
Do we have too many people which can't do the lvcreate/lvremove trick so that this work makes sense?
Quoted 10 lines
Cheers, Andreas
Signature · 7 lines
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert _______________________________________________ linux-lvm mailing list [email protected] http://lists.sistina.com/mailman/listinfo/linux-lvm
Signature · 15 lines
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Quoted 8 lines · Heinz
I am about to implement a vgscan option in order to support the recreation of the "invalid PV UUID list problem" in case a VG can't be found by vgscan any more.
What's your opinion (Andreas?) about it?
Do we have too many people which can't do the lvcreate/lvremove trick so that this work makes sense?
It is surely a fix for some of the problems. Of course, the need for the fix will be reduced as time goes on, so maybe a comment/#ifdef on the code so that it will be removed at a later date.
Cheers, Andreas
Signature · 3 lines
Andreas Dilger Turbolinux filesystem development http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 11 lines · Andreas Dilger
Quoted 8 lines · Heinz
I am about to implement a vgscan option in order to support the recreation of the "invalid PV UUID list problem" in case a VG can't be found by vgscan any more.
What's your opinion (Andreas?) about it?
Do we have too many people which can't do the lvcreate/lvremove trick so that this work makes sense?
It is surely a fix for some of the problems.
Which other problems do you see and are you able to define?
Quoted 2 lines
Of course, the need for the
fix will be reduced as time goes on,
That's why I asked in the first place.
Maybe the /etc/lvmconf/ to /etc/lvmtab.d/ copy and echo to /etc/lvmtab trick plus "vgchange -ay" and dummy change on VGs does it anyway?
Quoted 12 lines
so maybe a comment/#ifdef on the code
so that it will be removed at a later date.Cheers, Andreas
Signature · 7 lines
Andreas Dilger Turbolinux filesystem development http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ _______________________________________________ linux-lvm mailing list [email protected] http://lists.sistina.com/mailman/listinfo/linux-lvm
Signature · 15 lines
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-