I’ve disabled NetworkManager in favor of systemd-networkd but when I do I am not able to boot past grub.
Re-enabling NetworkManager allows me to boot back into the OS.
This the latest “user” version: neon-user-20241110-0746.iso
What is the problem? I have not run into this issue with Debian or Ubuntu.
Hi - so folks can have the best context to help you, what exact steps did you take to disable NetworkManager and install/activate systemd-networkd?
Also, what exactly do you see when you try to boot with systemd-networkd - does the system simply freeze at the GRUB menu, or do you see specific error messages?
systemctl stop --now NetworkManager >> systemctl disable NetworkManager I’ve also added systemctl mask NetworkManager all accomplish what I need them to.
systemctl enable sytemd-networkd as well as systemctl enable/start systemd-resolved and then configure in /etc/systemd/network/xx-lan.network
after clicking my selection in grub, screen goes blanks with flashing cursor.
It may then be helpful to check sudo journalctl --boot=-1 (if the previous boot was the one that stopped) and see what the last thing was that happened before the blank screen/flashing cursor point.
Ubuntu 24.04 introduced Netplan into the mix for desktops, and my hunch is that trying to switch NetworkManager for systemd-networkd without “telling” Netplan about it in some way might be causing something to get hung up - but I could be way off there.
Nothing notable in boot logs after I revert back to NetworkManager.
I’m quad booting and I run vanilla Ubuntu 24.04.1 and UbuntuServer 24.04.1 with KDE/Plasma (5.27) on top, both have NetworkManager masked, Netplan is a “front end” that works with both systemd-networkd or NetworkManager.
I suspect something is looking for NetworkManger in order to boot and not finding it (obviously) when it’s disabled.
What about the boot logs from when you had tried to boot with systemd-networkd in place?
If booting when trying to use systemd-networkd is silently failing, then the last messages in the logs for that boot should be substantially different than any normal boot, since the system isn’t continuing on to a graphical environment, you’re not logging in, etc.
So…
I was looking for “errors” in the logs, and boot log. Nothing of any significance. Then I searched for “warnings”, journalctl -p warning -b…and I see a “nomodeset” warning, not loading the graphics drivers. I checked /etc/default/grub, nothing, there was no “nomodeset”. So, long story short, I searched it up, specifically KDE Neon. I found a couple of users with the same issues a few months ago, they updated the kernel to the latest and problem gone.
I gave that a try, went to the latest mainline kernel, 6.11 and no more issues. I don’t know why, bug in the kernel maybe, but that’s doesn’t explain why I couldn’t get into a terminal with CTRL + ALT + F2.
Problems gone, everything seems normal. I don’t like doing that or having to do something like that (kernel change) and especially when I don’t know what the real problem was, but it’s done.
Thanks for your input. I wrote it off to a bug and would’ve waited to see if the situation changed with updates, but read your post and thought I should triple check the logs.
It’s kind of crazy how many independently-developed moving pieces come together in an operating system - perhaps just the right (wrong?) combination of hardware and software pieces was causing an issue with 6.8 and not with 6.11? Glad you’re up and running though!