[opensuse] UUID=>0x and LVM
Hello, One of my clients has a server, which doesn't boot anymore, because LVM doesn't find one of its hard-drives anymore. It looks for a hard- drive with a specific UUID, but this hard-drive has changed its UUID to 0x. Fortunately, I think, that I have most of the needed information by LVM, because the first hard-drive of the LVM is working. I tried everything I found on the net, including rewriting into LVM a new UUID of 0x for this hard-drive. (Though, it rejects a value of 0x.) Strangely, when I boot into a GParted Live-CD, everything comes up without a hick. I can mount the LVM and access its data. What does the GParted Live-CD do differently? How could I copy the configuration, GParted Live-CD constructs, over to my real system? (I tried changeroot, copy 'lvm.conf', etc.) Thanks for any help! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
In <8FC020C1-D875-4DE3-9C4B-2698A393FADC@econophone.ch>, Philip Mötteli wrote:
One of my clients has a server, which doesn't boot anymore, because LVM doesn't find one of its hard-drives anymore. It looks for a hard- drive with a specific UUID, but this hard-drive has changed its UUID to 0x.
What is telling you this? That's not a valid UUID. Assuming nothing is wrong with the drive, you should be able to run pvcreate and specify the UUID that LVM is expecting and it will write the new PV meta-data without affecting any other sectors on the drive/partition. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Am 14.06.2009 um 03:54 schrieb Boyd Stephen Smith Jr.:
In <8FC020C1-D875-4DE3-9C4B-2698A393FADC@econophone.ch>, Philip Mötteli wrote:
One of my clients has a server, which doesn't boot anymore, because LVM doesn't find one of its hard-drives anymore. It looks for a hard- drive with a specific UUID, but this hard-drive has changed its UUID to 0x.
What is telling you this?
fdisk -l
That's not a valid UUID.
Yes, I think so. Even the BIOS has problems.
Assuming nothing is wrong with the drive, you should be able to run pvcreate and specify the UUID that LVM is expecting and it will write the new PV meta-data
So allthough the drive has now the UUID of 0x, I just rewrite the old configuration? I mean, LVM already has the old UUID for this drive (hdc). I basically would re-write the same configuration, I already have.
without affecting any other sectors on the drive/partition.
That was something, I was afraid of. They haven't a backup so far. Thanks -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
In <8702E78B-86D7-4C69-8435-25875C189053@econophone.ch>, Philip Mötteli wrote:
Am 14.06.2009 um 03:54 schrieb Boyd Stephen Smith Jr.:
In <8FC020C1-D875-4DE3-9C4B-2698A393FADC@econophone.ch>, Philip Mötteli
wrote:
this hard-drive has changed its UUID to 0x. What is telling you this? fdisk -l
That's not the UUID that LVM reads. Actually, that's not a UUID at all, it is not enough bits. The UUID that LVM reads is stored inside the PV metadata section written by LVM itself. To see the UUIDs on the system as LVM sees them issue the command: pvscan -u as root.
Assuming nothing is wrong with the drive, you should be able to run pvcreate and specify the UUID that LVM is expecting and it will write the new PV meta-data
So allthough the drive has now the UUID of 0x, I just rewrite the old configuration? I mean, LVM already has the old UUID for this drive (hdc). I basically would re-write the same configuration, I already have.
LVM writes a UUID to the PV meta-data section of each PV. This UUID is used to identify the drive to LVM. LVM *also* writes the UUID of each PV in a VG to the VG meta-data area. These UUIDs are used to determine which drives belong in the VG. If LVM is giving you messages like "could not locate physical volume with UUID blah-blah-blah" that means it has found at least one copy of the VG meta-data and that meta-data lists "blah-blah-blah" as the UUID of the of the component PVs but LVM couldn't find a drive that has that UUID in its PV meta-data section. The pvcreate command will write a new PV meta-data section, which appears to be corrupt--at the very least (you say) it has the wrong UUID. It would not change the any of the VG meta-data. If the configuration was correct, you wouldn't be getting errors. Anything that corrects the situation is not "rewrit[ing] the same configuration".
without affecting any other sectors on the drive/partition.
That was something, I was afraid of. They haven't a backup so far.
Even if you can't mount the drive, you can take a dd_rescue copy of it before you make changes to any of the data on it. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
participants (2)
-
Boyd Stephen Smith Jr.
-
Philip Mötteli