As this is happening now on two different laptops, I am addressing you guys.
I did regular installation using Fedora-WS-Live-36-1-5 ISO image. Downloaded the ISO image, confirmed the checksum, dd’ed it to USB stick, and booted from it.
After boot from the stick, I also opted for medium check, which resulted in OK.
Installation went smooth and once the installer asked me for rebooting I did so.
The system comes up, but
on one laptop (FUJITSU LIFEBOOK S935, Intel® Core™ i5-5300U × 4, Mesa Intel® HD Graphics 5500 (BDW GT2)) it will stay on a blank screen
whereas on my other laptop (Lenovo ThinkPad X280, Intel® Core™ i5-8350U × 8, Mesa Intel® UHD Graphics 620 (KBL GT2)) the black screen has a small greyish horizontal bar at the bottom of the display.
As I got no reaction from the system (ESC, Control-Meta-F-keys, etc), I pushed the power button and the system shut down. The following boot went smoothly (except that it dropped me into the grub menu, as the previous boot was not marked as successful) and I could login. No (graphical) issues at all.
I checked journal entries and saw that the troublesome boot had a different BOOT_IMAGE parameter (hd1 vs hd0)
Does anyone know what’s going on here?
(I guess that I am the lucky one to have two different systems with similar issues that no one else is having, as I did not find any recent communication for this.)
After the failed boot, then the boot with the grub menu, it appears to have booted normally? Is that correct?
It would seem that possibly some module may not have loaded properly on the failed boot but did so with the completed boot. This seems common on systems that need a driver for graphics to be compiled for the running kernel and GPU which may take some time, and the initial boot may not wait long enough before trying to activate graphics.
Have you been able to do an update since? dnf update on the command line will handle that for you.
Since you have 2 laptops and it is not clear if the problem was resolved for both or for only one please give more detail as to the results.
Also, in the future please consider one thread for one issue on one machine so we can minimize confusion such as this.
Sorry for the confusion, will do as you said next time.
What I did on both laptops once I figured out that the screens will not come up:
try ESC, C-M-F, pressing random keys in slight agony → nothing changed
shortly press the power button → systems reacted by shutting down
another reboot → systems went into the configuration screen as they should have
GNOME software came up after some while to notify me on updates (no dnf necessary)
So, all in all, both systems are running perfectly, except the small hickup.
If you have any ideas on what to look for in the journal (or somewhere else) or what to do if I ran into this same situation again (I don’t mind, starting another install), please let me know.
You may peruse the logs with something like journalctl -b -1 and look for near where it ended to see what caused the hang. Depending on how many times you have booted since the initial that may need to be altered to -b -2, or even further. -0 gets the current boot, -1 is the last boot, -2 would be the one before that, etc.
There may be something there that catches your eye about it. I could not guess what you might see because it may or may not have been logged as an error. A careful read may help. Lots of standard entries and some that may be helpful.
Yeah, I checked the correct trouble kid via journalctl --list-boots and went back as you suggested. Only my ThinkPad still had the related journal still available…
I was suspecting that the issue might be related to how the kernel is started, that’s why I was grepping for “Command line:” and saw that the unsuccessful boot had Command line: BOOT_IMAGE=(hd1,gpt2)/vmlinuz-5.17.5-300.fc36.x86_64
whereas all the next boots had Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.17.5-300.fc36.x86_64
But then I thought that if kernel cannot load the boot image, I would get a real error message from the kernel which I didn’t.
I was checking the journal towards the as you suggested, but it looks like the system booted w/o any major issues (kernel comes up, systemd kicks in). The last entries before the Power Button pressed event was related to NetworkManager (deactivating interfaces about 5 minutes after the preceding entries).
Other things I think that might be of interest (really just samples from the >2k lines, filtered out failures, WARNING, etc:
Jul 11 20:40:47 fedora systemd[1]: systemd-firstboot.service - First Boot Wizard was skipped because of a failed condition check (ConditionFirstBoot=yes).
Jul 11 20:40:47 fedora systemd[1]: first-boot-complete.target - First Boot Complete was skipped because of a failed condition check (ConditionFirstBoot=yes).
Jul 11 20:40:58 fedora systemd[1048]: grub-boot-success.timer - Mark boot as successful after the user session has run 2 minutes was skipped because of a failed condition check (ConditionUser=!@system).
Jul 11 20:40:51 fedora nm-dispatcher[925]: req:1 'hostname': find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied
Jul 11 20:40:52 fedora nm-dispatcher[925]: req:2 'connectivity-change': find-scripts: Failed to open dispatcher directory '/etc/NetworkManager/dispatcher.d': Error opening directory “/etc/NetworkManager/dispatcher.d”: Permission denied
Jul 11 20:40:58 fedora gnome-session[1065]: gnome-session-binary[1065]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' failed
Jul 11 20:40:58 fedora gnome-session[1065]: gnome-session-binary[1065]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' failed
Jul 11 20:40:58 fedora gnome-session-binary[1065]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' failed
Jul 11 20:40:58 fedora gnome-session-binary[1065]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' failed
Jul 11 20:40:59 fedora /usr/libexec/gdm-wayland-session[1099]: fuse: failed to open /dev/fuse: Permission denied
Jul 11 20:41:00 fedora org.gnome.Shell.desktop[1073]: Window manager warning: Failed to parse saved session file: Failed to open file “/run/gnome-initial-setup/.config/mutter/sessions/10356c4a5b85d22537165756485866759400000010650000.ms”: No such file or directory
Jul 11 20:41:00 fedora wireplumber[1126]: Failed to set scheduler settings: Operation not permitted
Jul 11 20:41:01 fedora gnome-session[1065]: gnome-session-binary[1065]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Jul 11 20:41:01 fedora gnome-session-binary[1065]: WARNING: Could not retrieve current screensaver active state: Timeout was reached
Jul 11 20:41:25 fedora gnome-session[1065]: gnome-session-binary[1065]: GnomeDesktop-WARNING: Failed to acquire idle monitor object manager: Timeout was reached
Jul 11 20:41:25 fedora gnome-session-binary[1065]: GnomeDesktop-WARNING: Failed to acquire idle monitor object manager: Timeout was reached
Jul 11 20:41:25 fedora gsd-usb-protect[1204]: Failed to get screen saver status: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code24: Timeout was reached
Jul 11 20:41:25 fedora gsd-usb-protect[1204]: Failed to fetch USBGuard parameters: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
Jul 11 20:42:30 fedora gnome-session[1065]: gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.MediaKeys.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.MediaKeys.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session-binary[1065]: Unrecoverable failure in required component org.gnome.SettingsDaemon.MediaKeys.desktop
Jul 11 20:42:30 fedora gnome-session[1065]: gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.Wacom.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.Wacom.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session-binary[1065]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Wacom.desktop
Jul 11 20:42:30 fedora gnome-session[1065]: gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.Keyboard.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session[1065]: gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.Color.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session[1065]: gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.Power.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session[1065]: gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.XSettings.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.Keyboard.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session-binary[1065]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Keyboard.desktop
Jul 11 20:42:30 fedora gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.Color.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session-binary[1065]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Color.desktop
Jul 11 20:42:30 fedora gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.Power.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session-binary[1065]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Power.desktop
Jul 11 20:42:30 fedora gnome-session-binary[1065]: WARNING: Application 'org.gnome.SettingsDaemon.XSettings.desktop' failed to register before timeout
Jul 11 20:42:30 fedora gnome-session-binary[1065]: Unrecoverable failure in required component org.gnome.SettingsDaemon.XSettings.desktop
I’d say, gnome-session and gnome-session-binary have some bigger issues. But still not sure if that would cause my laptop’s behavior.
Reading that segment, it would appear that for whatever reason gnome was not able to initialize the DE so it was left with the black screen. There are several failures and warnings there to indicate that conclusion. With the initial gnome failure it did not get to the first boot config.
It may be that the bios had something left over from an earlier install (windows maybe) so it was trying to boot from the wrong drive and then figured out the error and corrected it.
I have seen similar issues as well when there are 2 drives or partitions that have the same UUID, so check that as well. That should not be the case when usinng the BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.17.5-300.fc36.x86_64 syntax since it tells grub to use the HD that bios has identified as the first (hd0) and the successful boot has corrected that to (hd1).
I am not familiar enough with bios nor grub to venture an educated guess here, but if both laptops show the same then it is really strange.
I did some search on google for GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' failed and came up with several hits, e.g.
People are describing similar behavior to mine.
Now question is why I am having this on first boot after install.
Regarding hd1 vs hd0: the entry at 20:40:38 is from first boot, the one at 21:06:26 is from the second, successful, boot. I have another theory: since we use UUIDs and the parameter doesn’t matter, couldn’t it be that the first boot will always have the hdN from the installation boot?
Update from my end: I once again decided for an installation, downloaded the ISO image again, and this time it went smooth w/o any issues.
I compared the first boots’ journal entries:
on smooth startup, I had the correct hd0 entry in Command line (Jul 14 14:10:04 fedora kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.17.5-300.fc36.x86_64 root=UUID=2f4f4a91....
again, I had the same GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' failed message; so this should not be an issue, then
in the “good” log I can see that gnome-session is coming up effortlessly and I see gnome-initial-session kicking in (which I did not see in the trouble journal)
All in all, I cannot find any indicator on what went wrong, but magically, it works again.