Gone Baby Gone
Updated yesterday on the build machine...
Since then NO NADA ZERO network... no matter what interface I put in the machine, it does not register
ceni sees no hardware interfaces at all
No errors, nothing obvious anyway...
I have only just now calmed down enough just to begin troubleshootiing.. I am pissed! First VirtualBox and now the network?
I can boot to any other partition on the same machine and have a perfect network with all cards and usb wifi dongles seen
Just not the build partition
Attack please.... let me know what you want to see
It may be related to this issues... Not sure, but it seems similar
Wired Network Manager weirdness (http://sitakom.blogspot.com/2015/06/how-to-fix-wired-network-interface.html)
Connected again.. this is the build partition... I just kept plugging and unplugging the cat5 and it suddenly came up... tried several different cables, routers and ports already so that is not the issue
Ceni still sees no hardware interfaces, this is still an issue
Your network interfaces show with either:
ip link
or
ifconfig -a
if so, they have the typical names - eth0, wlan0 etc ... Pretty sure the default for systemd is to give the interfaces names like eno1 etc ... and Debian reverts back to the old standard (Arch does not).
What distro(s) are on your other partitions?
All partitions are VSIDO in some varying stages... (I have so little time for anything other than VSIDO)
Several are current installs of VSIDO and/or just prior to the last dist-upgrade of this build partition
eth2 below is another card I added to eliminate this as an onboard realtek / mod issue
vastone@vsido:~$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:24:1d:76:86:84
inet addr:10.0.1.22 Bcast:10.255.255.255 Mask:255.0.0.0
inet6 addr: fe80::224:1dff:fe76:8684/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:619404 errors:0 dropped:11 overruns:0 frame:0
TX packets:349360 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:710369622 (677.4 MiB) TX bytes:31410915 (29.9 MiB)
eth1 Link encap:Ethernet HWaddr 00:24:1d:76:86:86
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth2 Link encap:Ethernet HWaddr 00:13:46:31:22:fd
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:2168 errors:0 dropped:0 overruns:0 frame:0
TX packets:2168 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:216012 (210.9 KiB) TX bytes:216012 (210.9 KiB)
I forgot to ask in my previous post - how do you manage your network ceni or wicd?
wicd (and gnome network-manager) are incompatible with the /etc/network/interfaces file. I've actually had a similar issue (fedora and debian) where the (gnome or wicd) network manager service fails if there is a /etc/network/interfaces file and the result is there is no network. Usually the system hangs for a bit until the service fails then finishes booting with no network connectivity. I can't recall if the devices - eth0, eth1 etc .. are not created in that scenario; if true ceni would not be able to list them.
If you're using wicd, you can fix the problem by just removing/renaming the /etc/network/interfaces file; if you're using ceni, you'll have to disbale the wicd service and purge the configuration files.
So eth0 and eth1 are onboard ethernet not pci cards?
Is there a kernel version difference between your build partition and the other installs? Gordon also seems to be having an issue with a realtek module at the moment. Boot into a partition that has network conectivity and get the results of:
lsmod <-- or lsmod | grep rt
and
lspci | grep Ethernet
Should be able to get the required realtek module needed for your ethernet. You can then try modprobe on the effected build and see if it loads.
I do mine the old school way of just editing and managing /e/n/i ... I do use ceni to check issues such as these but not to save anything
Yes, eth0 and eth1 are onboard. I did in fact have a similar issue about a month ago on my duplicate machine that runs all the backup services (www, files, music, etc) ... it resolved itself eventually (through updates) but I did have to add the same NIC to that machine that is now eth2 on this one just to get to the internet... Unlike this machine, it loaded right away and I had no issues
There are no kernel version that are different on the partitions that do work, the only difference is that they were not updated to the latest SID levels
I will get the lsmod and lspci results soon and post them
From this partition (one with issues)
vastone@vsido:~$ lspci | grep Ethernet
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
05:06.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
Info from second partition with same kernel
vsido@vsido:~$ lspci | grep Ethernet
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
05:06.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
This all appears to be a systemd issue... on the boot of the other partition I noticed a halt on the systemd load as it paused with a time out and red flag until ifup eth0 loaded, which it eventually did
I rebooted to this partition and did not see a pause, and did not have any connectivity, all was down and dead again
I ran
sudo ifup eth0
and am now connected...
I am getting a wee bit tired of all the shit lately of debian and/or systemd (since one depends on the other, are they the same now?)
dizzie posted a script on how on arch you can go from systemd to openrc in 28 seconds... when that is ported to debian, I will experiment
Looks like realtek - or whoever maintains their drivers for linux - are dropping the rt fro the name.
lsmod | grep 81 <-- grep 84[code]
should list the modules that need loading for that chip.
dizzie posted a script on how on arch you can go from systemd to openrc in 28 seconds... when that is ported to debian, I will experiment
But would you lose access to the debian repos since systemd will be embedded as a dependency? Part of the experiment, I guess.
That will suck big time if intermittent hardware outages are a side effect of systemd - almost a step backwards to the days when most distros weren't hardware compatible OOTB.
http://without-systemd.org/wiki/index.php/Main_Page (http://without-systemd.org/wiki/index.php/Main_Page)
Quote from: PackRat on June 05, 2015, 06:41:36 PM
dizzie posted a script on how on arch you can go from systemd to openrc in 28 seconds... when that is ported to debian, I will experiment
But would you lose access to the debian repos since systemd will be embedded as a dependency? Part of the experiment, I guess.
That will suck big time if intermittent hardware outages are a side effect of systemd - almost a step backwards to the days when most distros weren't hardware compatible OOTB.
There is no experiment, for all my huffing and puffing, we are dedicated to debian... They need to take notice though, IMO ... how is the issue, what venue I mean
It does in fact feel like the old days again, and maintaining a broken distro is not my desire of fun
Decided to try a dist-upgrade on my second and duplicate hw machine ... been holding off on it due to the nature of things... Grave warnings regarding serious bugs with systemd updates from listbugs... I will hold off a bit longer
I know we live in SID, I know this is the nature of this beast, but it seems to have gotten worse lately ... with no real explanations
You ever get more information on this issue? Especially -
Quoteceni sees no hardware interfaces at all
I don't roam too much anymore with the laptop so I was going to disable the wicd service and use ceni to configure my network - saves a lot of memory.
Epic fail.
Ceni does not see the network cards - eth0 and wlan0 - as hardware interfaces, but rather logical interfaces; and no longer scans for wireless networks. I used the current iso to get into a live session. Ceni worked fine - so this is a recent change - and I created a /etc/network/interfaces file to copy over to the harddrive. It worked (so it's a work around for now).
Tried to do a search and got some hits but nothing pertinent.
Hey PackRat...
No, I have not found the reasoning behind this issue... I did correct my failures by bonding the two nics and a ifup bond0 works flawlessly on bootup where ifup eth0 still fails. I have noticed activity on the ifupdown tools coming from the devs but nothing yet fixes that issue
On the ceni side, it is broken and going to the Siduction Ceni Repo (http://packages.siduction.org/base/pool/main/c/ceni/) and getting the latest version does nothing to correct it. I will log into there later and file a bug report
Still seeing the same thing as you PackRat (and I am parking an image)
(http://www.zimagez.com/miniature/screenshot2015-06-1013-31-36.php)
(http://www.zimagez.com/zimage/screenshot2015-06-1013-31-36.php)
VastOne, under '/etc/init.d' directory do you have any network related init scripts aside from 'networking', like 'networking.save' and 'networking~' ? If yes remove 'networking.save' and 'networking~' files and reboot.
Just a shot in the dark!
Cheers!!!
And regarding the boot up process and extra time taken to bring the network interfaces up you can supposedly solve it by a simple modification in the '/etc/network/interfaces' file. In this file replace all instances of 'auto' with 'allow-hotplug'. For example change,
allow-auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
to
allow-hotplug lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet dhcp
Save the file and reboot. I didn't test this. It's another shot in the dark!
Cheers!!!
This article though not directly related, could be useful,
Switching to systemd-networkd (https://www.joachim-breitner.de/blog/664-Switching_to_systemd-networkd)
It's past midnight here, so I got to but knowing VastOne he won't give up easily! All the best!
Cheers!!!
Got both Debian and Arch to run with OpenRC, some systemd crud still hiding, means I need more testing boss 8)
But it looks very doable, but but but(t) who would be interested in a systemd free system? For the general user, systemd is fine, and less annoying ;)
As for Ceni, I know you have, but I still have to ask? Got all the firmware drivers installed?
@hakerdefo, nothing other than networking in init.d and I have known about the allow-hotplug issue for a while and had that set. Keep in mind that these very same configs are in other partitions and work fine including all firmware drivers @dizzie
This is my /e/n/i
#auto lo
#iface lo inet loopback
#allow-hotplug eth0
#iface eth0 inet static
# address 10.0.1.22
# broadcast 10.255.255.255
# gateway 10.0.1.1
# netmask 255.0.0.0
# network 10.0.0.0
# The primary network interface 10.0.01 network
allow-hotplug eth0
allow-hotplug eth1
allow-hotplug bond0
auto bond0
iface bond0 inet static
address 10.0.1.22
netmask 255.0.0.0
network 10.0.0.0
broadcast 10.255.255.255
gateway 10.0.1.1
# dns-* options are implemented by the resolvconf package, if installed
# dns-nameservers 8.8.8.8 8.8.4.4
# dns-search example.com
up /sbin/ifenslave bond0 eth0 eth1
down /sbin/ifenslave -d bond0 eth0 eth1
As you see, the bond0 is nothing different than what eth0 should be doing, except that it works on bootup and eth0 does not
This is beyond bizzare
I would file a bug report for ceni, but it is taking too long to get approved to make a bug report over on Siduction
Hey VastOne try this. First stop networking,
sudo invoke-rc.d networking stop
Backup your current config,
sudo mv /etc/network/interfaces /etc/network/interfaces.bak
And save the following as your new '/etc/network/interfaces' file,
auto bond0
iface bond0 inet static
address 10.0.1.22
netmask 255.0.0.0
network 10.0.0.0
broadcast 10.255.255.255
gateway 10.0.1.1
slaves eth0 eth1
bond_mode active-backup
bond_miimon 100
bond_downdelay 200
bond_updelay 200
Start networking,
sudo invoke-rc.d networking start
Now what does ifconfig show?
ifconfig -a
Cheers!!!
Ran into this crap too. Installed wicd-curses, and got things working again.
Latest kernel (4.0.0-2-amd64 #1 SMP Debian 4.0.5-1 (2015-06-16)) and/or latest systemd has killed the network within V-Box
This shit is getting old
Blaze, wicd-curses? I will have to give it a try. WICD in VSIDO sees no eth0 available or any card for that matter
Turns out udev is renaming eth0 as enp0s3 ... ifconfig -a shows it as enp0s3 in /e/n/i
Changing that in /e/n/i and WICD preferences corrected it
Fuck me WHAT IS WRONG WITH eth0? BEEN THAT FUCKING WAY FOREVER
Predictable Network Interfaces - systemd (http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/)
I for one have not seen the problem he describes since Redhat 6/7 (the original pre-Fedora versions) - which would be old technology, not new. I have never seen anyone have this issue in a help forum.
If I was really cynical, I would say it's a systemd work around for a persistent Red Hat bug - :P
You can set up your computers to keep the eth[X] and wlan[X] nomenclature - with a udev rule, I believe - maybe the Sid udev rule got broken during an update? My recent clean install of Debian Testing has eth0, eth1.
I believe I am seeing it because I do have multiple nics in all my production machines. That is good knowledge PackRat I appreciate that article, thanks man
The issue with this I have is why not have some simple message on a your udev update that says 'hey if you have multiple network cards you might want to be aware that there will be or could be a possible name change and oh by the way just do a iconfig -a and check the new name.'?
Nothing like that ever happened, tis the new world order
That would have been nice.
What also needs to happen is Debian get off the snide and update/improve their wiki so it's on par with the Arch wiki - especially as it pertains to systemd. The distros are just different enough under the hood that the Arch wiki doesn't give you all the answers.
^ I agree, the debian wiki is extremely lacking
I have tried all the proposed methods to get ethx back as the defaults and keep failing
For some reasons, I am not at all surprised
Hi there VastOne! I think you can achieve the same without changing your '/etc/network/interfaces' file via udev rules.
sudo ifconfig
And note down MAC addresse(s) of your ethernet device(s). The output after "HWaddr" is the physical hardware address. For example '00:1A:2B:B3:12:21'.
Next open your text editor with sudo and create a file like this,
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1A:2B:B3:12:21", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1B:2C:B4:23:32", NAME="eth1"
Change value of 'ATTR{address}==' with the MAC address of your device and change value of 'NAME=' with the desired interface name for that device.
Save the file in '/etc/udev/rules.d' directory with the name '70-persistent-net.rules'. In case the file exists rename the original file to '70-persistent-net.rules.bak'.
Reboot and check.
Cheers!!!
Quote from: PackRat on June 20, 2015, 04:22:07 PM
Predictable Network Interfaces - systemd (http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/)
Why not using solution 1 or 4 from the official documentation PackRat posted? Don't they work on sid?
@aibo & @hakerdefo
I have tried all of the mentioned solutions verbatim without success
Yeah, it got wonky for me with ceni and wifi after systemd 215-18 and the jump to 220-x. I did delay on that jump. I have gone to connman to configure wifi (eth0 is dhcp and it does it automagically for me) on 2 testing and one sid(uction) machine Others posting elsewhere who used ceni are going to the cli of network-manager or configuring the networking service of systemd. All 3 have a specific service set up for systemd to use, just don't use 2 services. So far connman (using the interface connmanctl) works on (1)my testing wayland-weston hdd, (2)a sparky testing kde on a netbook (using the qt gui cmst for connman) and (3) on an amd netbox with sid(uction) and lxqt. ceni is just not going to function that well with systemd, and my guess for wicd (I did take a peek at the git page) is that it is not that well suited for systemd either.
I think an analogy is that the usage of init 3 and init 5 in a tty worked for a while with systemd, but now starting weeks ago using init3 and 5 for me killed eth0 and then later polkit and I would have to restart the internet in ~/.
One possible undocumented thing about connman is that using "connman agent on" does not work to enter the script to enter your psk phrase. However using the interreactive interface connmanctl <enter> new line > agent on will bring up the script to enter the name of the passphrase after you ask to connect the wifi service.
peace
@paxmark1
Thanks for that information and detail
I will definitely look into connman as more of a solution especially now that it appears ceni is dead
This all feels as if devs are just saying Fuck It and giving up on projects that need to be run with or altered for systemd. Is this collusion?
More fun... (If I had not shaved my head today ... I would just pull all my hair our one by one)
loaded connman
ran connmanctl
exited out to learn more about it (was expecting a script or menu system)
Now my network is deader than hell ...
Removed connman thinking it would restore to old
NOPE
Got my network back... for whatever reasons connman removed all resolv.conf information
I restored the settings and am back up
Seems like moving to connman is a popular choice right now ... hit an miss though (it never worked for me the 2-3 times I tried it).
QuoteThis all feels as if devs are just saying Fuck It and giving up on projects that need to be run with or altered for systemd. Is this collusion?
I don't think it's collusion. Now that systemd has progressed well beyond an init system and keeps evolving, (unpaid) devs aren't going to spend the time trying to keep pace. They will drop side projects, or move into non-systemd OS's.
I ended up digging into systemd-networkd and figured it all out... I am now running a bond setup using simple scripts within the structure of systemd-networkd
It is actually simple and elegant in it's design
When I get around to it, I will write up what I did for this type of bond and network setup
This release of ceni has corrected the issues we have seen (http://aptosid.com/debian/pool/main/c/ceni/)
I will package this with the next release of the ISO
It works with wired and wireless on my laptop.
I'll point this out here since I don't want to start a whole new thread about it.
Now that Debian has moved to the systemd convention of naming network interfaces enp0s3 etc .... any custom firewall rules you were using are most likely not working because the firewall was configured for eth0, wlan0 etc ... If I'm not mistaken, iptables just fails silently in the background it the interface doesn't exist.
Something to keep in mind when updating to the latest builds and restoring backups of your system configuration.
Quote from: VastOne on June 25, 2015, 02:34:14 AM
I ended up digging into systemd-networkd and figured it all out... I am now running a bond setup using simple scripts within the structure of systemd-networkd
Quote from: PackRat on July 07, 2015, 06:52:32 PM
I'll point this out here since I don't want to start a whole new thread about it.
Now that Debian has moved to the systemd convention of naming network interfaces enp0s3 etc .... any custom firewall rules you were using are most likely not working because the firewall was configured for eth0, wlan0 etc ... If I'm not mistaken, iptables just fails silently in the background it the interface doesn't exist.
Something to keep in mind when updating to the latest builds and restoring backups of your system configuration.
Some more weed for the pipes we must now smoke....
I upgraded to the latest SID Debian kernel (4.0.0-2-amd64 #1 SMP Debian 4.0.7-1 (2015-07-06) and booted to NO FUCKING NETWORK!
Good ole ifconfig -a shows ... wait for it, wait for it... YOU GUESSED IT! eth0 and wlan0 ARE BACK
And I have just officially gone insane!
Even though I specifically setup systemd-networkd to be the 'official' gatekeeper and network starter here, it failed due to these name changes again
What in the hell is Debian/Systemd/udev doing?
I know what they are doing...
They know they have the freaks over at VSIDO Linux to test and bait this shit on
(Mad dev laughter in the background) ... 'Go ahead Lennart and do it, those guys will figure the shit out anyway'
Ian Jackson is also in the background laughing his ass off right now with the biggest shit eating I TOLD YOU SO grin ever seen
It did not make these changes on the build systems, enp0s3 is still in play...
However, I do have the rules in place on this system to 'rebrand' everything to eth0 and wlan0 so my guess is is that the kernel matched the needs of udev/systemd and those functions are now working
I will let you know Lennart
QuoteIan Jackson is also in the background laughing his ass off right now with the biggest shit eating I TOLD YOU SO grin ever seen
No doubt
(http://s10.postimg.org/jo1cbyw3p/systemd_jpeg_7479.jpg) (http://postimg.org/image/jo1cbyw3p/)
I told you all I would keep you updated...
I have had a file for quite a while that resides in /etc/udev/rules.d called 70-persistent-net.rules
I had to create this file quite sometime ago because something changed my eth0 to eth1 and made a mess so this kept my ethx's in order
70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:24:1d:76:86:86", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:24:1d:76:86:84", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x1814:0x0201 (rt2500pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:12:17:66:73:91", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
# PCI device 0x1186:0x1300 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:46:31:22:fd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
# USB device 0x:0x (zd1211rw)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:2d:4b:23:fd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan1"
As I assumed, I deleted this file and rebooted back into my systemd network
So as hakerdefo pointed out in his earlier post, this is the solution but it obviously had been blocked until the latest kernel had 'allowed' it again...
We seem to be working on so many different changing levels...
Debian
Debian SID (Yes very distinctively different than Debian)
Systemd devs
Kernel Devs
I believe this is the life of SID now and may be this way until all this irons out and standards are once again hammered into place
I live for this... I complain a lot, but this is fun and a challenge... I believe we are the core users who are figuring all this shit out and this work is being seen and people are taking notice
For all who do assist and work to make it right for VSIDO and then the rest of this bizarre ecosystem, I salute you all!
Thanks for this, VastOne.
Quote<snip> I have had a file for quite a while that resides in /etc/udev/rules.d called 70-persistent-net.rules
<snip> I live for this... I complain a lot, but this is fun and a challenge... I believe we are the core users who are figuring all this shit out and this work is being seen and people are taking notice
I went the opposite way and commented the 70-persistent-net.rules out so on reboot my interfaces would have the new nomenclature (getting use to the systemd way). Interesting that ceni had no issue with detecting them (wired and wireless on desktop and laptop), but systemd-networkd just barfed. Using ceni configured interfaces on both computers for now since I don't do much roaming with the laptop anymore.
I'm sure it's a relatively simple fix to get systemd-networkd to recognize the new interface name, but that can wait.
I used this page to setup my systemd-networkd bond (http://www.reversengineered.com/2014/08/21/setting-up-bonding-in-systemd/)
From that I gleaned that if you ran
systemctl enable systemd-networkd
systemctl start systemd-networkd
then your systemd network would auto start and all would be good
When my device names switched back to eth0 and wlan0, this file
/etc/systemd/network/10-create-bond0.network:
[Match]
Name=enp1*
[Network]
Bond=bond0
auto changed to
[Match]
Name=eth*
[Network]
Bond=bond0
Which is good, but I do not believe systemd-networkd is auto starting. Once I changed that file back to show the original enp1 value, I did a
systemctl enable systemd-networkd
systemctl start systemd-networkd
and the network came up
Way too much manipulations to get a simple network going
This arch wiki page starting with Configuration examples (https://wiki.archlinux.org/index.php/Systemd-networkd#Configuration_files) is great for setting up systemd-networkd config files
Quote from: PackRat on July 08, 2015, 05:40:21 PM
I went the opposite way and commented the 70-persistent-net.rules out so on reboot my interfaces would have the new nomenclature (getting use to the systemd way). Interesting that ceni had no issue with detecting them (wired and wireless on desktop and laptop), but systemd-networkd just barfed. Using ceni configured interfaces on both computers for now since I don't do much roaming with the laptop anymore.
I'm sure it's a relatively simple fix to get systemd-networkd to recognize the new interface name, but that can wait.
I think we both did the same thing, removing what was in 70-persistent-net.rules letting systemd-networkd take over
Ceni is on board now with the name changes and systemd-networkd/udev changes and saves it all to /e/n/i which seems to take precedence over whatever is in /etc/systemd/network
I think systemd-networkd is barfing because it may not be starting on a reboot...
I did all the file editing and systemctl restart steps you outlined; systemd-netword just did not recognize the device name change. After doing the basics, I disabled systemd-networkd, rebooted, and ran ceni to get a working network.
I also find it interesting that my desktop devices are enp2s0 and wlp3s0 while the laptop is eno1 and wlo1 - got me curious on how those device names actually get generated - other than the "en" and "wl" part.