Hello all, I created an account to ask this question.
The latest update forced me from kernel 6.15 to kernel 6.16, which unfortonately does not boot my system. It just ends in a blackscreen and there is nothing on the screen. there is no boot record in journalctl -b -1 either.
However, that is not what I’m asking. There seems to be quite some boot issues with 6.16. It seems to be a problematic kernel version and I’ll follow up on it elsewhere, not here.
I managed to save my system by booting with a liveusb (which has an older kernel), chrooting to my installation and reinstalling 6.12 kernel, which boots my system fine.
I had one question and on feedback:
Feedback:please do not forcibly remove old kernels, exactly for this reason! If 6.15 had not been removed after installing 6.16, things would not have been so painful (no need for a liveusb etc).
Question: I want to get rid of 6.16 from my system, but can’t. When I try to uninstall it, I get the following error:
$ sudo mhwd-kernel -r linux616
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing linux616-headers breaks dependency 'linux616-headers' required by linux-headers-meta
:: removing linux616 breaks dependency 'linux616' required by linux-meta
:: removing linux616-virtualbox-host-modules breaks dependency 'linux616-virtualbox-host-modules' required by linux-virtualbox-host-modules-meta
How can I remove this broken kernel from my system?
Meta packages get installed when a kernel marked as EOL was not removed by the user before I removed them from the repositories. linux615 and it’s extramodules got removed yesterday also from stable branch.
You can also try a different kernel without removing 6.16.
For example, you could also install 6.12. Then you can choose which one to use in Grub. Having multiple kernels installed also makes it easier to determine whether it’s actually the specific kernel causing the problem.
As I wrote above, I already downgraded to 6.12 by using a liveusb session (and chroot). As I also wrote above, the issue (whatever it is) was introduced in 6.16.
Thanks, removing linux-meta packages got rid of 6.16 from my system.
I still think it’s a bad idea to remove the previous kernel after an update. It makes recovery much harder. The better way would be to keep kernel N-1 after update and delete N-2.
Unfortunately this is one of the things that are maybe less than perfect in arch. The update process starts with deleting the old kernel. Which means on the next update you will be left with unbootable system if you stay with EOL kernel only.
Now in that paticular case you did end there because of some other bug (nvidia or mesa probably), but for 90% of the people it will work and the meta-package will automatically add a newer kernel.
At the end of the day, manjaro as arch based system is a hands on system. If you don’t want to be bothered with kernel changing every 3 months - use an LTS kernel.
I think the better way is to keep the LTS kernel installed as fallback. Please notice the stable branch is really meant to run the 6.12 LTS kernel. Trying a newer one doesn’t imply to remove the default one. If you choose to do so, you aren’t stable anymore.
Which points to the 5.4 LTS kernel. Our meta packages will point to the last available after the dropped kernel. So 4.19 got dropped and 5.4 installed. 6.14 got dropped and 6.15 installed, 6.15 got dropped, 6.16 installed … Similar as Arch would do it on regular major kernel updates.
In the past we had linux-latest, which automatically installed the latest mainline kernel when it went stable.
Let’s assume the purpose of metapackages is to intervene if the currently actively used kernel is lost during an update, making the system unbootable.
If someone isn’t using the latest hardware, falling back to the latest LTS kernel would be a very good decision.
If someone is using relatively new hardware, falling back to the LTS kernel can cause real problems. In that case, the kernel after the one that is being dropped is the best choice.
If an old LTS kernel is being dropped, the last available LTS kernel is probably the first choice.
The decision as to the best choice can be guessed by a helper, but it will never be perfect.
Conclusion:
Even if these helpers exist, they are a stopgap measure. The responsibility remains with the administrator.
It is his job to replace the kernel with a good choice when it reaches EOL and before it disappears from the repositories.
