[linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Diederick van Dijk]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

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



[-- Attachment #2: log-lvm.gz --]
[-- Type: application/x-gzip, Size: 1119 bytes --]

\x1f‹\b\b‡\x10È:\0\x03log-lvm\0í™Ërâ:\x10†÷~
UeÃ,\x1alùÎj Ü\x12B„©³\x10X€\x13À`^[^[xú#AN\x06B`Âà\x1c²@\vŠr·õKýuKtñËu\x1cÿç3µlÄ¿ýs…&E|‚ \x12\x16\r\x12\x03‹`\x01\0НíùÈé¡É`áÙ]2D3œ(j4n2\x1eb\x1e\x02\x12DQL¢Ð\fSÔ\0ª×\f¨X½\x06Ô3Ú\x02Â|ö\x1a–ùA\x0ej¢ÒJ\aÌWJ"õ±CÒ
t\v\x1d
öí<\vYªw`>ÍMÁJ‰>ܶiµSg¾8‰î+ƒRö\x05f-+\x0f÷µ¶	…|\x7f\f%£W\aâx\x01<Ë/…û\x17æ+'Ñm»ðä„ð\(bhÕ–\x05hëË^[3Æ5àœ–ƒ^¹žš7˜¯’D¶ýŒ§-(^g\x06@p³\x03ÓÇv\x17Ô\x056AëÞõÙ\x1aìLYa¾j\x12MLÚ\x1a@\x1e\x14l°ú)^[òJÛ†þ²—\x01ã‘ê`Íܪf1_-‰\fBÌT	Ìqi\x0e%,åA\x1dUó0\x1d-
P««e(†E³b2_=ÉDz¥rýi\x15Há×'¨ÈÇQñk:}Ì@‘Œ«ð¤/Š¾\x15CèMC^[r™*\x05«Fˆ\¹P9JGºÔÊ7¤r9Á¾#\x15åBå^[RQ/T¾!\x15íBå^[RÑ/Tþg*|ì’	ú–íM†d X!i®	ô]g6Y½ØÌ£{žl \x0f|\x1anMu»Ôó¶¬.%V"tmŸr‡šOüÙ¶\x03	ˆ=$!M¸Ô³—ü^[÷¼B;C\x14J©Gt×|ÿ\x1c«šp=s?°\x18ÂÄŽw\rÆ\x7f3Õìåæv°ªÆM\x13åÓB‰ÌQy¯Ò®Å\x10R]ÿÃç|×Û*|Hf\x1c+\¨œýȬ RZ¨;>«\x03æ°m2±&¤†C§ËM‰Í·™IfOøÜ2Ÿ;çRfzïµrÁ\€-—×;í§fª\x1c6!»HKð0^[Ü‚Y4úpó0š‚\™Ë0Èš\x13u,¬«Öéo\x16+O\x12\x16Õ\x0f’d]í¯©’\bÃpO2½e\x13›¦Å³æ]Nm¤\x13Ç·›N¿ó‰;|EH\x12®ÃÓb×°›\x11«ãæ*ž\f½KÇ>ºÛF¢«â\x1a\bñ©µmÜ0Ùζâ˜Î}Ôc„„*Û\x13"\x03þéÑ®ï¸ë\x1dIX\x14ÒìÕ\x17ÄBgw7W¥\x1aIñ$\0ž3sYXÏ\a\x01\x1f\rAŽ›Ò\x01\b\x12»\x1cöQØ´EŒA:	C0
‰KÏGAþ\v
Šq€‚aî…°aŠ˜\x01>‰ÁÌsÏ\a@9\x1a€\x1a7´Ce \x1e(\x03õËÊ@>	ÁÀ\x19±\bÔ£\x19HqE?À@Öµ}\b6L\x11\x13PN;ˆÈ\x19‹@;\x1e\0;Ðù\x0f˜=\0ðþ\v\x19\x7fÙ…¬ž\x04À\x1fMÎ\a@?þ\x14:\x18\x7f	«{Ϡߦˆã¯öƒ($g\x04`\x1c_\x01Ø8\0@Æ{\x0f üEá×Y\x7fŽV\x04ÊÛ\x1düºy/¿2ˆ]ýØxïíÏ1\x143~pŸCý!k[Èzé«P¾uG	´êsÖ}’Ì»^[™­ä° ŒbR4‚:»
\x12¬5ýƒbGB1%\x1aE~\x7fJ’EUŽFÒеO)*(†#Ú¤ˆ¥OIª(¦E#É®†O)j(¦G´ÉU»þgE\x1dÅÔˆÊã\x15ä¿É¿²O²\x1e\0\0

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Andreas Dilger]

Diederick van Dijk writes:
> 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
-- 
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

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Diederick van Dijk]

On Monday 02 April 2001 23:00, you wrote:
> Diederick van Dijk writes:
> > 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>

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 ?

>
> 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

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Andreas Dilger]

Diederick van Dijk writes:
> On Monday 02 April 2001 23:00, you wrote:
> > Diederick van Dijk writes:
> > > 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/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>
>
> 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
-- 
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

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Diederick van Dijk]

On Tuesday 03 April 2001 08:23, you wrote:
> Diederick van Dijk writes:
> > On Monday 02 April 2001 23:00, you wrote:
> > > Diederick van Dijk writes:
> > > > 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/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>
> >
> > 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

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

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Diederick van Dijk]

On Tuesday 03 April 2001 09:51, you wrote:
> On Tuesday 03 April 2001 08:23, you wrote:
> > Diederick van Dijk writes:
> > > On Monday 02 April 2001 23:00, you wrote:
> > > > Diederick van Dijk writes:
> > > > > 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/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>
> > >
> > > 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
>
> 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.

Ok, I tested the dd commands with the 2.4.2 kernel without LVM support and 
had no success.

Thanks,

Diederick

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Andreas Dilger]

Diederick van Dijk writes:
> Diederick van Dijk writes:
> > 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.
> 
> 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
-- 
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

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Diederick van Dijk]

On Tuesday 03 April 2001 23:36, you wrote:
> Diederick van Dijk writes:
> > Diederick van Dijk writes:
> > > 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.
> >
> > 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

]# dd --version
dd (GNU fileutils) 4.0p

>
> 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

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Andreas Dilger]

Diederick van Dijk writes:
> ]# 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
-- 
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

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[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!

> > 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>
>
> 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 ?
>
> >
> > 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
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

--
  ------------------------------------------------------------------------
 David Vidal R. (vidalrod@in.tum.de)
 http://dvr.ismad.com
 "Ein Computer ohne Windows ist wie ein Fisch ohne Fahrrad."

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[David Vidal Rodriguez]

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. (vidalrod@in.tum.de)

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Heinz J. Mauelshagen]

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 --

On Wed, Apr 25, 2001@01:51:03PM +0200, David Vidal Rodriguez wrote:
> 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!
> 
> > > 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>
> >
> > 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 ?
> >
> > >
> > > 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
> >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> 
> --
>   ------------------------------------------------------------------------
>  David Vidal R. (vidalrod@in.tum.de)
>  http://dvr.ismad.com
>  "Ein Computer ohne Windows ist wie ein Fisch ohne Fahrrad."
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Andreas Dilger]

David Vidal writes:
> 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
-- 
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

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Heinz J. Mauelshagen]

On Wed, Apr 25, 2001 at 10:26:41AM -0600, Andreas Dilger wrote:
> David Vidal writes:
> > 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.

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?

> 
> Cheers, Andreas
> -- 
> 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
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

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
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Andreas Dilger]

Heinz writes:
> 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
-- 
Andreas Dilger                               Turbolinux filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [linux-lvm] Problem with UUID, vgscan, vgcfgrestore

[Heinz J. Mauelshagen]

On Mon, Apr 30, 2001 at 12:16:56PM -0600, Andreas Dilger wrote:
> Heinz writes:
> > 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?

> 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?

> so maybe a comment/#ifdef on the code
> so that it will be removed at a later date.
> 
> Cheers, Andreas
> -- 
> Andreas Dilger                               Turbolinux filesystem development
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

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
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-