Didier Kryn <k...@in2p3.fr> writes: > Le 03/10/2015 09:49, Simon Hobson a écrit : >> Lets face it - there is no "right" answer to this other than a system >> with enough intelligence to read the user/admin's mind and work out >> what they intend to happen - and I think we're a bit off that yet ! >> Looking back, I think I've "moved" something at least as often as >> I've replaced it with a different something in the same location - >> probably more in fact. > > This is exactly the point. But let's consider which devices are a > concern. > > As was remarked already, disks are no longer a problem since > partitions are uniquely identified, so that nobody cares of a random > device name. And even symlinks are created in /media, named after the > labels of the partitions.
All of these 'UUID' and 'partition labeling' is the exact same kind of workaround for the exact same kind of "udev design strangeness" as for the ethernet interfaces and I'm not using that anywhere except on a 'USB install disk' where the intended root partition needs to be found by the booting kernel and OS regardless of which mass storage devices may be found as part of the computer the system is booting on. Which is how these things should work: Use the more complicated solution for the more complicated case, don't just use it for the simple cases because it can also handle them. [...] > Ethernet interfaces are maybe the only issue, which explains why > distros have implemented a solution by the means of udev rules. The > way it is implemented is secure: every new ethernet device is given a > new device name (ethX) and no entry is created in > /etc/network/interfaces; therefore the interface isn't connected > without an action of the admin. If it is a replacement, then the admin > should just edit the MAC address in > /etc/udev/rules.d/70-persistent-net.rules. Not a big deal, compared to > replacing the hardware. As I already wrote: A file /etc/udev/rules.d/75-persistent-net-generator.rules can be created (on Debian up to wheezy at least) to avoid this "install the system to new hardware and get a whole bunch of new ethN instead of the onese which aren't available anymore" mess altogether. > The new policy Poettering et al are enforcing means to relieve the > admin from this little and rare work, at the cost of a nightmare for > all the rest. It's not that simple as MAC addresses are neither necessarily persistent nor necessarily unique. Eg, by default, so-called "virtual ethernet pair interface" (used to connect containers to physical interfaces via bridge interfaces) use random MAC addresses. It's also often/ usually possible to change the MAC address of an interface. That's just something the people who came up with the previous less-than-bright idea didn't think/ know about at the time they did come up with it (according to the 'code comment' documenting the new scheme). _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng