UB
Universal Blue•2mo ago
Atom

Sometimes bazzite doesn’t boot

Bazzite stays stuck in the boot process and fail to launch journald How can I debug this ? 
$ rpm-ostree status
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-nvidia-open:stable
                   Digest: sha256:2b4ed5a996290b66056801cf79113dc391ee2a6c808f47aa3ecd49741beaf19b
                  Version: 41.20250216.1 (2025-02-17T16:39:32Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-nvidia-open:stable
                   Digest: sha256:e83bd14e00fcb8dd9aed5954ca408c8b929f37b98a75ca3337c1991227958fb7
                  Version: 41.20250210.1 (2025-02-11T04:12:14Z)
$ rpm-ostree status
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-nvidia-open:stable
                   Digest: sha256:2b4ed5a996290b66056801cf79113dc391ee2a6c808f47aa3ecd49741beaf19b
                  Version: 41.20250216.1 (2025-02-17T16:39:32Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-nvidia-open:stable
                   Digest: sha256:e83bd14e00fcb8dd9aed5954ca408c8b929f37b98a75ca3337c1991227958fb7
                  Version: 41.20250210.1 (2025-02-11T04:12:14Z)
No description
18 Replies
Atom
AtomOP•2mo ago
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Mon 2025-02-24 10:31:53 CET; 2min 7s ago
 Invocation: 4d6a13d688aa4bf0a55e5ad3c94ec1f5
TriggeredBy: ● systemd-journald.socket
             ● systemd-journald-dev-log.socket
             ● systemd-journald-audit.socket
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
   Main PID: 928 (systemd-journal)
     Status: "Processing requests..."
      Tasks: 1 (limit: 57332)
   FD Store: 72 (limit: 4224)
     Memory: 74.8M (peak: 75.4M)
        CPU: 9.246s
     CGroup: /system.slice/systemd-journald.service
             └─928 /usr/lib/systemd/systemd-journald

févr. 24 10:31:53 bazzite systemd-journald[928]: Journal started
févr. 24 10:31:53 bazzite systemd-journald[928]: [🡕] Runtime Journal (/run/log/journal/64a59eff00464eff97af35f39a62de88) is 8M, max 961.4M, 953.4M free.
févr. 24 10:31:53 bazzite systemd-journald[928]: Collecting audit messages is enabled.
févr. 24 10:31:53 bazzite systemd[1]: systemd-journald.service: Deactivated successfully.
févr. 24 10:31:54 bazzite systemd-journald[928]: Time spent on flushing to /var/log/journal/64a59eff00464eff97af35f39a62de88 is 69.725ms for 5486 entries.
févr. 24 10:31:54 bazzite systemd-journald[928]: [🡕] System Journal (/var/log/journal/64a59eff00464eff97af35f39a62de88) is 3.9G, max 4G, 23.6M free.
févr. 24 10:31:54 bazzite systemd-journald[928]: Received client request to flush runtime journal.
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Mon 2025-02-24 10:31:53 CET; 2min 7s ago
 Invocation: 4d6a13d688aa4bf0a55e5ad3c94ec1f5
TriggeredBy: ● systemd-journald.socket
             ● systemd-journald-dev-log.socket
             ● systemd-journald-audit.socket
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
   Main PID: 928 (systemd-journal)
     Status: "Processing requests..."
      Tasks: 1 (limit: 57332)
   FD Store: 72 (limit: 4224)
     Memory: 74.8M (peak: 75.4M)
        CPU: 9.246s
     CGroup: /system.slice/systemd-journald.service
             └─928 /usr/lib/systemd/systemd-journald

févr. 24 10:31:53 bazzite systemd-journald[928]: Journal started
févr. 24 10:31:53 bazzite systemd-journald[928]: [🡕] Runtime Journal (/run/log/journal/64a59eff00464eff97af35f39a62de88) is 8M, max 961.4M, 953.4M free.
févr. 24 10:31:53 bazzite systemd-journald[928]: Collecting audit messages is enabled.
févr. 24 10:31:53 bazzite systemd[1]: systemd-journald.service: Deactivated successfully.
févr. 24 10:31:54 bazzite systemd-journald[928]: Time spent on flushing to /var/log/journal/64a59eff00464eff97af35f39a62de88 is 69.725ms for 5486 entries.
févr. 24 10:31:54 bazzite systemd-journald[928]: [🡕] System Journal (/var/log/journal/64a59eff00464eff97af35f39a62de88) is 3.9G, max 4G, 23.6M free.
févr. 24 10:31:54 bazzite systemd-journald[928]: Received client request to flush runtime journal.
I'm looking for ideas, I'm not familiar on how to debug OS/boot issues Trying to boot without the quiet parameter to see if I get more infos next time there's an boot error Happens since I installed bazzite for the past 6 months
zolta
zolta•2mo ago
not sure if it is the most helpful, but have I u tried reinstalling fresh?
Atom
AtomOP•2mo ago
It looks like an extreme solution considering that when it boots no issues arise And there’s no guarantee that it will stop happening
DevilFish303
DevilFish303•2mo ago
what kind of hardware is this? i would run diagnostics on the SSD to see if its failing
Atom
AtomOP•2mo ago
It’s an Nvidia powered pc, I9-9900K, rtx 3080, 2to Corsair nvme mp660 pro, 48gb ram
DevilFish303
DevilFish303•2mo ago
yea check the nvme for corruption, things like journal failing to boot is a bit puzzling sudo smartctl -a /dev/nvme0n1 usually
Atom
AtomOP•2mo ago
Can’t process it until next Tuesday, I’ll ping you when I have the report
zolta
zolta•2mo ago
true, an otpion would be to clone the os partition before trying
Atom
AtomOP•2mo ago
this is the output

njEnYsJ.txt

Atom
AtomOP•2mo ago
Apparently nothing looks wrong I'm probably going to open an systemd issue maybe they'll know how to troubleshoot it properly because I have no idea what's going on
ruffedgz
ruffedgz•2mo ago
Just curious about this but can you do more of a journalctl instead of the systemctl status after boot? From this code snipet, it looks like systemd-journald starts up later just has a hard time during boot but would be interested in what it says in something like: 
journalctl -b | grep systemd-journald
journalctl -b | grep systemd-journald
Atom
AtomOP•2mo ago
Sure but I'm unusure if there'sd gonna be usable informations since when it happens journald isn't initialized yet
Atom
AtomOP•2mo ago
Atom
AtomOP•2mo ago
This is on a successful boot since it's too early on unsucessful ones If anyone has any other ideas I'm willing to troubleshoot else I'll try over at the systemd github issues
ruffedgz
ruffedgz•2mo ago
mars 04 16:51:42 bazzite systemd-journald[377]: Journal stopped
mars 04 16:51:43 bazzite systemd-journald[377]: Received SIGTERM from PID 1 (systemd).
mars 04 16:51:42 bazzite systemd-journald[377]: Journal stopped
mars 04 16:51:43 bazzite systemd-journald[377]: Received SIGTERM from PID 1 (systemd).
This is interesting to me as it looks like systemd causes a SIGTERM but then was able to start it up again shortly after... yea hard to say what without more info but I did read something about adding some kernel parameters to help grab more verbose info: systemd.log_level=debug systemd.log_target=kmsg It could help if you go to the systemd peeps as well
Atom
AtomOP•2mo ago
Yea that's def weird, wouldn't systemd.log_level=debug be enough ? damn im dumb pardon me
ruffedgz
ruffedgz•2mo ago
no worries, the kmsg part is for you to see it when it happens since like you said, its not able to collect any logs since it cant start.. I think you know this hence the quote but explaining it for others that are curious 🙂
Atom
AtomOP•2mo ago
Updated the bios and it looks like it’s more reliable, I close this issue and I will update it if it occurs again, hopefully not🤞

Did you find this page helpful?