Re: Kernel panics on boot with fresh testing install on ASUS UX501J notebook
[Wanderer wrote:]
> It really does sound like he's been doing multiple reinstalls, and even
> probably reinstalled buster after the latest failed install of testing (snip)
This is correct: I reinstalled Bullseye a few times and am currently using a
fresh Buster install (with non-free firmware).
[Alexander wrote:]
> Every .jpg URL returns "Access Denied" message for me.
Hmm, I'm sorry to hear that. I tried the URLs in an incognito window in an
attempt to rule out any kind of session being necessary, but maybe I was
mistaken. Can anyone else confirm this? In that case I'll try another image
hosting service. Sorry for the trouble and thanks for your time.
> The way I would approach this problem is by making boot logs persistent (snip)
Thanks, I'll look into this!
> I also recommend you to check what BIOS version this laptop is using currently
> and update it to most recent one from official Asus support website.
Ah, I forgot to mention this in my OP, but indeed I also updated the BIOS.
There was a minor update available (still, from a 2015 version to a 2019
version), but it made no difference.
[Greg Wooledge wrote:]
> Yes, that is precisely what I mean. After a dist-upgrade, you have
> both kernels (or more) just sitting there. Simply choose the buster
> kernel from the GRUB menu and see whether it makes the symptoms go away.
Yes, I failed to mention this in my OP, but indeed the 4.19 kernel worked after
the dist-upgrade. That is why I suspected a kernel issue. Then again, I wasn't
sure if it was a faulty upgrade either, hence the eventual reinstall.
> Enabling the persistent journal oneself is simple enough, though. Just
> follow the instructions in systemd-journald(8).
Thank you for that additional pointer!
[Reco wrote:]
> I'd like to suggest a different approach, considering we're dealing with
> kernel panics here. (snip) They've invented kdump (snip) with exact
> purpose of capturing kernel panics and storing kernel crash dumps in a
> persistent way, and crash (snip) for analyzing them.
Thank you for this pointer, I'll also look into using kdump!
To summarize, what I will do over the following days is do an upgrade to
Bullseye again, this time simply falling back on the old kernel to avoid
boot issues. I will then try to isolate logs/dumps using persistent systemd
logs and/or kdump. Hopefully that'll give me some good clues for figuring out
the actual issue(s?). I'll be back on this list then.
In the meantime I'd like to thank you all for your quick, detailed and helpful
responses.
Thom
Reply to: