Simple question involving a CLI tool

Ask Fedora
1

Can journalctl log reboots too?

2

As in journalctl --list-boots ?

3

That is correct. So, journalctl --list-boots also list reboots too?

4

I guess you could parse the output to determine when the “last entry” is within a few seconds of the next “first entry”, but I don’t think it has any way to determine when a shutdown and startup is any different from a reboot.

5

I had a little play around:

└─➜ journalctl -u systemd-reboot.service -u systemd-poweroff.service --since "1 week ago"
6

I think the udev error has to do with the kernel crash and the black screen after the reboot process

Jun 27 09:21:09 fedora44 systemd[1]: systemd-reboot.service: Deactivated successfully.
Jun 27 09:21:09 fedora44 systemd[1]: Finished systemd-reboot.service - System Reboot.
Jun 27 09:21:09 fedora44 systemd[1]: Reached target reboot.target - System Reboot.
Jun 27 09:21:09 fedora44 systemd[1]: Shutting down.
Jun 27 09:21:10 fedora44 audit: BPF prog-id=60 op=UNLOAD
Jun 27 09:21:10 fedora44 audit: BPF prog-id=59 op=UNLOAD
Jun 27 09:21:10 fedora44 audit: BPF prog-id=57 op=UNLOAD
Jun 27 09:21:10 fedora44 audit: BPF prog-id=56 op=UNLOAD
Jun 27 09:21:10 fedora44 audit: BPF prog-id=53 op=UNLOAD
Jun 27 09:21:10 fedora44 audit: BPF prog-id=52 op=UNLOAD
Jun 27 09:21:10 fedora44 audit: BPF prog-id=48 op=UNLOAD
Jun 27 09:21:10 fedora44 audit: BPF prog-id=50 op=UNLOAD
Jun 27 09:21:10 fedora44 audit: BPF prog-id=49 op=UNLOAD
Jun 27 09:21:10 fedora44 audit: BPF prog-id=41 op=UNLOAD
Jun 27 09:21:10 fedora44 systemd[1]: Using hardware watchdog /dev/watchdog0: 'intel_oc_wdt', version 0.
Jun 27 09:21:10 fedora44 systemd[1]: Watchdog running with a hardware timeout of 15s.
Jun 27 09:21:10 fedora44 kernel: watchdog: watchdog0: watchdog did not stop!
Jun 27 09:21:10 fedora44 systemd-shutdown[1]: Using hardware watchdog /dev/watchdog0: 'intel_oc_wdt', version 0.
Jun 27 09:21:10 fedora44 systemd-shutdown[1]: Watchdog running with a hardware timeout of 15s.
Jun 27 09:21:10 fedora44 systemd-shutdown[1]: Syncing filesystems and block devices.
Jun 27 09:21:10 fedora44 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Jun 27 09:21:10 fedora44 systemd-udevd[545]: Failed to remove file descriptor "config-serialization" from the store, ignoring: Connection refused
7

Posted in the wrong topic?

I’ve no idea what udev error you’re referring to nor can I see any udev error in that output.

8

What is going on is a sequence of steps

  1. Power on
  2. UEFI boot linux
  3. linux starts systemd that starts journaling
  4. journal knows that a the system has booted.
  5. Either you choose poweroff or reboot
  6. systemd bring the systems down, umount disk etc
  7. systemd logs that systemd-poweroff.service ot systemd-reboot.service is started
  8. systemd stops journaling
  9. Either the UEFI is told to poweroff or reboot depending on what you choose at (5)

From that information you can figure out if its a reboot, poweroff or forced power off (no journal logs).

The

9

When doing ctrl-alt-del on boot, its force stops the boot sequence resulting in the Caps lock flashing, and the equivalent of ctrl-alt-del occurs after the reboot sequence finishes, but i never touched ctrl-alt-del/

10

Maybe, the UEFI is corrupted causing reboots to fail every time. Is there a way to find out if the UEFI is corrupted or not?

11

Usual it’s a issue of bugs in the vendor firmware.
Look for UEFI BIOS updates for your system.