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.
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?
Any other suggestions on how to generate any meaningful logs for a bug report?
Thanks in advance,
Beat