Re: [gentoo-user] Switching from eudev to udev, disaster.

[Grant Taylor]

On 11/30/21 1:56 PM, Laurence Perkins wrote:
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.


-guppy mouth-

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.


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.


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.


Thank you for that explanation.  It describes what I witnessed perfectly.


I've seen motherboard firmware updates do the same.


Oy vey!

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.


One would hope.

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.


Indeed.



--
Grant. . . .
unix || die

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Rich Freeman]

On Tue, Nov 30, 2021 at 3:56 PM Laurence Perkins  wrote:
>
> 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.
>

I'm not sure if other network managers support wildcards, but with
networkd I just set the interface name to e* on single-device systems.

-- 
Rich

RE: [gentoo-user] Switching from eudev to udev, disaster.

[Laurence Perkins]

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.

LMP

-Original Message-
From: Grant Taylor  
Sent: Tuesday, November 30, 2021 12:34 PM
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Switching from eudev to udev, disaster.

On 11/30/21 12:58 PM, Dale wrote:
> What I noticed in dmesg is that it takes the old name, eth0 for 
> example, and then renames it to the new name.

I don't know if it's the /kernel/ that does the renaming, or not based on the 
kernel parameter, or if it's something else very early in the boot that does 
the renaming.

> Well, if one moves things around and eth0 becomes eth3 then doesn't 
> that mess up the new name as well?

My understanding is that the new name is -- supposed to be -- based off of some 
property of the device.  I assume that said property is from something akin to 
where lspci gets it's data.  Probably something exposed in /proc and / or /sys 
via the actual driver that ultimately gets feed into the renaming routine.

> That could be why you see the results you have.> It's hard to base a 
> name on something that is changing itself.

My understanding is that the new name is supposed to be completely independent 
from and not derived using the old name.  So the old naming should have no 
influence on the new name.

> 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.

Agreed.  As in have the driver instantiate the device with the new name from 
the outset.

> In other words, have the kernel assign it enp2s3 or whatever when 
> booting and that is the only name it gets.

Yep.

I don't know /why/ or /where/ the failure is with the new names.  I just know 
that I have seen instability in them.  Seeing as how stability ~> 
predictability is the motivation for the rename, well, that's a failure in my 
opinion.

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.



--
Grant. . . .
unix || die

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Grant Taylor]

On 11/30/21 12:58 PM, Dale wrote:
What I noticed in dmesg is that it takes the old name, eth0 for 
example, and then renames it to the new name.


I don't know if it's the /kernel/ that does the renaming, or not based 
on the kernel parameter, or if it's something else very early in the 
boot that does the renaming.


Well, if one moves things around and eth0 becomes eth3 then doesn't 
that mess up the new name as well?


My understanding is that the new name is -- supposed to be -- based off 
of some property of the device.  I assume that said property is from 
something akin to where lspci gets it's data.  Probably something 
exposed in /proc and / or /sys via the actual driver that ultimately 
gets feed into the renaming routine.


That could be why you see the results you have.> It's hard to base 
a name on something that is changing itself.


My understanding is that the new name is supposed to be completely 
independent from and not derived using the old name.  So the old naming 
should have no influence on the new name.


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.


Agreed.  As in have the driver instantiate the device with the new name 
from the outset.


In other words, have the kernel assign it enp2s3 or whatever when 
booting and that is the only name it gets.


Yep.

I don't know /why/ or /where/ the failure is with the new names.  I just 
know that I have seen instability in them.  Seeing as how stability ~> 
predictability is the motivation for the rename, well, that's a failure 
in my opinion.


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.




--
Grant. . . .
unix || die

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Dale]

Grant Taylor wrote:
> 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).
>
>
>


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. 

I don't change much hardware often so it doesn't affect me but I'm sure
there are people, maybe even large companies/orgs that it does and it
could be a issue for them.  It could even be a security issue if two
nics gets switched and one has a lot of security and the other doesn't. 

Either way, I'm up and running again.  Even rebuilt my backup kernels to
include the drivers this morning.  I just hope nothing comes back and
bites me later.  :/  I was a bit lost there for a while. 

Dale

:-)  :-) 

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Grant Taylor]

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).




--
Grant. . . .
unix || die

RE: [gentoo-user] Switching from eudev to udev, disaster.

[Laurence Perkins]

>> -Original Message-
>> From: tastytea  
>> Sent: Monday, November 29, 2021 9:00 PM
>> To: gentoo-user@lists.gentoo.org
>> Subject: Re: [gentoo-user] Switching from eudev to udev, disaster.
>> 
>> On 2021-11-29 22:47-0600 Dale  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/*.
>> 
>> Kind regards, tastytea
>> 
>> --
>> Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at 
>> <https://tastytea.de/tastytea.asc>.

Don't even need to do that if you don't care about human beings too much.  
/dev/disk/by-id has similar links based on drive model and serial number and 
/dev/disk/by-uuid I think has them by filesystem uuid.  All of those should be 
pretty consistent.

LMP

Re: [gentoo-user] Switching from eudev to udev, disaster.

[tastytea]

On 2021-11-29 23:19-0600 Dale  wrote:

> 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* 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'd suggest using the UUIDs for the disks (acquired via the blkid
> > 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 

If the partition table is GPT (instead of msdos compatible), you can
set a label to the partition itself with gparted (right click →
name partition) and then access it via /dev/disk/by-partlabel/. That
works for encrypted partitions too, since the name is stored in the
partition table and not the file system.

Kind regards, tastytea


-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgpvHFgnrSW0v.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Wols Lists]

On 30/11/2021 04:47, Dale 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.


ls -al /dev/disk/by-uuid

That's a bunch of symlinks. The uuid part is guaranteed to be 
consistent, and the link points to the correct sdXn.


Try using that instead, and see if it works. It's supposed to ...

Cheers,
Wol

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Dale]

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* 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'd suggest using the UUIDs for the disks (acquired via the blkid
> 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 

Dale

:-)  :-)

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Matt Connell]

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 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'd suggest using the UUIDs for the disks (acquired via the blkid
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.

Re: [gentoo-user] Switching from eudev to udev, disaster.

[tastytea]

On 2021-11-29 22:47-0600 Dale  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/*.

Kind regards, tastytea

-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgpwc3q7qeVz5.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Dale]

Neil Bothwick wrote:
> On Sun, 28 Nov 2021 11:02:17 -0600, Dale wrote:
>
>> 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? 
> Add net.ifnames=0 to kernel boot parameters.
>
>


I've already switched to the new naming method.  I'm not real big on it
but its been that way for a while so not likely to change again anytime
soon.  That said, they will likely announce a change in a month or so
just to rub my nerve the wrong way.  ROFL  At least it isn't as big a
deal as hal was.  ;-)  My biggest problem, I wasn't sure where to start
looking.  For some reason searching dmesg just escaped me. 

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'd also like for kwin to stop resetting every once in a while.  I
toggled the compositor(sp?) setting and that seems to have helped, so
far anyway. 

Dale

:-)  :-) 

Re: [gentoo-user] Switching from eudev to udev, disaster.

[tastytea]

On 2021-11-28 11:50-0500 Jack  wrote:

> 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.

The name switch is announced via a warning message when you emerge udev:

WARN: postinst

udev-249 defaults to predictable interface renaming, as described in
the URL below:
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

If you wish to disable this, please see the above documentation, or set
net.ifnames=0 on the kernel command line.

You can change settings for log messages in make.conf, see
/usr/share/portage/config/make.conf.example for documentation (search
for PORTAGE_ELOG). I have
PORTAGE_ELOG_SYSTEM="save echo:error,warn,log" in my make.conf. echo
means the messages are displayed again when emerge exits.

> […]

Kind regards, tastytea

-- 
Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at
.


pgpjFa3IJ8OoN.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Neil Bothwick]

On Sun, 28 Nov 2021 11:02:17 -0600, Dale wrote:

> 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? 

Add net.ifnames=0 to kernel boot parameters.


-- 
Neil Bothwick

Of course it's not your day,
With 7 billion people on earth chances are slim it will ever be *your*
day.


pgpFRDXAtGS87.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Dale]

Jack wrote:
>
> 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 :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)


Yep, your info helped.  Oh, Gentoo wiki is up and that helped too.  I
was able to access the install docs and print it for reference.  Anyway,
I removed eudev, emerged udev and rebooted, since it names the devices
during boot up, I thought that made sense.  When I got booted up,
naturally the network didn't work.  To make it easy I just logged into
KDE.  In a Konsole I ran both ip a and ifconfig.  Both agreed the
network was named enp3s0.  I then simply renamed the old net.eth0 file
to net.enp3s0.  After that, it came up but it didn't know to use DHCP
but did try it as a last resort.  That will slow things down so I went
digging for the file, /etc/conf.d/net, and changed the name of the
network to the new deal.  Once all this was done, I ended up with this
and it trying DHCP first.


root@fireball / # dmesg | grep e1000
[    0.531129] pci :06:00.0: reg 0x30: [mem 0xfe10-0xfe13 pref]
[    0.531486] pci :00:15.0:   bridge window [mem 0xfe10-0xfe1f]
[    0.568155] pci :00:15.0:   bridge window [mem 0xfe10-0xfe1f]
[    0.569693] pci_bus :06: resource 1 [mem 0xfe10-0xfe1f]
[    0.814373] e1000: Intel(R) PRO/1000 Network Driver
[    0.814432] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    0.814510] e1000e: Intel(R) PRO/1000 Network Driver
[    0.814566] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    0.814775] e1000e :03:00.0: Interrupt Throttling Rate (ints/sec)
set to dynamic conservative mode
[    0.901776] e1000e :03:00.0 eth0: (PCI Express:2.5GT/s:Width x1)
68:05:ca:42:17:39
[    0.901855] e1000e :03:00.0 eth0: Intel(R) PRO/1000 Network
Connection
[    0.901925] e1000e :03:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008
[    9.795053] e1000e :03:00.0 enp3s0: renamed from eth0
[  275.422120] e1000e :03:00.0 enp3s0: NIC Link is Up 1000 Mbps Full
Duplex, Flow Control: Rx/Tx
root@fireball / # ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: enp3s0:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
    link/ether 68:05:ca:42:17:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.100/24 brd 192.168.0.255 scope global dynamic
noprefixroute enp3s0
   valid_lft 7134sec preferred_lft 6234sec
    inet6 fe80::1eef:2ca0:c286:9eec/64 scope link
   valid_lft forever preferred_lft forever
3: eth2:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
    link/ether 94:de:80:cc:0c:39 brd ff:ff:ff:ff:ff:ff
    altname enp4s0
4: sit0@NONE:  mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
root@fireball / #


I'm mostly posting this just on the off chance someone else runs into
this and needs some guidance, I sure did.  o_O  Oh, don't forget to
remove the old network and add the new network to the default runlevel
as it should be. 

So, thanks Jack for the help.  The wiki coming up helped to but you got
me started by knowing what I should look for and where.  I think I could
have done this without the wiki and just the info you provided.  As a
bonus, I have the new network name. 

Dale

:-)  :-) 

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Jack]

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 :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)

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Dale]

Jack wrote:
> 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'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? 

That makes sense and was on my suspect list.  I just didn't know where
to get the new name from. 

Dale

:-)  :-) 

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Jack]

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.


On 11/28/21 11:35, Dale wrote:

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  mtu 1500
     inet 192.168.0.100  netmask 255.255.255.0  broadcast 192.168.0.255
     inet6 secret stuff  prefixlen 64  scopeid 0x20
     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 0xfe3c-fe3e

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)

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Dale]

Alexandru N. Barloiu wrote:
> 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. 
>
>


I don't use modules, except for nvidia-drivers.  The network drivers are
built into the kernel.  When I first switched, I restarted all the
related stuff but it still wouldn't work even tho I had not rebooted.  I
only rebooted just in case it might help.  Still not sure if rebooting
makes a difference.

Any more ideas?

Dale

:-)  :-) 

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Alexandru N. Barloiu]

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. 

[gentoo-user] Switching from eudev to udev, disaster.

[Dale]

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  mtu 1500
    inet 192.168.0.100  netmask 255.255.255.0  broadcast 192.168.0.255
    inet6 secret stuff  prefixlen 64  scopeid 0x20
    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 0xfe3c-fe3e 

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)