I have just bought a Lenovo IdeaPad 3 and installed Fedora 37 on it.
When I boot into Fedora, it sits on the Lenovo Splash screen for what seems like a very long time, then puts up a message that I am now in emergency mode. I can continue using Ctl-D, and log on normally.
If Gnome Software has downloaded updates, they do not get applied.
Once logged on, I can use sudo normally, including sudo dnf upgrade to apply updates.
If I recall correctly, the issue started after I applied the first lot of updates following the initial install.
An Internet search came up with some Suggestions:
Set a password for root - no effect
Unlock root using passwd - no effect
Unlock root using usermod - no effect.
As above, the system is usable at present, but it is an issue.
Thanks. The only things I can see in that that look like errors are this Block:
^[M^M^[[K[^[[0;1;31m TIME ^[[0m] Timed out waiting for device ^[[0;1;…1c793-1edc-4611-b298-3476372e7cd0.^M
^[[K[^[[0;1;38;5;185mDEPEND^[[0m] Dependency failed for ^[[0;1;39mhome.mount^[[0m - /home.^M
[^[[0;1;38;5;185mDEPEND^[[0m] Dependency failed for ^[[0;1;39mloca…s.target^[[0m - Local File Systems.^M
[^[[0;1;38;5;185mDEPEND^[[0m] Dependency failed for ^[[0;1;39mseli… the need to relabel after reboot.^M
[^[[0;1;31m TIME ^[[0m] Timed out waiting for device ^[[0;1;…dev-zram0.device^[[0m - /dev/zram0.^M
[^[[0;1;38;5;185mDEPEND^[[0m] Dependency failed for ^[[0;1;39mdev-…m - Compressed Swap on /dev/zram0.^M
[^[[0;1;38;5;185mDEPEND^[[0m] Dependency failed for ^[[0;1;39msyst…e^[[0m - Create swap on /dev/zram0.^M
[^[[0;1;31m TIME ^[[0m] Timed out waiting for device ^[[0;1;…[0m - /dev/disk/by-uuid/68A1-9C4C.^M
[^[[0;1;38;5;185mDEPEND^[[0m] Dependency failed for ^[[0;1;39mboot-efi.mount^[[0m - /boot/efi.^M
[^[[0;1;38;5;185mDEPEND^[[0m] Dependency failed for ^[[0;1;39msyst…ck on /dev/disk/by-uuid/68A1-9C4C.^M
[^[[0;1;31m TIME ^[[0m] Timed out waiting for device ^[[0;1;…a1d5c-1240-484a-b3d8-4f23ed381b7f.^M
[^[[0;1;38;5;185mDEPEND^[[0m] Dependency failed for ^[[0;1;39mboot.mount^[[0m - /boot.^M
[^[[0;1;38;5;185mDEPEND^[[0m] Dependency failed for ^[[0;1;39msyst…a1d5c-1240-484a-b3d8-4f23ed381b7f.^M
These are a consecutive block, about two thirds of the way through.
I’ve got it saved as a text file if there is more that you want to see.
I guess you have not a graphical interface now and can’t copy/past the command right?
If you can pass me as a personal message the file /var/log/boot.log
I will transform it that it looks like:
[ OK ] Mounted sys-fs-fuse-connec…nt - FUSE Control File System.
[ OK ] Mounted sys-kernel-config.… Kernel Configuration File System.
[ OK ] Finished systemd-sysctl.service - Apply Kernel Variables.
[ OK ] Finished systemd-random-se…rvice - Load/Save Random Seed.
[ OK ] Finished systemd-tmpfiles-…reate Static Device Nodes in /dev.
Thanks. I’m new here and not sure how to send a personal message, but
Trying cut and paste from direct terminal output rather than the saved text, and also I have just spotted a couple more messages, included.
[ TIME ] Timed out waiting for device 793-1edc-4611-b298-3476372e7cd0.
[DEPEND] Dependency failed for home.mount - /home.
[DEPEND] Dependency failed for loca…s.target - Local File Systems.
[DEPEND] Dependency failed for seli… the need to relabel after reboot.
[ TIME ] Timed out waiting for device ev-zram0.device - /dev/zram0.
[DEPEND] Dependency failed for dev-…m - Compressed Swap on /dev/zram0.
[DEPEND] Dependency failed for syst…e - Create swap on /dev/zram0.
[ TIME ] Timed out waiting for device 0m - /dev/disk/by-uuid/68A1-9C4C.
[DEPEND] Dependency failed for boot-efi.mount - /boot/efi.
[DEPEND] Dependency failed for syst…ck on /dev/disk/by-uuid/68A1-9C4C.
[ TIME ] Timed out waiting for device 1d5c-1240-484a-b3d8-4f23ed381b7f.
[DEPEND] Dependency failed for boot.mount - /boot.
[DEPEND] Dependency failed for syst…a1d5c-1240-484a-b3d8-4f23ed381b7f.
[ OK ] Stopped systemd-ask-passwo… Requests to Wall Directory Watch.
[ OK ] Reached target timers.target - Timer Units.
[ OK ] Reached target network-pre…get - Preparation for Network.
[ OK ] Reached target nss-user-lo…[0m - User and Group Name Lookups.
[ OK ] Reached target paths.target - Path Units.
[ OK ] Reached target sockets.target - Socket Units.
[ OK ] Reached target swap.target - Swaps.
Mounting tmp.mount - Temporary Directory /tmp...
Starting import-state.serv…rk configuration from initramfs...
Starting plymouth-read-wri…mouth To Write Out Runtime Data...
Starting systemd-binfmt.se…et Up Additional Binary Formats...
Starting systemd-boot-upda… - Automatic Boot Loader Update...
[FAILED] Failed to start systemd-jo…ush Journal to Persistent Storage.
See 'systemctl status systemd-journal-flush.service' for details.
[ OK ] Finished systemd-random-se…rvice - Load/Save Random Seed.
[FAILED] Failed to start systemd-sy…vice - Apply Kernel Variables.
See 'systemctl status systemd-sysctl.service' for details.
Giving the systemctl commands results in
john@fedora ~]$ systemctl status systemd-journal-flush.service
â—Ź systemd-journal-flush.service - Flush Journal to Persistent Storage
Loaded: loaded (/usr/lib/systemd/system/systemd-journal-flush.service; static)
Active: active (exited) since Sun 2023-01-29 16:03:30 NZDT; 3 days ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Process: 858 ExecStart=journalctl --flush (code=exited, status=0/SUCCESS)
Main PID: 858 (code=exited, status=0/SUCCESS)
CPU: 3ms
Jan 29 16:03:30 fedora systemd[1]: Starting systemd-journal-flush.service - Flush Journal to Persistent Storage...
Jan 29 16:03:30 fedora systemd[1]: Finished systemd-journal-flush.service - Flush Journal to Persistent Storage.
[john@fedora ~]$ systemctl status systemd-sysctl.service
â—Ź systemd-sysctl.service - Apply Kernel Variables
Loaded: loaded (/usr/lib/systemd/system/systemd-sysctl.service; static)
Active: active (exited) since Sun 2023-01-29 16:03:30 NZDT; 3 days ago
Docs: man:systemd-sysctl.service(8)
man:sysctl.d(5)
Process: 859 ExecStart=/usr/lib/systemd/systemd-sysctl (code=exited, status=0/SUCCESS)
Main PID: 859 (code=exited, status=0/SUCCESS)
CPU: 3ms
Jan 29 16:03:30 fedora systemd[1]: Starting systemd-sysctl.service - Apply Kernel Variables...
Jan 29 16:03:30 fedora systemd[1]: Finished systemd-sysctl.service - Apply Kernel Variables.
[john@fedora ~]$ cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Thu Jan 12 14:47:06 2023
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=1071c793-1edc-4611-b298-3476372e7cd0 / btrfs subvol=root,compress=zstd:1 0 0
UUID=28ba1d5c-1240-484a-b3d8-4f23ed381b7f /boot ext4 defaults 1 2
UUID=68A1-9C4C /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=1071c793-1edc-4611-b298-3476372e7cd0 /home btrfs subvol=home,compress=zstd:1 0 0
[john@fedora ~]$
Those outputs all look very normal.
The only thing I see that I wonder about is the fact that you have bitlocker active on the windows partition (nvme0n1p3). It is possible that fedora is trying to open that partition but cannot read it so could be cycling around that and delaying the actual boot of fedora. I don’t know that is the case but it does seem possible.
Otherwise, the log snippets seem to show timeouts in mounting all the fedora partitions. /boot, /boot/efi, /home, and in configuring zram. Whatever may be causing those timeouts seems the culprit.
After a new boot, please post the output of systemd-analyze blame | head 50 and systemd-analyze critical-chain | head 50.
This may allow us to see at least the items that are taking an excessive time to complete during the boot.
You also can easily see the kernel messages during boot by pressing and holding the shift key when powering on to get the grub menu, then press the e key when the menu is displayed. move to the kernel command line (begins with linux) and remove the rhgb quiet from that line then press ctrl + X to continue booting. The kernel messages should then scroll on the screen and you may be able to tell what is causing the delays.
I rebooted, and edited the parameters per Jeff V’s suggestion.
This time, it happily applied outstanding updates, which as above it has not been doing, and rebooted. I was caught by surprise, and neither selected the new kernel (Grub had defaulted to the previous one) or edited the parameters. Same problem again.
I rebooted again, selected the new kernel, and edited the parameters. Problem gone.
I think no point in running systemd-analyze on this latest boot. I could reboot without the edit if you think that would be useful.
So it seems it has something to do with “rhgb quiet”.
From that latest info I would guess that this may be affected by trying to do offline updates which is the default on newer fedora systems. They do the updates during the power down and back up sequence. Doing so has the potential to impact other things that might not be accounted for in the logic controlling that process.
When shutting down or rebooting the final displayed popup before completing the action may have a checkbox (checked by default) requesting permission to do the updates. If you do not uncheck that box the system will download and install any pending updates as part of the shutdown&restart process.
Doing that may or may not be problematic and may or may not be what the user desires. I personally dislike it and disable this feature with sudo systemctl mask packagekit-offline-update.service.
As far as the rhgb quiet portion of the kernel command line is concerned, that mainly is a feature that hides the text messages from the boot sequence behind a graphical screen. It normally has no impact on the actual boot process.
At this point I would suggest that you open a terminal and run sudo dnf distro-sync --refresh to see if the system is fully up to date. Let us know the results.
However, the fact that the offline update completed and the latest boot succeeded using the newest kernel with the edit would indicate that your problem may have been resolved. A simple reboot without that edit may confirm this supposition.
[john@fedora ~]$ systemd-analyze critical-chain | head -n50
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 @2min 19.134s
[john@fedora ~]$
I would have expected the critical-chain to look something like this.
# systemd-analyze critical-chain | head -n50
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 46.573s
└─multi-user.target @1min 46.573s
└─plymouth-quit-wait.service @1min 40.622s +5.939s
└─systemd-user-sessions.service @1min 40.565s +34ms
└─remote-fs.target @1min 40.550s
└─remote-fs-pre.target @1min 40.550s
└─nfs-client.target @1min 34.285s
└─gssproxy.service @1min 34.183s +100ms
└─network.target @1min 34.161s
└─wpa_supplicant.service @1min 34.573s +23ms
└─dbus-broker.service @1min 31.660s +421ms
└─dbus.socket @1min 31.501s
└─sysinit.target @1min 31.488s
└─systemd-resolved.service @3.547s +114ms
└─systemd-tmpfiles-setup.service @3.378s +152ms
└─import-state.service @3.317s +40ms
└─local-fs.target @3.304s
└─home.mount @3.214s +89ms
└─systemd-fsck@dev-mapper-fedora_raid1\x2dhome.service @2.905s +294ms
└─dev-mapper-fedora_raid1\x2dhome.device @2.878s
The blame part shows that something took more than 2 minutes earlier in the startup, and you may need to run it as systemd-analyze blame | less then page through the output until you see what is causing the large delay. That whole segment posted only encompasses 23 milliseconds time (2 min 6.532s to 2 min 6.555s)