Slow Boot and Crashing After Upgrade

Issues & Assistance
1

Hello, cachyos was working perfectly 1 week ago, after i did some updates it is taking such a long time to boot, before it was 4-5 seconds, now it is taking 1-3 minutes.

And i just had an instance of after 10 minutes booted the GPU/System i dunno just crashed and i got a black screen and could not do anything.

I tried to read the

sudo dmesg

Here is the output for my

sudo cachyos-bugreport.sh

❯ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1min 13.529s
└─multi-user.target @1min 13.529s
  └─docker.service @1min 12.367s +1.162s
    └─network-online.target @1min 12.366s
      └─NetworkManager-wait-online.service @1min 6.366s +5.999s
        └─NetworkManager.service @1min 6.041s +323ms
          └─basic.target @1min 6.040s
            └─dbus-broker.service @1min 6.021s +17ms
              └─dbus.socket @1min 6.007s
                └─sysinit.target @1min 6.006s
                  └─systemd-resolved.service @1min 5.954s +51ms
                    └─run-credentials-systemd\x2dresolved.service.mount @1min 5.969s

Please lat me know if there is missing info or if i need to provide more details or logs.

Thanks.

2

Some ideas:

  1. The BIOS has an update available (F40d)

  2. It looks like something with USB is going on?

    [   10.707541] usb 1-1.1.3: device descriptor read/64, error -110

    That gets repeated further on with seconds in between them.
    Is there something plugged in that’s not working correctly or maybe a cable issue?

  3. This looks weird:

    [   21.941494] systemd[1]: systemd-journald.service: start operation timed out. Terminating.

    and

    [   32.191849] systemd[1]: systemd-journald.service: Killing process 448 (systemd-journal) with signal SIGKILL.

    Is that the systemd journal service getting killed? :face_with_raised_eyebrow:

  4. Both can also be seen in the journal:

    nov 18 17:12:53 MarioDesktop kernel: usb 1-1.1.3: device descriptor read/64, error -110
nov 18 17:12:53 MarioDesktop systemd[1]: systemd-journald.service: start operation timed out. Terminating.
nov 18 17:12:53 MarioDesktop kernel: usb 1-1.1.3: device descriptor read/64, error -110
nov 18 17:12:53 MarioDesktop systemd[1]: systemd-journald.service: State 'stop-sigterm' timed out. Killing.
nov 18 17:12:53 MarioDesktop kernel: usb 1-1.1.3: device descriptor read/64, error -110
nov 18 17:12:53 MarioDesktop systemd[1]: systemd-journald.service: Processes still around after SIGKILL. Ignoring.
nov 18 17:12:53 MarioDesktop kernel: usb 1-1.1.3: device descriptor read/64, error -110
nov 18 17:12:53 MarioDesktop systemd[1]: systemd-journald.service: State 'final-sigterm' timed out. Killing.

  5. Maybe this still works to get the log of the failing service:

    $ journalctl --unit systemd-journald.service

  6. Does

    $ systemd-analyze blame

    show a stalling unit? Times should be below 1 second, usually.

1 Like
3

Thanks @deex

I will download and update the BIOS.

Regarding the USB i will remove some and try to boot with only the monitor and add ony by one to see which one is giving this error.

Output of journalctl --unit systemd-journald.service

Output of systemd-analyze blame

9.561s systemd-journald.service
5.999s NetworkManager-wait-online.service
1.162s docker.service

Seems like the issue are with systemd journal and the network manager

4

Seems like every boot journald tries to move the log file out of the way:

File /run/log/journal/781556cc27f54311af2f9671f579c7bd/system.journal corrupted or uncleanly shut down, renaming and replacing.

Here it’s freshly created:

Runtime Journal (/run/log/journal/781556cc27f54311af2f9671f579c7bd) is 16M, max 1.5G, 1.5G free.

And here it corrupts again, in the same boot:

Received client request to flush runtime journal.
File /var/log/journal/781556cc27f54311af2f9671f579c7bd/system.journal corrupted or uncleanly shut down, renaming and replacing.

So I wonder what’s going on there.

Could you check the filesystem?

You could also try to remove all logs - make sure you do not need those

But now I’m starting to guess.

9.561s systemd-journald.service
5.999s NetworkManager-wait-online.service
1.162s docker.service

Shows journald taking its good time trying to sight the killing.
Network has strange durations sometimes.
Docker also is pretty heavy, so it’s okay.