Les Mikesell wrote:
The problem of mismatched identifiers is always going to exist, depending on which part you swap, and the motherboard, nics, conrollers, and disks are all equally candidates. We just need something besides andaconda that knows how to glue the pieces together.
I worried about the Solaris catalog method when it was implemented, but it was a site finer than the AIX ODB, which had to match the equivalent text config files. Edit one of those by hand to get it out of sink with the ODB and AIX could crumble.
The further notion of a 'registry' has long been proven less than useless in its implementations.
The current Linux method of creating persistent udev entries for the hardware it sees, is much more like the SUN catalog than the ODB or registry approach, but I agree that the job is not done yet.
For administrators and serious tinkerers, understanding what is being used is the first step. That is what we are trying to accomplish here. Suggestions and possible solutions would probably go to the lkml, but I am short on those.
However, my observations lead me to hope that we are headed in the right direction.
If I could have my wishes, I would push for LVM support in grub, automatic LVM evaluation by anaconda (are these drives in a LVM?), and better kernel errors when a LVM cannot be put together properly on boot -- give us some kind of (legible) clue.
Software based raid, including LVM, ZFS, and even GFS have great potential into the foreseeable future. Linux as a kernel and platform need better support for these. UUIDs are not enough to resolve issues with RAID devices.
. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
