On 10/28/2015 05:57 PM, Anton Bizzarri wrote:
The efforts so far have been,
- recreated the logical volume with the same drives (as well as the one
that had failed previously and now seemed to be working and is back in the
same place).
- I can see the logical volume in lvm as well as the device in
/dev/mapper/dm0
- I tried repairing it by running fsck and its full of inode failures and
errors.
Please "reply to list".
Looking at your first post, /dev/sd* identifiers are notorious for
changing whenever a drive, adapter, and/or port changes. Perhaps the
drives are being enumerated in a different order now than they were when
the LV worked. Get the UUID for every drive. Correlate those to drive
makes, models, serial numbers, and ports. Unplug all the drives. Reset
the CMOS via the motherboard jumper. Reconnect all the drives.
Reconfigure CMOS settings. Boot. Check UUID's again -- if they're the
same, no luck; if they changed, perhaps. If that doesn't fix it, tear
down and rebuild LVM using UUID's for PV's.. If you can script the
process, that will facilitate checking the rest of the permutations (5!
= 240 total).
If anyone has any links to more authoritative sources or links or
suggestions let me know. I tried Red Hat LVM list and that proved to return
no results.
Its either a very common problem or its a dead problem.
I STFW for an LVM community the other night, but didn't find one. My
guess is that the code stabilized years ago, was rolled in the Linux
kernel, and people moved on. You might be able to find LVM people by
contacting for the Debian "lvm2", etc., package maintainers and/or by
searching the various Debian mailing lists. Another place to look would
be the Linux kernel version control system.
David
