Andrew Farris wrote:
Anaconda should have handled changing your configuration change in
/etc/fstab for you at install if all your partitions were labeled.
When does anaconda run? I want to be able to install an OS, then add
disks or move them. Right now a machine by my desktop has 2 scsi and
8 sata drives in hot-swap bays plus an assortment of pluggable
firewire and USB external drives, and only the scsi pair were
installed when anaconda ran. I'd much, much prefer that the raw
devices for the swappable bays always had fixed device names for the
drive inserted by position regardless of insertion order but I realize
that's not likely to happen, so I'll settle for a reasonable
description of how to figure out the right name for a newly inserted
drive with the understanding that it may not have a filesystem lable
and I may not want to mount it. At the moment, the most likely thing
I'd want to do is add a partition from a newly inserted disk to an
existing md array, but at some point in the setup (and not while
anaconda is running...) it is necessary to partition and build the
arrays out of a bunch of disks that mostly look the same. Is fedora
suitable for jobs like this?
Well in that particular situation where you know when the disk is
inserted and you can do them one at a time it should be easily
determined which device nodes are assigned just by 'tail -F
/var/log/messages' prior to the disk insertion. I'd agree thats not
exactly as elegant as the assumption that the device will consistently
be assigned a certain device node but it works. When the disk is
inserted the kernel messages very clearly identify it if a usable disk
is found whether it is partitioned or not.
You can also just look into /dev/disk/by-id for links that give you the
device if you know which id is which (and if only one of the disks
inserted doesn't have partitions you know which it is immediately).
/dev/disk/by-path even tells you the controller you're connected to for
each device node (with the caviat that it calls them all scsi, but
primary controller to secondary controller should still make sense).
That gives you all you should need to handle those disk management jobs...
If thats still just not how you want it to be, thats understandable I
suppose.
It doesn't seem as sensible as being able to plug into a known
controller position and get a known device name, particularly in the
scenario where the drives aren't hot-plug and you want to access a bunch
of new ones after a reboot and know which is which. But I'm not
interested in turning this into a helpdesk session about special case
procedures. The same scenario happens even more often when I build a
disk and ship it to a remote location where someone else (who doesn't
know anything about linux...) swaps it into a server with multiple NICs
- and now we have to associate the right NIC configuration with the
right cable connection. In the old days if it was eth0 yesterday it
would still be eth0 today, but that doesn't happen anymore. The servers
typically have 4 nics with 2 in use and it can be painful figuring how
to assign the addresses and routes so the network connections work on a
new box or a replacement OS.
So, the generic question is, now that the system uses essentially random
names for devices, is there a way, or a plan for a way, to deal with
situations where many choices of new devices appear as a result of
hardware changes, disk moves, backup/restores on new hardware, etc. and
if so, will it require a GUI to deal with it? So far I've only heard
the notion that these things should "just work" and I want to make sure
that everybody knows it can't "just work" because the system can't
possibly know want I want to do with a newly attached device or a whole
bunch of them and I normally don't want anything to happen automatically
other than being able to know the device name to access them. Someone
mentioned a scenario with usb->serial converters which would be a
similar case - no matter how much you want to guess and do something
friendly, you aren't going to know what's on the serial side of that
thing or what to do with it.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
