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.
Get them by MAC, not as ethX. I.e., here I have in
Thanks - that works in the replacement case if I have the foresight to
snarf the current MAC addresses before the disk dies. (Is this
documented somewhere and is it going to stay this way?) But an equally
common case is that new machines are being rolled out and the hardware
tech plugging the drive in doesn't know much about linux or what the MAC
address is for the machine - and I can't connect to help until he gets
at least one of them right.
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,
... random hot(un)plugging, ...
Of devices that I don't necessarily want mounted.
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
The systen /can/ tell e.g. this is still the FooLaser printer serial
XYZ-ABCDE, even though it is connected through a different USB port today.
AFAICS, as things stand, the system is /not/ doing anything funky, it just
gives a way of finding out what is where (and the device has a clear ID);
and uses this if the device had been configured before. Things do get
tricky if you want to dd(1) disk images around, or are fond of serial
devices connected through USB-serial dongles, etc. But then you want the
system to do non-obvious stuff...
I'd say most of what I do is non-obvious, which is why I've always liked
unix systems that don't make wrong guesses and do what someone else
thought should be the obvious thing. There's a place for the black
magic stuff, of course, but how do you turn it off - for example when
you are building/copying drive images that will run elsewhere or you
just want raw device access for other reasons? And how do you identify
the device from a set of choices?
fedora-devel-list mailing list
01-11-2008, 09:15 PM
Linux is not about choice
Arthur Pemberton wrote:
On Jan 11, 2008 2:30 PM, Les Mikesell <email@example.com> wrote:
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.
Frankly i like this idea, but I'm unsure of the practicality of it:
What is the highest level which is even aware of the physical location
of said device? I would imagine the BIOS knows, and maybe some really
low level kernel modules but anything above that?
The bios doesn't necessarily know anything except for the one(s) that it
might boot. But I think there may be some extra magic in what the
kernel does with the names depending on which drive bios used to boot.
The stuff in /dev/disk/by-path might be useful for the versions that
have it, but I can't see anything for the empty controller positions
where the drives aren't connected so the arrangement doesn't make a lot
Then it seems to me that what you/i/we want can be accomplished with
soem clever udev rules.
Yes, maybe, someday... I'm just not getting a warm and fuzzy feeling
that there will be a reasonable mechanism for people to interact with
this process to get deterministic behavior for the simplest thing,
accessing a device by a name related to the hardware in some way.
Shouldn't that come before magically attempting some high-level thing
with hot-plugged unknowns or browsing that only makes sense in a GUI?
fedora-devel-list mailing list