Ross Boylan wrote: > Thanks everyone for the feedback. Bob asked for more information about > what is going on with my system. Thanks for the story! It really does help make more sense of your setup there. > I have some dead or detached disks; since they might come back I > don't want to eliminate them from LVM's knowledge yet. With your fuller explanation I understand your sentiment and reasoning. But continuing to run your system with partial physical drives is going to make it more fragile. I am actually a little amazed that it is doing as well as it is under the circumstances! I would only encourage you to push through and get to conclusion. (Although I am as guilty as anyone for having some of these projects go on and on for extended time.) Because for as long as things are left in a somewhat betwixt and between state it is going to be more fragile than it could be if it were concluded. But along the way you will learn a lot and have the more experience for having done it. > So all of the disks that are detached might come back, either because I fix > the failure or attach the IDE. Thus I do not want to removed them from > LVM just yet. On the other hand, I have backups, and so I am > reconstructing using them rather than monkeying around with the absent > drives. Yay for backups! :-) > The one other oddity is that one of the GPT tables has gotten a little funky > ... > I'm not sure what's going on; I definitely did some manipulations on the > GPT table, but since they were all with standard tools I don't know why it > would be corrupt. Because of the changes to Advanced Format and other partition tables and so forth many of the tools that work on partitions have been changed. I often see new tools complain about work done by older tools. And older tools don't understand the work done by newer tools. Basically there is a lot of incompatibility among the partition tools in this, say, two-to-five year window of tools. Eventually everything will be moved forward. But how long will this take? Who knows. In the meantime I am right there with you seeing various incompatibilities. > Because some of the LVM VG's are incomplete, rebooting is a bit rough. The > usual scripts detect there is a problem and drop me into a shell in the > initrd. vgchange -ay and some crypto stuff gets the disks in shape, and I > can then proceed with the pivot to my regular OS. $Begin Off-Topic Drift$ I ran into a very similar problem with a CentOS system some time ago. I had added another disk to the machine. I had included it in the volume group. The machine booted fine. I thought all was good. Then later I needed to increase the space on the root partition. All seemingly good. But then two months later the machine would not reboot. I had unknowingly created a terrible problem. By default CentOS sets rd_MD_UUID=w-x-y-z on the command line. I had not updated grub for the new volume group. This had worked initially because on CentOS if the root filesystem can be launched with partial PVs then it will continue silently. But later when I expanded the root file system some of the space came from the recently added PV. At that point it would no longer boot because the root file system needed space from a PV not listed in an rd_MD_UUID. On CentOS the two possible fixes would be to add in the additional rd_MD_UUID's needed for each additional PV. Or remove it entirely and let it automatically assemble all dynamically found drives. I chose the latter since I am not booting it with additional disks on it. But in general dynamically assembling can cause problems. Add a disk from a recovery system and it will be automatically added. Not good. I am rather happy with Debian's strategy which I think is better now that I have been through the RHEL/CentOS way. $End Off-Topic Drift$ Bob
Attachment:
signature.asc
Description: Digital signature