Bill Davidsen wrote:
Your points are well taken, but I consider hal keeping it's own ideas
instead of using sysconfig to be a bug, not a feature.
You do need to be able to move parts around as well as replace old
parts in an existing system. And you need to be able to do image
copies of drives. What happens if you put disks with duplicate labels
(for years they wouldn't boot...) or uuids into the same machine?
What if you put disks that previously used to be the same-numbered md?
device from 2 different machines into the same box? It has been a
while since I tried that, but it wasn't pretty.
The md device number seems not to be an issue.
If I put it 2 sets of drives that used to be md2 in former machines,
which set will become md2 and what happens to the other one?
Using a non-unique UUID
on a system is the same level as swapping two hard drives and using the
physical device name to determine how they're used, if you make an
effort to shoot yourself in the foot you will wind up with a hole in
your shoe. Deliberately creating a condition where the information used
to tell hardware apart is ambiguous is dubious practice at best.
Making a unix-like system that can't deal with dd-copied disks is
shooting everyone in both feet.
What if you want to replace your current eth0 with a different card
and shift the use of the existing one to a different subnet?
Have the info in one place, sysconfig, not sysconfig and hal keeping
their own idea of reality. Being able to set this in one place is good,
assuming that two places will always match is unrealistic. People screw
up, restores happen, one place is right or wrong, but never maybe.
And all of this gets in the way when you need to restore your backups
onto a similar but different box.
If you make physical backups of drives that is the least of the
problems.
The disk part will work as long as the replacement motherboard has the
same controller type - and you don't put 2 copies of the same disk in it
at once. But your network won't come up, so it's no fun when you have
someone replacing stuff remotely and you expect it access it again.
The UUID isn't backed up using by-file backup, so conventional
backups by tape or rsync aren't a problem.
You always have a problem, you are just moving it around. Now you have
a machine that won't boot, and if it did boot, would have fstab entries
pointing at uuids or labels that don't exist.
Finding that two drive made a
few months apart, with the same part number, are actually slightly in
size is painful reality, the only things I backup with a physical backup
are VM images, and usually not those either.
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.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
