On Wed, Sep 06, 2017 at 02:52:21PM +1000, [email protected] wrote:
> Incidentally, it's not necessary to endure the loony Systemdix¹ interface
> naming, taken from /dev/urandom, just to annoy users. On debian 9.0,
> I've adopted the now common:
I'm not a fan of these overly verbose network names, but:
a) There **is** a good reason for them, whether you use systemd or not.
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 disks, You should use UUID= or LABEL= entries in /etc/fstab, and
/dev/disk/by-{path,id,label,partlabel,partuuid,uuid} from the command line
or in scripts (and, e.g., for creating ZFS pools) when you need to specify
a specific drive.
I tend to use /dev/disk/by-id for ZFS pools - the symlinks in there contain
the brand, model, and serial number of every drive in the system (and the
drives in my hot-swap bays have sticky labels with the serial number on
them). For most other things i use label or uuid.
For network interfaces, see udev info below.
b) They're not random. Look closer, it's obviously "enx" followed by the MAC
address without colon separators.
device name: enx0c5b8f279a64
MAC address: 0C:5B:8F:27:9A:64
> In /etc/default/grub, change the GRUB_CMDLINE_LINUX=”” to:
>
> GRUB_CMDLINE_LINUX="net.ifnames=0"
>
> Or, if biosdevname is installed:
> GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
The way to do this these days is by editing 70-persistent-net.rules in
/etc/udev/rules.d/
e.g. I force the eth0, eth1, wlan0 names onto particular MAC addresses on my
machine with:
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:23:cd:b0:23:b9", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="14:da:e9:09:4b:d7", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth1"
# USB device 0x:0x (ath9k_htc) TP-Link TL-WN721N
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="c4:6e:1f:12:a1:62", ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="wlan*", NAME="wlan0"
This isn't exactly new. I switched from using ifrename to this udev method
years ago. so long ago I've forgotten when.
udev auto-generates those lines, comments and all (I added the TP-Link stuff
to the wlan0 comment), after it detects a new device. All you have to do is
edit the NAME="..." portion and reboot.
if you don't want to reboot, you can edit 70-persisent-net.rules, then run
'ifdown -a' to take all your interfaces down, followed by 'udevadm trigger'
and then 'ifup -a'. you can even do that (with a script) over ssh if you have
to.
craig
ps: yeah, r8169 NICs aren't great. They're OK for home use, and they're
what's on my motherboard and on the cheap TP-Link PCI-e NICs I got 10 years
or so ago. Realtek ethernet is kind of OK-ish. Realtek WiFi adaptors are
invariably rubbish, especially if you want to run hostapd. My $15 TP-Link
ath9K in the udev rule above is a replacement for another $15 TP-Link with a
Realtek chip that used the rtl8192 driver...useless piece of garbage. I spent a
week trying to get it to work reliably, then gave up and went hunting for a
model with an Atheros chip.
Anyway, I'll be switching to dual Intel NICs when І get my new ryzen
threadripper X399 motherboard in a month or two. I've been waiting for years
(since 2011 or so) for AMD to come out with a new CPU that's both affordable
and worth upgrading to, and Intel's so overpriced that I would have had to
spend ~$1000 just to get similar performance to what I already have with
my Phenom II 1090T...if i'm going to spend that kind of money, I want an
*upgrade* worth that much. The FX-83x0 series CPUs are nice, but $250+
for an FX-8350 didn't give enough benefit for the money and seemed like
wasting money on a dead-end technology.
I put off buying a Ryzen 7 earlier this year until I saw the specs and price
and hands-on reviews for the recently released 8-core/16-thread threadripper
model (I NEED more than 24 PCI-e 3.0 lanes. That's only enough for a 16x video
card and not much more. I've got a GPU, two 8x SAS controllers, a second
NIC, and a DVB card in this machine. the TR4 has 64 PCI lanes, it has 2 or 3
nvme sockets, and i'd like the option of putting a 16x card for 4 more nvme
sockets. It also has 8 DDR4 RAM sockets, rather than four, and supports up to
128GB RAM with 16G sticks)
and it looks like I may have the opportunity for some work in the near future
so I may pay the extra for the 16 core/32 thread model...won't need to upgrade
for another 5 or 10 years. apparently it's capable of compiling a 4.12 kernel
in about 40 seconds, so maybe it will run chromium at a decent speed :)
--
craig sanders <[email protected]>
_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
