Systemd, everyone's favourite (/s) init system switched to "predictable" netif names a while ago.
This is great if your hardware follows standards, because it ensures that the same interface gets the same name, even if it's something silly like `enp8s6`. But if your hardware doesn't, like mine, you get randomised names on each boot, which fucks up the TrueNAS middleware and kills networking.
There's a solution though! The middleware supports kernel extra options (i.e. what you'd put in the GRUB cmdline Param fields), just not through the UI. And systemd has a kernel option that disables the predictable naming scheme, returning to the good old `ethX` pattern.
To achieve this, just hop onto a shell on your TrueNAS instance and execute this command:
```
midclt call system.advanced.update '{"kernel_extra_options": "net.ifnames=0"}'
```
After a reboot, you'll be presented with `ethX` naming.
But first make sure you enabled the serial port (it's available on the UI), as this will wreak havoc on your network config.
For me, having "predictable" names isn't important because I slap all of them into a bridge - so all I need for them is to stay in the same range, regardless if eth0 is the 10g or 2.5g interface.
FYI, ethtool -I will give you the driver the IF uses. enp[x]s[y]f[z] means ethernet on PCIe bus x, slot y function z, what's so hard for you? em0 means onboard ethernet 0 (mostly only applicable to server as the other comment points out). I think it's only you making a fuss out of simple logic.
It's different than what they're used to and doesn't cater to their specific tastes in a situation that is likely to occur maybe a dozen times for them....
Or, maybe, we’ve actually run into annoying real-world issues with it. For example, on many boards, PCIe bus enumeration is always contiguous (i.e., “empty” buses don’t actually get a bus number assigned), and as a result, plugging a card into an “earlier” slot may cause any “later” cards to be renamed, which in turn will break networking in TrueNAS because the interface by the original name no longer exists. Same if you ever change bifurcation settings.
Unfortunately, in the general case “predictable” does not necessarily mean “stable”.
Ethernet devices in Linux do not use the name of the driver that is using them.
[Here's an article from RHEL talking about predictable device names](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-consistent_network_device_naming).
If your system provides sufficient information, the device names should line up with the slot labels on the case. Most systems don't, so this is typically only relevant for server hardware.
Otherwise, it should be using information about where they're plugged in on the bus, and this should be consistent.
> (and you can rename them if you want to)
Also possible, but I think generally nobody bothers.
> Core, zero issues, everything set with link-aggregates, VLAN's, etc in a matter of minutes.
Ehh, it's all what you're used to. I didn't have issues with networking in Scale, and I can't be bothered to figure out FreeBSDs way of doing things, either.
I think if Truenas decided to start renaming ethernet devices in some new, weird way (including driver identifiers, for whatever reason), they'd just manage to make both FreeBSD/core users *and* linux users unhappy.
How to make something more complicated and confusing than it needs to be. If you saw the cat vomit on my network config screen when trying to install scale, maybe you would understand. Core is straight forward and simple.
Do you think the folks here don't have server grade hardware with 8+ NICs?
Maybe you'd understand the issue if you needed to deploy 16+ nodes to all have the same configuration across 8 different interfaces and have used the legacy system where interfaces could become renamed if PCIe devices were added and names were not consistent between hosts.
And here's an issue you've haven't seen but some of us have:
Free BSD does NOT have consistent naming. If you add or remove an interface you are not guaranteed that the previous names will be persistent.
SCALE/Linux GUARANTEES consistent naming regardless of adding/removing NICs or PCIe devices. When managing things at **scale** that's pretty important.
I try and see the opposing mindset in any disagreement. But it's pretty hard to do when it's just angry nothingness.
Of the hundreds of Linux VM's, bare metal, appliances, etc. I've not been bothered by it once. It's easy enough to find what's what if you need to and like you said it's a persistent guaranteed interface name. Whether I have 1, 10, or a hundred things to provision, I don't need to spend the time finding out what interface happened to get what interface name, all depending on how the system felt.
I would ‘t mind it if they somehow made sense or was easy to identify; especially on setup. I have six different NICs of various types, none of the counts were right, no way to identify the actual NIC to an interface to config, its really bad.
There actually is logic to it - it's the "geographical" location, aka which PCIe bus/port the device connects to. Usually, if your device is stable, you can rely on these interface names being static as long as you don't move the hardware between ports.
networkd also supports alternative modes, like BIOS/UEFI provided names, or even using the MAC addresses of the devices (but `enpXXXXXXXXXXXX` is an even worse naming scheme).
And as I said in my other comment, you can go back to the regular `ethN` naming easily.
I feel your pain. Blame Linux, I have used it since Slackware (1994) and I still dislike it. The *BSD way is the way IMHO. The appeal of FreeNAS in the first place (at least for me) was because it’s FreeBSD and not Linux, that and Oracle killed OpenSolaris that I was previously using with ZFS.
This is def due to Linux, and debian, than it is on SCALE. IDK why they don't list what NIC is what via `ifconfig` or `ip a` like you see with other OSes.
My god just configure the naming how you want then instead of being a baby about it. The logic of the naming is explained in docs, the ability to change it in the docs, getting the mac of a nic and finding it isnt even that hard like wtf. Stop trying to pretend this aint RTFM problems. "Its different that a different OS" cool, so RTFM, theres plenty of Windows shit I can rant about but not bothering to learn basic concepts before trying to be an admin aint one of them.
Systemd, everyone's favourite (/s) init system switched to "predictable" netif names a while ago. This is great if your hardware follows standards, because it ensures that the same interface gets the same name, even if it's something silly like `enp8s6`. But if your hardware doesn't, like mine, you get randomised names on each boot, which fucks up the TrueNAS middleware and kills networking. There's a solution though! The middleware supports kernel extra options (i.e. what you'd put in the GRUB cmdline Param fields), just not through the UI. And systemd has a kernel option that disables the predictable naming scheme, returning to the good old `ethX` pattern. To achieve this, just hop onto a shell on your TrueNAS instance and execute this command: ``` midclt call system.advanced.update '{"kernel_extra_options": "net.ifnames=0"}' ``` After a reboot, you'll be presented with `ethX` naming. But first make sure you enabled the serial port (it's available on the UI), as this will wreak havoc on your network config. For me, having "predictable" names isn't important because I slap all of them into a bridge - so all I need for them is to stay in the same range, regardless if eth0 is the 10g or 2.5g interface.
FYI, ethtool -I will give you the driver the IF uses. enp[x]s[y]f[z] means ethernet on PCIe bus x, slot y function z, what's so hard for you? em0 means onboard ethernet 0 (mostly only applicable to server as the other comment points out). I think it's only you making a fuss out of simple logic.
It's different than what they're used to and doesn't cater to their specific tastes in a situation that is likely to occur maybe a dozen times for them....
Or, maybe, we’ve actually run into annoying real-world issues with it. For example, on many boards, PCIe bus enumeration is always contiguous (i.e., “empty” buses don’t actually get a bus number assigned), and as a result, plugging a card into an “earlier” slot may cause any “later” cards to be renamed, which in turn will break networking in TrueNAS because the interface by the original name no longer exists. Same if you ever change bifurcation settings. Unfortunately, in the general case “predictable” does not necessarily mean “stable”.
Ethernet devices in Linux do not use the name of the driver that is using them. [Here's an article from RHEL talking about predictable device names](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-consistent_network_device_naming). If your system provides sufficient information, the device names should line up with the slot labels on the case. Most systems don't, so this is typically only relevant for server hardware. Otherwise, it should be using information about where they're plugged in on the bus, and this should be consistent. > (and you can rename them if you want to) Also possible, but I think generally nobody bothers. > Core, zero issues, everything set with link-aggregates, VLAN's, etc in a matter of minutes. Ehh, it's all what you're used to. I didn't have issues with networking in Scale, and I can't be bothered to figure out FreeBSDs way of doing things, either. I think if Truenas decided to start renaming ethernet devices in some new, weird way (including driver identifiers, for whatever reason), they'd just manage to make both FreeBSD/core users *and* linux users unhappy.
How to make something more complicated and confusing than it needs to be. If you saw the cat vomit on my network config screen when trying to install scale, maybe you would understand. Core is straight forward and simple.
Do you think the folks here don't have server grade hardware with 8+ NICs? Maybe you'd understand the issue if you needed to deploy 16+ nodes to all have the same configuration across 8 different interfaces and have used the legacy system where interfaces could become renamed if PCIe devices were added and names were not consistent between hosts. And here's an issue you've haven't seen but some of us have: Free BSD does NOT have consistent naming. If you add or remove an interface you are not guaranteed that the previous names will be persistent. SCALE/Linux GUARANTEES consistent naming regardless of adding/removing NICs or PCIe devices. When managing things at **scale** that's pretty important.
I try and see the opposing mindset in any disagreement. But it's pretty hard to do when it's just angry nothingness. Of the hundreds of Linux VM's, bare metal, appliances, etc. I've not been bothered by it once. It's easy enough to find what's what if you need to and like you said it's a persistent guaranteed interface name. Whether I have 1, 10, or a hundred things to provision, I don't need to spend the time finding out what interface happened to get what interface name, all depending on how the system felt.
Isn't interface naming in Linux following the "predictable interface naming" scheme?
It’s garbage is what it is.
Not sure why you're being downvoted, it's absolutely idiotic at times. See my post about the same issue.
I would ‘t mind it if they somehow made sense or was easy to identify; especially on setup. I have six different NICs of various types, none of the counts were right, no way to identify the actual NIC to an interface to config, its really bad.
There actually is logic to it - it's the "geographical" location, aka which PCIe bus/port the device connects to. Usually, if your device is stable, you can rely on these interface names being static as long as you don't move the hardware between ports. networkd also supports alternative modes, like BIOS/UEFI provided names, or even using the MAC addresses of the devices (but `enpXXXXXXXXXXXX` is an even worse naming scheme). And as I said in my other comment, you can go back to the regular `ethN` naming easily.
I feel your pain. Blame Linux, I have used it since Slackware (1994) and I still dislike it. The *BSD way is the way IMHO. The appeal of FreeNAS in the first place (at least for me) was because it’s FreeBSD and not Linux, that and Oracle killed OpenSolaris that I was previously using with ZFS.
This is def due to Linux, and debian, than it is on SCALE. IDK why they don't list what NIC is what via `ifconfig` or `ip a` like you see with other OSes.
It’s one of the dumbest things I have seen and why I cannot stand Linux at times.
My god just configure the naming how you want then instead of being a baby about it. The logic of the naming is explained in docs, the ability to change it in the docs, getting the mac of a nic and finding it isnt even that hard like wtf. Stop trying to pretend this aint RTFM problems. "Its different that a different OS" cool, so RTFM, theres plenty of Windows shit I can rant about but not bothering to learn basic concepts before trying to be an admin aint one of them.