|
There is no man 4 pci in Linux so whatever is on that page probably doesn't apply I don't know what system500 is but my network interfaces have the same name every boot
|
#
?
Aug 26, 2022 10:25
|
|
|
|
| # ? May 18, 2024 06:58 |
|
|
BattleMaster posted:There is no man 4 pci in Linux so whatever is on that page probably doesn't apply System500 is a pun using roman numerals and the spelling "SystemD", which is how Lennart doesn't want it spelled. Sure, but as an example what does "ens18" mean? There's no ens(4) driver, and there aren't 19 NICs of that kind in the box - and it gets worse with enp6s18 because that makes no sense in the scheme used by every Unix-like where an interface named after the driver they attach to and a zero-indexed number. Having repeatable device naming across reboots is cool, but when it only applies to network devices, I don't know how much use it is? BlankSystemDaemon fucked around with this message at 10:36 on Aug 26, 2022 |
|
#
?
Aug 26, 2022 10:30
|
|
|
BlankSystemDaemon posted:Seems like Linux lacks necessary documentation then. Who cares what it means, and you don't know how much use it is but it is one solution to precisely the same problem someone is having in this thread??? udev rules can also be written to change any aspect of how device files are created and named so you can use it for anything else? And if you don't like the names it gives your interfaces you can write new rules to give your devices a name that makes you feel good? It's almost like you have zero interesting things to add to a discussion on this topic
|
|
#
?
Aug 26, 2022 10:34
|
|
|
BattleMaster posted:Who cares what it means, and you don't know how much use it is but it is one solution to precisely the same problem someone is having in this thread??? And the documentation isn't correct, because even if I go by the example given in the documentation you linked where "names incorporating firmware provided pci-ex hotplug slot index numbers", it shouldn't give "ens18" as an interface name, since there aren't 19 PCI hotplug devices in the system - there's just 10. Instead it just gets swept under the table, because we should obviously not criticize any decision made by any developer whatsoever, because they're doing it for free so therefore we should obviously just be thankful for what we get. BlankSystemDaemon fucked around with this message at 10:48 on Aug 26, 2022 |
|
#
?
Aug 26, 2022 10:44
|
|
|
did you seriously just make up an imaginary linux install with an imaginary device named ens18 on an imaginary system with 10 devices?
|
|
#
?
Aug 26, 2022 10:51
|
|
|
BattleMaster posted:did you seriously just make up an imaginary linux install with an imaginary device named ens18 on an imaginary system with 10 devices? His forums name abbreviates to BSD, what do you think? 
|
|
#
?
Aug 26, 2022 11:13
|
|
|
BattleMaster posted:did you seriously just make up an imaginary linux install with an imaginary device named ens18 on an imaginary system with 10 devices? pre:debdrup@dogpound:~> lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon
00:12.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:1e.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge
00:1f.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge
debdrup@dogpound:~> ifconfig | head -n 9
ens18: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet [snip] netmask 255.255.255.224 broadcast [snip]
inet6 [snip] prefixlen 64 scopeid 0x20<link>
ether [snip] txqueuelen 1000 (Ethernet)
RX packets 213374605 bytes 22911783083 (22.9 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 166896114 bytes 21427632742 (21.4 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
|
#
?
Aug 26, 2022 11:29
|
|
|
Wibla posted:His forums name abbreviates to BSD, what do you think? Well I certainly wasn't expecting him to have a real Linux install! So I understand why I was confused about the "systemd/udev" thing. I remembered udev predating systemd by a lot but at some point it was made a part of systemd. However! There is a non-systemd fork of it called eudev and Alpine seems to have it in its repository! So that might be the way to get predictable device naming going. okay, literally who cares? BattleMaster fucked around with this message at 11:33 on Aug 26, 2022 |
|
#
?
Aug 26, 2022 11:30
|
|
|
BattleMaster posted:Well I certainly wasn't expecting him to have a real Linux install! BattleMaster posted:okay, literally who cares? BlankSystemDaemon fucked around with this message at 11:36 on Aug 26, 2022 |
|
#
?
Aug 26, 2022 11:32
|
|
|
Okay so let's go with it. Does that example go against the documentation? ens18 means that the interface is named based on "Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)" How does PCI Express hotplug number the slots? quote:Logical Slot Identifier So devices can be numbered based on either the PCI bus logical numbering scheme (which doesn't have anything to do, necessarily with number of devices on the bus), or on the physical slot number. quote:Physical Slot Identifier The physical slot number is assigned by the vendor and also doesn't necessarily have anything to do with the number of devices. Let's see what ens18's PCI bus logical number is: quote:00:12.0 Ethernet controller: Red Hat, Inc. Virtio network device Oh look, hex 12 is decimal 18!!!! Which clearly matches ens18. You were clearly mistaken as to how those numbers are arrived upon. Nothing to do with how many devices there are. "but what if it's based on the physical slot number???" then it would have an enp* name: "Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)" "but the numbers are not to my liking!" like it doesn't matter as long as they are the same across boots. It straight up does not matter what the numbers are as long as you know which one is which. You look them up and configure your /etc/network/interfaces or systemd .network unit files or whatever you feel like and then not think about it until you need to reconfigure it. like I cannot think of something I care about less than "the number is 18 but there is not 0-17" If you care about the specific name and number you can make a udev rule to change it to whatever you want. regarding the staticness of the names, ens* numbers can change if the contents of your PCI bus change, but the enp* numbers are based on vendor assigned physical slot ID and I've never had them change even with adding or removing other devices. BattleMaster fucked around with this message at 12:03 on Aug 26, 2022 |
|
#
?
Aug 26, 2022 11:58
|
|
|
quote:The idea was that this provides "Predictable Names", though as it turns out the main thing that's predictable about it is that calling it this will cause furious users to pop up disputing the appropriateness of that name.
|
|
#
?
Aug 26, 2022 12:41
|
|
|
I don't even post here much but felt compelled to buy that avatar and text. You are a complete pain in the rear end and should be thread banned from here. You loving moron.
|
|
#
?
Aug 26, 2022 13:37
|
|
|
Oh no I killed the thread! I just enabled dhcp on everything and called it a day, gang! It’s all good! <3
|
|
#
?
Aug 26, 2022 13:50
|
|
|
BlankSystemDaemon posted:Wouldn't this match on any interface named beginning with en, not just ones that have a link state? This might be an issue if you have a machine where you want to use both systemd-netword and NetworkManager for unfathomable reasons, but I think everyone pretty much agrees that's a bad idea except for Ubuntu.
|
|
#
?
Aug 26, 2022 14:19
|
|
|
BlankSystemDaemon posted:So far as I know, udev exists to solve Linux not enumerating devices the same across reboots, which isn't a problem in most other OS, but is also the cause of people having to use /dev/by-id for OpenZFS. But also, when this issue first came up some 15 years ago the Linux (kernel) people, correctly, pointed out that hardware isn't static and so while PCI bus enumeration should be predictable as long as you're not physically swapping out cards, things like USB adapters and hot-plug devices in general will come and go, and so relying on a name based on enumeration isn't great. They ended up punting this problem to userspace (udev, later systemd) which has better facilities for assigning device names/aliases than the kernel does internally. For example, with with disks, like /dev/sda being the first SCSI/SATA/SAS device is great, but suppose I'm upgrading my laptop from a M.2 SATA SSD to a M.2 NVMe SSD, suddenly my disk is going to appear as /dev/nvme0n1 instead. Fortunately that's not a problem since most installations will put filesystem UUIDs in /etc/fstab and will successfully mount partitions regardless of what bus or physical media they're located on. Regarding network devices, usually when it comes down to it there's two scenarios I need to deal with: (i) a machine where the network configuration is fixed to a specific interface which I can key using the MAC address, or (ii) a set of machines that are built identically to each other and so the network configuration is fixed to a particular PCI slot. In the interim period, udev's persistent names supported (i) just fine, but didn't easily support (ii). With systemd-networkd I can write a match rule for either based on which of the two is situationally appropriate.
|
|
#
?
Aug 26, 2022 14:38
|
|
|
Klyith posted:The idea was that this provides "Predictable Names", though as it turns out the main thing that's predictable about it is that calling it this will cause furious users to pop up disputing the appropriateness of that name. To be fair, it can produce names like "enp7s0f3u2u3c2" (an actual interface on some of our systems) which is pretty far from human friendly.
|
|
#
?
Aug 26, 2022 14:54
|
|
|
xzzy posted:To be fair, it can produce names like "enp7s0f3u2u3c2" (an actual interface on some of our systems) which is pretty far from human friendly. You get stuff like that for USB network devices: [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>] It's so long because it specifies which ports of which hubs it's connected to, which ensures that you get the same interface name if you keep it plugged in the same way. I think the whole "stays the same across boots" thing is more important than having a pretty name, and if you only have one USB network adapter then it's not like you're going to mistake that for anything else. edit: also, bash has autocomplete for stuff like ifup so you just need to type like ifup enp<tab> if you can't be assed to remember it BattleMaster fucked around with this message at 15:06 on Aug 26, 2022 |
|
#
?
Aug 26, 2022 15:03
|
|
|
xzzy posted:To be fair, it can produce names like "enp7s0f3u2u3c2" (an actual interface on some of our systems) which is pretty far from human friendly.
|
|
#
?
Aug 26, 2022 15:13
|
|
|
xzzy posted:To be fair, it can produce names like "enp7s0f3u2u3c2" (an actual interface on some of our systems) which is pretty far from human friendly. "Human friendly" can mean a whole lot of things, and I think the only reason that people who have used *nix for a long time would call "eth0" friendly is that they know it. Most things in the guts of *nix are astonishingly user-unfriendly, starting with the general pattern of "maximum abbreviation so I can type commands faster". That is provably a massive barrier to learning. So, my take on human friendly is that the Device Name is the friendly part, and the IF name is the guts part. If you're needing to address things by the guts name you should probably know how that name works. If you don't like "enp7s0f3u2u3c2" because it's too long and goes against the idea that everything should have a maximum of 5 characters, you can alias it to eth0 and be old-school. (And maybe that's a good idea if you are managing a bunch of machines with variations in hardware -- script each machine to make an eth0 alias for the correct interface, and then have a single script that configures eth0 across all of them.)
|
|
#
?
Aug 26, 2022 15:34
|
|
|
We had a period where we forced using the kernel device names, and a period where we'd alias them as well. It caused more trouble than it was worth, so we just live with whatever udev comes up with for us. It's generally pretty usable, but every once in a while it throws a curveball and we get to be amused by it. Ideally the names it generates would be both persistent and easy to type, but I guess in an era where people increasingly do stuff with a GUI that abstracts it all it's less important. We run thousands of linux servers though so get to look at it constantly.
|
|
#
?
Aug 26, 2022 15:42
|
|
|
ExcessBLarg! posted:I've only gotten as far as "enp6s1f1" for a PCIe card. My USB Ethernet adapter is named "enx00051bb0a6e2", which makes me think they just straight gave up trying to think of how to better handle USB devices. This sounds like they may using the hardware MAC address. That would hopefully be both unique and consistent, so I can think of much worse schemes. Eletriarnation fucked around with this message at 15:52 on Aug 26, 2022 |
|
#
?
Aug 26, 2022 15:49
|
|
|
ExcessBLarg! posted:I've only gotten as far as "enp6s1f1" for a PCIe card. My USB Ethernet adapter is named "enx00051bb0a6e2", which makes me think they just straight gave up trying to think of how to better handle USB devices. Tfw udev gives up on your device and just uses a serial number Also, I gotta say, BSD hasn't managed to get the linux thread this angry in years. Good work!
|
|
#
?
Aug 26, 2022 15:58
|
|
|
Yes, it is the MAC address, that's the obvious part. I'd assume that the alternative is to figure out the USB connection path through hubs and all to the device and use that, which would amusingly change if you connected it to a different USB port.
|
|
#
?
Aug 26, 2022 17:09
|
|
|
ExcessBLarg! posted:I'd assume that the alternative is to figure out the USB connection path through hubs and all to the device and use that, which would amusingly change if you connected it to a different USB port. That is specifically what the non-MAC address alternative is, which as I posted earlier, contains port information and so will change if it is moved.
|
|
#
?
Aug 26, 2022 17:21
|
|
|
well poo poo
Klyith fucked around with this message at 23:27 on Aug 26, 2022 |
|
#
?
Aug 26, 2022 18:02
|
|
|
Please just forget I said anything, because I can't deal with this right now. I just found a lump near a place where the previous time I found a lump, it turned out to be cancer.
|
|
#
?
Aug 26, 2022 18:15
|
|
|
BlankSystemDaemon posted:Please just forget I said anything, because I can't deal with this right now. Big hugs friend. Pm me if you want to talk
|
|
#
?
Aug 26, 2022 18:30
|
|
|
BattleMaster posted:https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames BSD is a gimmick troll, and not a very fun one due to their lack of technical knowledge, its best to just ignore them.
|
|
#
?
Aug 26, 2022 18:54
|
|
|
BlankSystemDaemon posted:Please just forget I said anything, because I can't deal with this right now. I'm crossing my fingers for you, cancer is no joke.
|
|
#
?
Aug 26, 2022 19:37
|
|
|
BlankSystemDaemon posted:Please just forget I said anything, because I can't deal with this right now. Did the name of the lump change? (USER WAS PUT ON PROBATION FOR THIS POST) (USER WAS PUT ON PROBATION FOR THIS POST)
|
|
#
?
Aug 26, 2022 22:52
|
|
|
Aware posted:I don't even post here much but felt compelled to buy that avatar and text. You are a complete pain in the rear end and should be thread banned from here. You loving moron. Aware posted:Did the name of the lump change? You're a goddamn rear end in a top hat. gently caress you.
|
|
#
?
Aug 26, 2022 23:05
|
|
|
Aware posted:I don't even post here much but felt compelled to buy that avatar and text. You are a complete pain in the rear end and should be thread banned from here. You loving moron. I wish you would post even less
|
|
#
?
Aug 26, 2022 23:08
|
|
|
BlankSystemDaemon posted:Please just forget I said anything, because I can't deal with this right now. loving hell, best wishes ❤️
|
|
#
?
Aug 26, 2022 23:26
|
|
|
BlankSystemDaemon posted:Please just forget I said anything, because I can't deal with this right now. Hey man, I appreciate hearing your point of view and having you in the thread. I'm wishing along with you that this isn't bad news once you get it checked out.
|
|
#
?
Aug 27, 2022 00:12
|
|
|
I'm sorry. Please be OK! 
|
|
#
?
Aug 27, 2022 00:24
|
|
|
BlankSystemDaemon posted:Please just forget I said anything, because I can't deal with this right now. That's a bummer, I hope you caught it early and it's treatable.
|
|
#
?
Aug 27, 2022 01:35
|
|
|
BlankSystemDaemon posted:Please just forget I said anything, because I can't deal with this right now. Shiiit. Best wishes. (PS please don't stop BSD posting lol)
|
|
#
?
Aug 27, 2022 04:22
|
|
|
VostokProgram posted:You're a goddamn rear end in a top hat. gently caress you. Sometimes I wish you could plus posts. But yeah, I agree completely.
|
|
#
?
Aug 27, 2022 09:13
|
|
|
BlankSystemDaemon posted:Please just forget I said anything, because I can't deal with this right now. Ah that's less than ideal - I hope it proves to be benign this time.
|
|
#
?
Aug 27, 2022 12:46
|
|
|
|
| # ? May 18, 2024 06:58 |
|
|
Aware posted:Did the name of the lump change? I really wish my buttons worked here
|
|
#
?
Aug 27, 2022 15:02
|
|