You are not logged in.
Hi All,
After years of having no trouble with Arch, the upgrade today made my system unbootable.
1. I updated today to linux-lts-6.12.58-1, and the system didn't boot. Bootloader loaded. But I got no console output, no network connection. Ctrl-Alt-Del worked to reboot, but journalctl -b -1 showed no logs from the failed boot. (Failsafe mode did the same thing)
2. I downgraded to linux-lts-6.12.57-1, and had the same behavior.
3. I downgraded further to linux-lts-6.12.56-1 (by downgrading all packages to the state on 2025-11-01, one day before 6.12.57-1 was introduced), and the system booted fine.
How do I go about debugging the problem if I have no console output, and no logs, and no network activity?
Any help would be appreciated. Thanks in advance
GI
Offline
PS: All my other machines upgrade fine to the latest linux-lts. I use similar configurations on all of them (no display manager, autologin console, etc.). The only notable difference on the machine that won't boot is that it has a few docker containers that auto-start, more complex network rules (along with a systemd-networkd-wait-online requirement), more complex partitioning (still all ext4, but one raid array), and slightly different hardware (desktop; intel). I assume if the system isn't getting online, I would at least see console output (or logs), and if the raid array isn't coming online I would also see console output / logs (the main boot partition is not raid).
so something in the boot process seems to be hanging, yet is responsive to the 3 finger salute ctrl-alt-delete
Offline
https://wiki.archlinux.org/title/Genera … l_messages and only boot the multi-user.target (2nd link below) but my gut-feeling is that you're booting and older kernel (forgot or failed to mount /boot or mounting a spurious /boot partition) and only restoring the previously used kernel fixes that by aligning booting an installed kernel (modules)?
Offline
Thanks @seth. I enabled debugging messages; I'll see what it spits out when I'm able to upgrade + reboot it next.
After a bit of digging I suspect it's mounting the wrong root partition. I supply the `root=...` option correctly. However, the partition table has partition #2 with type 8404 (Linux root x86_64), and my actual root partition with type 8400 (Generic Linux). So maybe that's causing a problem with the new kernels.
I'll post back Monday if I can either diagnose the problem, or solve it once debugging messges are enabled.
Thanks again.
Offline
Don't reference the root partition via the device node (sda2, nvme0n1p2 etc) but use the UUID - the device node order isn't stable ie. sda and sdb can switch places any time.
Offline
Thanks. I just did some digging. If I set the partition types correctly and include `systemd` in my mkinitcpio hooks, then I don't have to specify a `root=...` option, and I don't need entries in /etc/fstab.
I've lost count of how often I've messed up an install because I put the wrong UUID's in there. (It was a quick fix, but annoying).
I switched to this on my home computers, and it works great. (Now I don't even need to ensure I have good mount options; systemd seems to choose discard, relatime etc for me automatically). I'm going to run with this, and prey my work computer upgrades and boots Monday morning.
Offline
Offline
Eye never did no how two spell. So sew me.
Offline