Arthur Pemberton wrote:
Either we look at the USB device it's hanging off (vendor, product or
class id's), the driver or we provide a simple interface in
gnome-device-manager or similar (including command line apps) to set it.
You're wierd dude, this essentially the same thing I suggested and you
discouraged.
The system can't possibly work with multiple choices unless you have an
interface to let a human configure which is which. Now the kicker is
that most of my machines are in remote locations with swappable drives
and I expect to be able to ship a pre-configured drive built locally and
have someone pop it in a known controller position and have it come up
working - and to be able to copy images that will work across a number
of identical machines without individual attention other than setting
the hostname and IP addresses.
I would have thought that with dirves you can jsut mount by labels,
does this not work for your use case?
First, disks aren't born with labels. Second, most of my disks get
created by dd'ing an existing raw disk or the equivalent, generally on a
different machine and not necessarily under an exactly matching kernel
that would know the filesystem or how to label it. Third, you can't use
labels for fdisk/mkfs, or even dump and I'd really like to know which
physical drive is going to be the target of those commands. I realize
it is not an easy question. For example the adaptec SAS raid controller
in an ibm 3550 maps drives to volumes internally and remembers them even
if you only have one drive in a volume. That is, if you build a master
image in the first slot, dd it to the drive in the 2nd slot, take that
2nd disk and put in the first slot of another and attempt to copy again,
your disk with contents will be detected as /dev/sdb (remembered)
instead of sda from being in the first position. This is fun when you
try to repeat the dd command expecting the same thing to happen.
Anyway, the long-winded point is that you do more things with disks than
mount the file systems they contain, so a label doesn't solve the
identification problem.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
