On 3/9/22 16:20, Beat Kuster wrote:
Hi Dusty
Thanks for your fast reply!
I'm not sure if I understand your proposition correctly. I do have physical access to
the system but when the boot process stalls, it does not reach the login prompt. So even
if I would set a password for my account, I never get the chance to login.
Ahh. I thought the machine was just not getting networking, but otherwise was OK, which
means you would have been able to log in on the console.
However, I just reproduced the boot process stall now (Wed 2022-03-09 around 20:53 UTC)
and then forced physical poweroff after 5min of hanging there. After booting the working
release (35.20220103.3.0) I checked the logged boots with $ journalctl --list-boots:
-5 05ea07dd8f6d437a966c7296de773fe3 Mon 2022-02-21 20:42:08 UTC—Tue 2022-02-22 02:00:24
UTC
-4 94ec3894d8b54af98ab677bc14b62d77 Tue 2022-02-22 17:37:04 UTC—Tue 2022-02-22 17:44:57
UTC
-3 c653f3e3815a470485af6d0fbc1ab728 Tue 2022-02-22 18:06:06 UTC—Tue 2022-02-22 18:07:08
UTC
-2 90c02bf939964260ba78960196601484 Tue 2022-02-22 18:08:24 UTC—Tue 2022-03-08 02:00:59
UTC
-1 caa89f6a944d4b4b9d85839ff1664796 Tue 2022-03-08 17:18:50 UTC—Wed 2022-03-09 20:47:01
UTC
0 143ab2c95037459b8458b8bca259132b Wed 2022-03-09 21:00:59 UTC—Wed 2022-03-09 21:02:07
UTC
Unfortunately, as you can see, the stalled boot process around 20:53 does not show up.
And as expected, checking boot 0 does not show anything strange because it brought up the
system correctly and I could SSH in. Maybe the physical poweroff is preventing journalctl
to persist the logs?
It depends on how far along in the boot process the system got before it hangs.
Any other suggestions on how to generate any meaningful logs for a bug report?
Unfortunately without setting up a serial console on the machine so you can scrollback and
copy/paste your only real options is to stare at what scrolls across the screen and try to
derive any clues that way. Maybe recording a video on of the screen would help?
Dusty