[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]