You are not logged in.
Hi all,
I have a home server that runs Arch. Today I found it like this.
Does anyone know what could have happened here?
moderator edit -- replaced oversized image with link.
Pasting pictures and code
Last edited by EgidioCaprino (2022-07-31 13:11:38)
Offline
There's a kernel oops further up, but the meaningful parts are missing.
Shift+PgUp should allow you to see what came before.
In doubt just film the entire boot process
Offline
Hi Seth,
Thank you for your reply.
I downgraded the kernel and everything is up again
Could it be that the package linux-api-headers wasn't aligned with the version of linux and linux-headers packages?
Last edited by EgidioCaprino (2022-07-31 13:11:26)
Offline
That'd not prevent a boot (except if you rely on some dkms package and that module failed to build in turn)
Either there's a regression w/ the new kernel (do you have an nvidia chip and what kernel versions are involved) or the update failed (forgot to mount the boot partition?)
With a little luck, there's a system journal ("sudo journalctl -b -1", though typically not if you did a hard reboot)
Offline
Hi Seth, thank you for your reply.
No, I don't have a nvidia card. I have an AMD one but I don't have the drivers installed. I only see these two packages
amd-ucode 20220708.be7798e-1
opencl-amd 22.20.0.50200-1
This is the log for the closest boot with the error: https://pastebin.mozilla.org/qYUnk8tM
I don't see nothing strange. Do you?
Do you think I won't have that problem anymore with linux-lts?
Last edited by EgidioCaprino (2022-08-02 06:37:05)
Offline
AMD and the kernel oops tail look like the meanwhile identified https://bbs.archlinux.org/viewtopic.php … 6#p2049636
Last edited by seth (2022-08-02 06:41:59)
Offline
Alright, thank you Seth.
Is that something that will be fixed in Arch packages or do I need to add that boot parameter?
Also, will this kind of issues be less frequent if I switch to the LTS version of the kernel?
Offline
https://bugs.archlinux.org/task/75478 - should™ be by upstream fixed w/ 5.18.16 - and 5.15.59 (what means the LTS kernel is affected likewise)
The kind of issue will be as frequent as somebodies frequency to fuck up
A possible mitigation strategy is to have both kernels installed and if after an update one fails, hope for the other.
(You could also ignore the LTS kernel and only update it explicitly when the main kernel updated w/o problems)
Offline
Alright, thank you for taking the time to explain. Blocking updates of the LTS version seems a good solution, I'll try that. Also, linux 5.18.15.arch1-1 is still broken for me, using LTS at the moment
Offline