Does anyone have any issues with 6.5.7? I updated yesterday and could not boot.
(1 of 2) A start job is running for /dev/mapper/root (30s / no limit) (2 of 2) A start job is running for /dev/disk/by-uuid/MY-UUID (30s / no limit)
Also during update my display resolution was set to 640x480 and I could not change it, so decided to reboot. I use a popular nowadays setup with LUKS encryption + unlock on TPM2, secure boot. I thought I messed with configs somewhere so started chasing that: changing configs and rebooting with no luck. The solution was to restore kernel 6.5.5 and everything booted back up without a hiccup. I am dreaded to see what happens during next kernel upgrade.
This is not asking for hep, more like a PSA if you have setup similar to mine, be aware
To those who stumble on this post in the future, I have found a solution that was in my case not knowing my system well enough. Since I decided to use Unified kernel images, I used mkinitcpio to compile those, but for some reason I used sbctl-bundle on top of that, which in itself is not any harm, just extra unnecessary work, and every single time I referenced an initramfs image from /boot which was an old one and was installed prior to me switching to UKI. When I read on Arch Wiki that I can delete those initramfs images from /boot - I deleted them, then had problems with sbctl bundle, and ONLY THEN it clicked - any new kernel install/upgrade doesn’t generate initramfs in /boot but instead directly in UKI.
This is also good news because sbctl author announced deprecation of the bundle feature in the future.
Have you tried to update to kernel 6.5.6 to bisect a bit further? This would help to find the commit that’s responsible for that, after which you can report the bug and usually get a swift response (and meanwhile you can then just revert that single commit). That’s what I did when I had keyboard issues with a recent Ryzen laptop (it also turned out the fix was surprisingly simple, just had to comment out a few lines that were inserted by the “faulty” commit and I even proposed my first patch back then, then an AMD guy did a more proper fix and it’s now in Linux stable).
I have not - this is a work laptop, I was kind of stressed to fix it ASAP so that I can continue working. I might try that at home
Just a suggestion, I always have both the latest and LTS versions installed concurrently. Have the current version as what boots and pacman will update both when you -Syu.
Then if you have any problems just boot the LTS. Grub automatically offers it in the advanced menu or you can manually point to it
I’m inclined to have both, I guess hiw does Debian based distros keep multiple versions? I know I have to clean them up because they are kept like 5 versions or so
Would depend on the distro. Mint keeps a few older kernels and puts an option in grub to choose them. Debian family doesnt do rolling release in the same way as arch so it’s a different paradigm