Fedora had a strange behavior at boot for the first time: booting was very slow, the Plymouth-LUKS screen was not loaded (I inserted the password for the decryption of the disc in a full-text screen), access was approved with extreme slowness and the GDM was loaded; after that the PC was very slow and I thought that the GPU was not working, so I restarted the system and everything was solved.
Now I wonder if I should check something: I looked at GNOME Logs and I found a series of logs regarding security, but there are too many to be able to report them.
Maybe it was only an exception, or maybe not. What do you think? (No update has been installed before that occurs)
Look at systemd-analyze critical-chain and see what was slow on the boot.
Without logs to review we cannot guess what may be the problem.
Maybe give a sample of logs?
Was this first boot after an upgrade or a fresh install? You can check for high priority issues withjournalctl -b -p 3. Did the log entries related to security mention selinux (and maybe relabeling)?
At present there are no critical issues from this point of view (the issue appeared only once):
$ 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 @5.030s
└─multi-user.target @5.029s
└─plymouth-quit-wait.service @2.830s +2.189s
└─systemd-user-sessions.service @2.809s +17ms
└─network.target @2.785s
└─wpa_supplicant.service @3.417s +7ms
└─basic.target @1.935s
└─dbus-broker.service @1.916s +17ms
└─dbus.socket @1.902s
└─sysinit.target @1.899s
└─systemd-resolved.service @1.786s +86ms
└─systemd-tmpfiles-setup.service @1.700s +62ms
└─local-fs.target @1.696s
└─boot-efi.mount @1.685s +10ms
└─boot.mount @1.227s +30ms
└─systemd-fsck@dev-disk-by\ ... .service @1.13>
└─dev-disk-by\ ... .device @584542y 2w 2d 20>
Not exactly. Only these two types of messages appear, repeated dozens of times. It was not a fresh installation or a system upgrade, it is an error that appeared unusually only once.
ACPI BIOS Error (bug): Failure creating named object
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
The output from
$ systemd-analyze critical-chain
is truncated at the > characters, so key information may be missing. You can either increase the width of the terminal or use a pipe as in systemd-analyze critical-chain | cat.
It booted in 5 seconds. I would assume that the first boot was slow becuase of some one-of setup that was being done.
I apologize for the oversight. I add the missing part below:
... .service @1.121s +45ms
... .device @584542y 2w 2d 20h 40.745s +1min 9.911s
I don’t know, it happened only once. Inexplicably and for no apparent reason.
If you want to hunt for the reason you should be able to find what was run on your first boot in the system journal (access with journalctl).
I tried to look for the “wanted” boot by running:
journalctl --lists-boots
Once I found it, I searched for its information by launching:
journalctl -b -*
In any case, I do not think that the information displayed is useful.
journalctl captures a massive amount of detail, so it is sometimes not easy to find filters to select the detail relevant to a particular issue. It is helpful to make a note of the time when an issue occurs so you can match the entry in journalctl --list-boots to the time of the problem. Once you have the -N number, use journalctl -b -N ... where ... is additional filters to help select the relevant lines.
Thank you so much for your help. For now, the issue seems to have disappeared. I’ll update you if necessary.