On Thu, Sep 07, 2017 at 12:14:02PM -0700, Rick Moen wrote:
> Quoting Craig Sanders ([email protected]):
>
> > You can't rely on the kernel assigning any name to any particular network
> > interface - same as you can't rely on a hard disk getting the same
> > /dev/sdX name on every reboot.
>
> For the record, over decades of administering Linux servers, I've just
> never had a problem with (by which I mean, not encountered) either network
> interfaces or hard disks / SSDs getting a new device name upon reboot. So,
> I think this risk is massively overstated.
І've had it happen to me on several occasions - both disks and NICs.
> I'd speculate that it primarily relates to the effect of hardware
> changes (adding/removing internal hardware) and, most of all,
> hotpluggable devices such as (most notably) USB. And yes, _of course_
> USB devices change device nodes upon reuse. ;->
The most common cause in my experience wasn't adding or removing drives/NICs,
it was:
a) upgrading the kernel, which changed the order that devices were detected,
resulting in eth0 and eth1 being swapped, or sda & sdb being swapped, etc.
and
b) driver modules being loaded in a different order (same cause, different
incarnation) - this could be partially solved by listing the modules you want
loaded in /etc/modules, they'll load in the order listed (unless something
else triggers them being loaded earlier).
Adding drives and controller cards and USB **also** changes the order. e.g.
you'd think that on a system with SATA ports built in to the motherboard AND a
SAS controller card, that the motherboard-connected drives would be detected
first. Nope, not necessarily.
e.g. on my my system, I have four Crucial SSDs plugged into the motherboard
(my boot drives and root zpool), a variety of WD & Seagate drives plugged into
a SAS controller card (my main storage and backup zpools). Also a USB card
reader, and an android phone (which sits in its USB connected dock recharging
and displaying a clock whenever I'm at home, also running a sip client to
connect to my asterisk server over my local wifi).
On most reboots, the SAS ports are detected first, then the USB card reader
(which doesn't even have any cards inserted), then the phone, then finally my
motherboard SATA ports. I can't remember the details, but this order changed
when I made some changes to BIOS settings...motherboard ports used to come
first, now they don't. I don't care enough to find out why or change it
because it doesn't matter at all if i use UUIDs or LABELs or /dev/disk/by-*
Even having one or more of the drives take longer than usual to spin up can
change the detection order, which may explain this:
The SAS port drives aren't even detected in any predictable order. All of the
4TB ST4000DX drives (my "backup" zpool) are plugged into one SFF-8087 socket
on the SAS card (which goes to one of my 4-drive hot swap bays), and the 1TB
WDs and STs are plugged into the other (which goes into another 4-drive bay).
You'd expect them to be detected in that order, but...nope.
$ list_disks
sda ST31000528AS_9VP14CCV
sdb WDC_WD10EACS-00ZJB0_WD-WCASJ2134122
sdc ST4000DX001-1CE168_Z303PVZ2
sdd WDC_WD10EACS-00ZJB0_WD-WCASJ2135141
sde WDC_WD10EARS-00Y5B1_WD-WMAV50993036
sdf ST4000DX001-1CE168_Z306PTHA
sdg ST4000DX001-1CE168_Z301ZSGB
sdh ST4000DX001-1CE168_Z308PSH6
sdi USB_SD_Reader_058F312D81B-0:0
sdj USB_CF_Reader_058F312D81B-0:1
sdk USB_SM_Reader_058F312D81B-0:2
sdl USB_MS_Reader_058F312D81B-0:3
sdm HTC_Android_Phone_SH0AWRX01988-0:0
sdn Crucial_CT275MX300SSD1_163313AADB8A
sdo Crucial_CT275MX300SSD1_163313AAF750
sdp Crucial_CT275MX300SSD1_163313AB032C
sdq Crucial_CT275MX300SSD1_163313AAEF5F
If I happen to reboot without my phone plugged in to a USB port, then the
Crucial drives would probably be /dev/sdm to /dev/sdp rather thn n to q. If
I got rid of the USB card reader (which I almost never use) they'd probably
end up being i-l or j-n, depending on whether the phone was plugged in when i
rebooted or not. "probably" because there are no guarantees for device naming.
I also have a second SAS controller connected to a third 4-drive hot swap bay
for adding and removing replacement drives and temporary drives. I can't
remember if I've ever rebooted with drives inserted in that but I have no idea
whether they would be detected immediately after the first SAS controller or
at some other time.
and if my list_disks script wasn't written to exclude ZFS ZVOLs, every
single ZVOL on my system (a swap dev and at least one for every VM image
on my system - about 30, most rarely used), would show up with different
/dev/zdN and /dev/zdNpP block devices on every reboot (which is why ZFS has
its own persistent device naming scheme /dev/zvol/POOLNAME/ZVOLNAME and
/dev/zvol/POOLNAME/ZVOLNAME-part#)
LVM solves the same persistent-naming problem with device mapper names.
So, when the kernel devs say that you can't rely on the order of naming for
drives and other devices, I believe them. They know what they're talking
about and my own experience and observation backs them up.
and, yeah, this is an unusual setup for a home system. It's not all that
unusual for anyone running a file server for a business or other organisation,
or anyone who doesn't want to pay for a ridiculously overpriced NAS box when
they can DIY with linux's built-in features.
> I vaguely recall that a system swapped eth0 and eth1 when replacing a 2.0.x
> kernel with a 2.2.x kernel (or 2.4 to 2.6, or something like that). Which
> didn't surprise me much, and is why God made rc files editable.
>
> And ifrename is cool.
It was cool. I installed it on every machine for several years. Then it became
unnecessary when the same capability (renaming NIC interfaces according MAC
address) was standard in udev.
Given a choice between using a standard feature that's in every linux system
(well, possibly excluding some embedded linux devices) and using a relatively
obscure, "non-standard" tool that does the same thing, the decision to switch
to using udev for that was easy.
udev was standalone for years before it got borged into systemd. It was a
useful and practical solution to the long-standing hardware abstraction and
identification issues. It still is, even though it's now embedded in systemd.
udev also has the advantage over ifrename of being useful for a lot more
device-related stuff than just NIC device renaming...and it's not something
that just does weird shit on my system that I have no control over, it's a
configurable/programmable tool that I can (and do) use to control what happens
on my system.
> So, in short, I greatly doubt there's a significant need, except for
> people highly reliant on USB for critical infrastructure (you poor
> sods!) to have the Freedesktop.org Predicatble Network Interface Names
> kludge^W scheme, nor the Freedesktop.org
> /dev/disk/by-{path,id,label,partlabel,partuuid,uuid} scheme, either.
systemd and associated projects have done a lot of incredibly stupid, even
reprehensible things over the years but persistent device naming isn't one of
them. Surprisingly, it's actually a pretty good standard, with concise and
well-written documentation...they must have stolen it from somewhere else :)
/dev/disk/by-id is especially useful - brand, model, and serial number in
the device node symlink. perfect!
if i used machines with lots of controllers and/or multipath connections to
drives, i'd probably find /dev/disk/by-path to be just as useful.
PNIN often results in ugly NIC device names, but that's easily fixed with
udev rules, and can't really be done automagically - **I** know which NIC I
want to be "eth0" and which one I want to be "eth1" etc, because **I** know
which switch or whatever they're plugged in to. The kernel doesn't and can't
know....which is precisely why I used to use ifrename, especially on servers
and cluster nodes, and now use udev for the same task.
> In my experience, the Linux kernel can do just fine managing automated
> device nodes, and automatic loading of firmware, by itself, using its own
> devtmpfs code
> (https://unix.stackexchange.com/questions/77933/using-devtmpfs-for-dev),
> which IIRC Torvalds and company wrote as a reaction to ongoing bad
> behaviour from the systemd/udev people.
devtmpfs doesn't solve the device order or naming problem. It's just
auto-populated with device nodes in the order that the kernel finds them. It's
not something to use instead of udev (or ifrename), it's something to use WITH
them.
> https://wiki.gentoo.org/wiki/Mdev
> https://github.com/slashbeast/mdev-like-a-boss
whether it's called udev or mdev or some other clone of udev, it still does
the same thing. It definitely would be better if udev wasn't merged into
systemd so that competing alternatives like mdev could gain enough traction to
improve rapidly (and spur improvements in udev too), but that's kind of beside
the point here. the point is what udev (or mdev or whatever) **DOES**, not
what the implementation is called.
> > I switched from using ifrename to this udev method years ago. so long
> > ago I've forgotten when.
>
> ifrename is cool. ;->
was :)
> It's too bad about AMD Platform Security Processor (PSP).
> https://libreboot.org/faq.html#amd
>
> Seems that we're on our way to being able to totally neuter Intel Management
> Engine, but not yet PSP. (Personally, I like the thought of my systems not
> being able to be remotely controlled by others invisibly.)
I'd rather NOT have that shit but since it's impossible to buy the CPU (or
any Intel equivalent, and many/most ARM etc CPUs too) without it, my choices
are: 1. don't buy it, 2. buy it with that shit.
I expect that the AMD PSP will also eventually be cracked, or someone will
discover the NSA backdoor (or, as you mentioned, their disabling method as
recently happened with the Intel Management Engine)
craig
--
craig sanders <[email protected]>
_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
