Linux is not about choice [was Re: Fedora too cutting edge?]

[Les Mikesell]

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 at gmail.com