Howdy all,
First, if anyone is planning to switch a remote machine, you may want to delay that.
As some, most, know eudev is being removed. I can't say how much I
dislike that but it seems to be happening despite some are saying it is
still being maintained upstream. During my weekly update today, eudev
was masked and the virtual wanted systemd, which I do not want at all,
so I knew it was time to switch. I do my updates in a chroot so that I
can just install binaries on my main system. Everything went well in
the chroot. No problems there. However, when I switched in the real system, no network. Everything else seems to work but when I try to
bring up net.eth0, it pukes on my keyboard about a missing driver. Keep
in mind, I was using the same kernel as before. The only difference, switching to udev. Also, I switched to udev not systemd as a whole. I unmerged eudev, emerged udev with some little friends.
I suspect there is some sort of name change, config change or something required that everyone else did ages ago. I'm still using as you might
have noticed, net.eth0 for the name. Thing is, it's all I have here.
By the way, switching back to eudev got me connected with no problems.
Some info.
root@fireball / # ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.100 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 secret stuff prefixlen 64 scopeid 0x20<link>
ether secret stuff txqueuelen 1000 (Ethernet)
RX packets 7841 bytes 9076941 (8.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7436 bytes 748477 (730.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 34 memory 0xfe3c0000-fe3e0000
root@fireball / # ls -al /etc/init.d/net*
lrwxrwxrwx 1 root root 6 Mar 1 2012 /etc/init.d/net.eth0 -> net.lo
lrwxrwxrwx 1 root root 18 Oct 12 2013 /etc/init.d/net.eth1 -> /etc/init.d/net.lo
-rwxr-xr-x 1 root root 19861 Nov 18 20:38 /etc/init.d/net.lo
-rwxr-xr-x 1 root root 2071 Nov 19 06:38 /etc/init.d/netmount
-rwxr-xr-x 1 root root 2278 Nov 19 06:38 /etc/init.d/net-online root@fireball / #
Of course that is with eudev not udev. Hard to post udev when it isn't working. ;-) This is the emerge logs.
1638112926: Started emerge on: Nov 28, 2021 09:22:06
1638112926: *** emerge --oneshot --unordered-display --ask
--backtrack=100 --jobs=5 --keep-going --with-bdeps=y --quiet-build=n --regex-search-auto=y --usepkg --verbose udev
1638112961: >>> emerge (1 of 9) acct-group/kmem-0-r1 to /
1638112961: >>> emerge (2 of 9) acct-group/tty-0-r1 to /
1638112961: >>> emerge (3 of 9) acct-group/audio-0-r1 to /
1638112961: >>> emerge (4 of 9) acct-group/cdrom-0-r1 to /
1638112961: >>> emerge (5 of 9) acct-group/dialout-0-r1 to /
1638112962: === (1 of 9) Merging Binary (acct-group/kmem-0-r1::/var/cache/portage/packages/acct-group/kmem-0-r1.tbz2) 1638112963: === (2 of 9) Merging Binary (acct-group/tty-0-r1::/var/cache/portage/packages/acct-group/tty-0-r1.tbz2) 1638112965: === (4 of 9) Merging Binary (acct-group/cdrom-0-r1::/var/cache/portage/packages/acct-group/cdrom-0-r1.tbz2)
1638112965: === (5 of 9) Merging Binary (acct-group/dialout-0-r1::/var/cache/portage/packages/acct-group/dialout-0-r1.tbz2)
1638112965: === (3 of 9) Merging Binary (acct-group/audio-0-r1::/var/cache/portage/packages/acct-group/audio-0-r1.tbz2)
1638112966: >>> emerge (6 of 9) acct-group/disk-0-r1 to /
1638112967: === (6 of 9) Merging Binary (acct-group/disk-0-r1::/var/cache/portage/packages/acct-group/disk-0-r1.tbz2) 1638112977: >>> emerge (7 of 9) acct-group/tape-0-r1 to /
1638112978: === (7 of 9) Merging Binary (acct-group/tape-0-r1::/var/cache/portage/packages/acct-group/tape-0-r1.tbz2) 1638112980: >>> AUTOCLEAN: acct-group/kmem:0
1638112982: >>> AUTOCLEAN: acct-group/cdrom:0
1638112991: === (1 of 9) Post-Build Cleaning (acct-group/kmem-0-r1::/var/cache/portage/packages/acct-group/kmem-0-r1.tbz2) 1638112991: ::: completed emerge (1 of 9) acct-group/kmem-0-r1 to / 1638112991: === (4 of 9) Post-Build Cleaning (acct-group/cdrom-0-r1::/var/cache/portage/packages/acct-group/cdrom-0-r1.tbz2)
1638112991: ::: completed emerge (4 of 9) acct-group/cdrom-0-r1 to / 1638113005: >>> AUTOCLEAN: acct-group/tty:0
1638113009: >>> AUTOCLEAN: acct-group/audio:0
1638113018: === (2 of 9) Post-Build Cleaning (acct-group/tty-0-r1::/var/cache/portage/packages/acct-group/tty-0-r1.tbz2) 1638113018: ::: completed emerge (2 of 9) acct-group/tty-0-r1 to / 1638113018: === (3 of 9) Post-Build Cleaning (acct-group/audio-0-r1::/var/cache/portage/packages/acct-group/audio-0-r1.tbz2)
1638113018: ::: completed emerge (3 of 9) acct-group/audio-0-r1 to / 1638113032: >>> AUTOCLEAN: acct-group/dialout:0
1638113035: >>> AUTOCLEAN: acct-group/disk:0
1638113043: === (5 of 9) Post-Build Cleaning (acct-group/dialout-0-r1::/var/cache/portage/packages/acct-group/dialout-0-r1.tbz2)
1638113043: ::: completed emerge (5 of 9) acct-group/dialout-0-r1 to / 1638113043: === (6 of 9) Post-Build Cleaning (acct-group/disk-0-r1::/var/cache/portage/packages/acct-group/disk-0-r1.tbz2) 1638113043: ::: completed emerge (6 of 9) acct-group/disk-0-r1 to / 1638113049: >>> AUTOCLEAN: acct-group/tape:0
1638113055: === (7 of 9) Post-Build Cleaning (acct-group/tape-0-r1::/var/cache/portage/packages/acct-group/tape-0-r1.tbz2) 1638113055: ::: completed emerge (7 of 9) acct-group/tape-0-r1 to / 1638113055: >>> emerge (8 of 9) sys-fs/udev-249-r3 to /
1638113056: === (8 of 9) Merging Binary (sys-fs/udev-249-r3::/var/cache/portage/packages/sys-fs/udev-249-r3.tbz2) 1638113063: >>> AUTOCLEAN: sys-fs/udev:0
1638113072: === (8 of 9) Post-Build Cleaning (sys-fs/udev-249-r3::/var/cache/portage/packages/sys-fs/udev-249-r3.tbz2) 1638113072: ::: completed emerge (8 of 9) sys-fs/udev-249-r3 to / 1638113072: >>> emerge (9 of 9) virtual/udev-217-r3 to /
1638113073: === (9 of 9) Merging Binary (virtual/udev-217-r3::/var/cache/portage/packages/virtual/udev-217-r3.tbz2) 1638113081: >>> AUTOCLEAN: virtual/udev:0
1638113081: === Unmerging... (virtual/udev-217-r3)
1638113087: >>> unmerge success: virtual/udev-217-r3
1638113093: === (9 of 9) Post-Build Cleaning (virtual/udev-217-r3::/var/cache/portage/packages/virtual/udev-217-r3.tbz2) 1638113093: ::: completed emerge (9 of 9) virtual/udev-217-r3 to / 1638113093: *** Finished. Cleaning up...
1638113098: *** exiting successfully.
1638113098: *** terminating.
This is the network part of lspci -k and I'm using the top one:
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
Subsystem: Intel Corporation Gigabit CT Desktop Adapter
Kernel driver in use: e1000e
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet
Kernel driver in use: r8169
This is the USE flags for both packages. I don't see anything obvious.
[ebuild N ] sys-fs/udev-249-r3::gentoo USE="kmod (split-usr) -acl (-selinux) -test" ABI_X86="32 (64) (-x32)" 0 KiB
[uninstall ] sys-fs/eudev-3.2.10-r1::gentoo USE="hwdb introspection kmod -rule-generator (-selinux) -static-libs -test" ABI_X86="32 (64) (-x32)"
In case it matters, I also have these udev rules.
root@fireball / # ls -al /etc/udev/rules.d/*
-rw-r--r-- 1 root root 2064 Apr 27 2021 /etc/udev/rules.d/69-libmtp.rules -rw-r--r-- 1 root root 1903 Apr 4 2012 /etc/udev/rules.d/70-persistent-cd.rules
-rw-r--r-- 1 root root 814 Jan 1 2008 /etc/udev/rules.d/70-persistent-net.rules
-rw-r--r-- 1 root root 0 Mar 22 2015 /etc/udev/rules.d/80-net-name-slot.rules
root@fireball / #
Anyone have any ideas? Are the network interfaces called something else now? Some config file not correct?
Thanks.
Dale
:-) :-)
On Sun, 2021-11-28 at 10:35 -0600, Dale wrote:
Boot with udev and do either ifconfig -a or ip addr show and look for
them. If they are not there, just load the modules e1000e or the other
one r8whatever it was. Should autoload, but who knows why they are not.
Use dmesg. Not that hard to debug.
This switch is NOT bringing in systemd. It is just switching which
package is now providing udev as extracted from systemd. The news item actually gives a bit more detail.
The network name switch (which I had thought was mentioned in the new
item, but apparently is not, so I don't remember where I read it) is
not directly due to eudev vs. udev, but to the "new" (years old at
this point) switch to consistent naming (or something like that) so
your network is probably something like enp20s2, reflecting which slot
your network card is physically in. I'm pretty sure there is a kernel
boot parameter which forces the old way, but can't find it now, as I
switched to the new naming with eudev, so switching to udev didn't
break anything for me.
Looking through the dmesg output should tell you what it is currently
using but you'll have to hunt (or someone else will hopefully
remember) how to make the system revert to the old network interface
naming.
I'd suggest checking the wiki for network setup, but it's still down,
and (of course) I can't currently find the URL for the status page.
General searching for "consistent network naming" or "persistent
network naming" is also likely to find some helpful pages (among the
not so helpful...)
If you know the kernel module you use for ethernet (even if it's built
in) you can search for that in dmesg. For example, my dmesg includes
"[ 19.528285] r8169 0000:19:00.0 enp25s0: renamed from eth0" If
you're not sure, lspci can help: mine includes "19:00.0 Ethernet
controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI
Express Gigabit Ethernet Controller (rev 15)" so you could find the
PCI address for your network card and search for that in dmesg. (19
hex is 25 decimal to get the network name)
I'm not completely opposed to switching to the new name method. Your
info about it being in dmesg is helpful. Now I know where that name is exactly. ;-) Do I just rename my current net.eth* files to the new way and it works or do I need to do something else or is there a automatic
way to do this?
This switch is NOT bringing in systemd. It is just switching which
package is now providing udev as extracted from systemd. The news
item actually gives a bit more detail.
The network name switch (which I had thought was mentioned in the new
item, but apparently is not, so I don't remember where I read it) is
not directly due to eudev vs. udev, but to the "new" (years old at
this point) switch to consistent naming (or something like that) so
your network is probably something like enp20s2, reflecting which
slot your network card is physically in. I'm pretty sure there is a
kernel boot parameter which forces the old way, but can't find it
now, as I switched to the new naming with eudev, so switching to udev
didn't break anything for me.
[…]
On Sun, 28 Nov 2021 11:02:17 -0600, Dale wrote:
I'm not completely opposed to switching to the new name method. YourAdd net.ifnames=0 to kernel boot parameters.
info about it being in dmesg is helpful. Now I know where that name is
exactly. ;-) Do I just rename my current net.eth* files to the new way >> and it works or do I need to do something else or is there a automatic
way to do this?
Now if I can figure out how to reset the list of /dev/sd* names that
are lurking about and inconsistent, that would be like striking
gold. Every time I hook up my external drive, it gets a different
sd* name. It does the same on the SD cards from my trail cameras too
but I can auto mount those.
Now if I can figure out how to reset the list of /dev/sd* names that
are lurking about and inconsistent, that would be like striking gold.
Every time I hook up my external drive, it gets a different sd*
name. It does the same on the SD cards from my trail cameras too but
I can auto mount those.
On Mon, 2021-11-29 at 22:47 -0600, Dale wrote:
Now if I can figure out how to reset the list of /dev/sd* names thatI'd suggest using the UUIDs for the disks (acquired via the blkid
are lurking about and inconsistent, that would be like striking
gold. Every time I hook up my external drive, it gets a different
sd* name. It does the same on the SD cards from my trail cameras too
but I can auto mount those.
command) and adding them to your /etc/fstab ... That's always been my solution to commonly-connected-but-never-permanently external disks.
It won't ensure the same sd* name, but it will ensure that they get
mounted consistently where you expect them to be.
Now if I can figure out how to reset the list of /dev/sd* names that are lurking about and inconsistent, that would be like striking gold. Every time I hook up my external drive, it gets a different sd* name. It does
the same on the SD cards from my trail cameras too but I can auto mount those.
Matt Connell wrote:
On Mon, 2021-11-29 at 22:47 -0600, Dale wrote:
Now if I can figure out how to reset the list of /dev/sd* namesI'd suggest using the UUIDs for the disks (acquired via the blkid
that are lurking about and inconsistent, that would be like
striking gold. Every time I hook up my external drive, it gets a
different sd* name. It does the same on the SD cards from my
trail cameras too but I can auto mount those.
command) and adding them to your /etc/fstab ... That's always been
my solution to commonly-connected-but-never-permanently external
disks.
It won't ensure the same sd* name, but it will ensure that they get
mounted consistently where you expect them to be.
Thanks to both for the idea. My problem isn't mounting, it's
decrypting the drive. I use cryptsetup and I have to give the sd*
name for both my external drives. The way I do now, I type in the
command to the sd point and hit tab twice. Once the drive gets spun
up, I hit tab again. Whichever one adds a 1 on the end is the one
picked. Thing is, it's rarely the same one so I have to test to see
which one it picks. I wish it would either reset itself or pick the
same one each time. I already know to ignore sda, sdb, sdc, sdd and
sde.
If it wasn't encrypted, it would be a good idea. I sometimes wish
there was a GUI way to do it that allows me to set my own mount
point. There are GUI crypt programs but they set their own mount
points. Plus, the command line is fairly easy. The password is the
hard part. Good luck NSA. ROFL
On 2021-11-29 22:47-0600 Dale <rdalek1967@gmail.com> wrote:
Now if I can figure out how to reset the list of /dev/sd* names that
are lurking about and inconsistent, that would be like striking gold.
Every time I hook up my external drive, it gets a different sd*
name. It does the same on the SD cards from my trail cameras too but
I can auto mount those.
I don't think it is possible to get consistent sd* names for removable
media.
But you could use volume labels with `tune2fs -L` or `tune.exfat
-L` or `fatlabel` and then mount them via /dev/disk/by-label/*.
On 11/28/21 9:50 AM, Jack wrote:
The network name switch ... is not directly due to eudev vs. udev,
but to the "new" ... switch to consistent naming ... so your network
is probably something like enp20s2, reflecting which slot your
network card is physically in.
Except I've had multiple instances where the supposed to be consistent
naming is anything but consistent. I don't know if it was a udev
issue or something else. But I've seen the actual address of cards in
the system change based on what other cards are added to / removed
from the system. It seems as if the motherboard re-configured
addressing with the hardware change. E.g. NIC1 in PCIe slot A and
NIC2 in PCIe slot C. NIC2 changed from (hypothetical) enp20s2 to
enp16s2 when NIC1 was removed from PCIe slot A.
So ... if the new naming scheme isn't consistent, then I'm not going
to give it the time of day. I'd rather have the older and simpler inconsistent naming scheme (eth#) vs the newer and more annoying
scheme en{po}\d\d{,s}{,1,2,3}.
The epiphany when is aw that the supposedly consistent names weren't
was a real son of a REDACTED moment.
I'm pretty sure there is a kernel boot parameter which forces the old
way, but can't find it now, as I switched to the new naming with
eudev, so switching to udev didn't break anything for me.
As Neil B. pointed out, "net.ifnames=0" is now on all my kernel boot
lines (for the above reason).
The network name switch ... is not directly due to eudev vs. udev,
but to the "new" ... switch to consistent naming ... so your network
is probably something like enp20s2, reflecting which slot your network
card is physically in.
I'm pretty sure there is a kernel boot parameter which forces the old
way, but can't find it now, as I switched to the new naming with eudev,
so switching to udev didn't break anything for me.
What I noticed in dmesg is that it takes the old name, eth0 for
example, and then renames it to the new name.
Well, if one moves things around and eth0 becomes eth3 then doesn't
that mess up the new name as well?
That could be why you see the results you have.> It's hard to base
a name on something that is changing itself.
It would seem to me that if they were going to change things for real,
they would change what the kernel names it in the beginning and it uses
the name it was first given based on slot or something else unique.
In other words, have the kernel assign it enp2s3 or whatever when
booting and that is the only name it gets.
If you only have one interface though and tweak your hardware regularly then you'll probably be happier to put it back to the old naming scheme because with only one device it should always be eth0.
So the old inconsistency was a super-bad kind of inconsistency.
The interfaces got named based on the order in which the devices
were discovered. Which, on a lot of systems, meant that every boot
was essentially rolling the dice on a race condition.
If you only have one device, you're fine. If your devices consistently
come up in the same order, you're fine. If there's jitter though
then things can easily get messy, and do so unexpectedly.
The new naming scheme names devices based on where they show up
on the bus. This has its own issues. It means that USB adapters
get different names when plugged into different slots. It means
that adding or removing other PCI bus devices can change the bus
address and therefore the name of your network interfaces.
I've seen motherboard firmware updates do the same.
But, at least in theory, this inconsistency should be triggered
by something you *know* about unless hardware is getting added and
removed by someone else without your knowledge.
If you only have one interface though and tweak your hardware regularly
then you'll probably be happier to put it back to the old naming
scheme because with only one device it should always be eth0.
Besides, it's a LOT easier to /just/ `tcpdump -nni eth0` when logging
into a machine than it is to have to figure out the interface name first.
That being said, I was okay with what CentOS 6.x did, where the new name
was matched against the MAC address. I had eth0 based on MAC for
outside and eth1 based on MAC for inside on a number of systems.
IIRC, there are situations where using udev rules to rename them
"ethN" based on MAC addresses will fail because that can conflict
with the low-level kernel names. Or something like that.
I guess I never really gave the renaming much thought because I
almost always complied drivers into the kernel, which meant that
they had a consistent ~> predictable enumeration and naming order.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (3 / 13) |
Uptime: | 81:07:01 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,096 |
Messages: | 5,276,696 |