Lenovo Ideapad 3 boot issue | boot up very slow

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.


Welcome to the Fedoraproject @jhaotearoa

Please execute the command below and check if you see wich errors you get:

sudo sed $'s/\^\[/\E/g' /var/log/boot.log

You can observe tis messages live while booting if you press ESC after the boot is initialized.

Please do not for get to post the errors here as (see icon in menu above </>) pre formatted text.

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.

So we can read it.

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)
    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)
    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.

Thanks for your assistance.

It wants to mount your file system, there seams to be a wrong entry in your fstab
Please execute cat /etc/fstab
and paste it here

There were at least 3 file systems that did not mount plus the creation of zram failed.

If you can please also post the output of lsblk -f (run either with the system booted or from a live USB. )

1 Like


[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 ~]$ 


[john@fedora ~]$ lsblk -f
NAME        FSTYPE    FSVER LABEL                 UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zram0                                                                                                 [SWAP]
├─nvme0n1p1 vfat      FAT32 SYSTEM_DRV            68A1-9C4C                             206.2M    19% /boot/efi
├─nvme0n1p3 BitLocker 2                                                                               
├─nvme0n1p4 ntfs            WINRE_DRV             580EA8120EA7E76A                                    
├─nvme0n1p5 ext4      1.0                         28ba1d5c-1240-484a-b3d8-4f23ed381b7f  633.4M    28% /boot
└─nvme0n1p6 btrfs           fedora_localhost-live 1071c793-1edc-4611-b298-3476372e7cd0  122.1G    10% /home
[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.

Now, that was unexpected.

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”.

Thanks for your time and patience.

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.

Rebooted without editing the parameters. Problem is back.

I don’t know if it is relevant, but Grub is defaulting to the last but one kernel (easily corrected).

Running systemd-analyize blame:

john@fedora ~]$ systemd-analyze blame | head -n50
2min 6.555s sys-module-fuse.device
2min 6.541s dev-ttyS1.device
2min 6.541s sys-devices-platform-serial8250-tty-ttyS1.device
2min 6.541s dev-ttyS0.device
2min 6.541s sys-devices-platform-serial8250-tty-ttyS0.device
2min 6.540s dev-ttyS12.device
2min 6.540s sys-devices-platform-serial8250-tty-ttyS12.device
2min 6.540s dev-ttyS10.device
2min 6.540s sys-devices-platform-serial8250-tty-ttyS10.device
2min 6.539s dev-ttyS15.device
2min 6.539s sys-devices-platform-serial8250-tty-ttyS15.device
2min 6.539s sys-devices-platform-serial8250-tty-ttyS13.device
2min 6.539s dev-ttyS13.device
2min 6.539s dev-ttyS11.device
2min 6.539s sys-devices-platform-serial8250-tty-ttyS11.device
2min 6.539s dev-ttyS16.device
2min 6.539s sys-devices-platform-serial8250-tty-ttyS16.device
2min 6.538s sys-devices-platform-serial8250-tty-ttyS19.device
2min 6.538s dev-ttyS19.device
2min 6.538s sys-devices-platform-serial8250-tty-ttyS2.device
2min 6.538s dev-ttyS2.device
2min 6.537s dev-ttyS17.device
2min 6.537s sys-devices-platform-serial8250-tty-ttyS17.device
2min 6.536s dev-ttyS4.device
2min 6.536s sys-devices-pci0000:00-0000:00:1e.0-dw\x2dapb\x2duart.2-tty-ttyS4.device
2min 6.536s dev-ttyS18.device
2min 6.536s sys-devices-platform-serial8250-tty-ttyS18.device
2min 6.536s sys-devices-platform-serial8250-tty-ttyS20.device
2min 6.536s dev-ttyS20.device
2min 6.535s sys-devices-platform-serial8250-tty-ttyS14.device
2min 6.535s dev-ttyS14.device
2min 6.535s sys-devices-platform-serial8250-tty-ttyS23.device
2min 6.535s dev-ttyS23.device
2min 6.535s sys-devices-platform-serial8250-tty-ttyS22.device
2min 6.535s dev-ttyS22.device
2min 6.535s dev-ttyS25.device
2min 6.535s sys-devices-platform-serial8250-tty-ttyS25.device
2min 6.534s dev-ttyS26.device
2min 6.534s sys-devices-platform-serial8250-tty-ttyS26.device
2min 6.534s dev-ttyS24.device
2min 6.534s sys-devices-platform-serial8250-tty-ttyS24.device
2min 6.533s dev-ttyS28.device
2min 6.533s sys-devices-platform-serial8250-tty-ttyS28.device
2min 6.533s sys-devices-platform-serial8250-tty-ttyS27.device
2min 6.533s dev-ttyS27.device
2min 6.533s dev-ttyS3.device
2min 6.533s sys-devices-platform-serial8250-tty-ttyS3.device
2min 6.532s dev-ttyS21.device
2min 6.532s sys-devices-platform-serial8250-tty-ttyS21.device
2min 6.532s dev-ttyS29.device
[john@fedora ~]$ 

And then critical-chain

[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)

This should cover all the significant delays:

2min 5.365s dev-nvme0n1.device
2min 5.365s dev-disk-by\x2dpath-pci\x2d0000:00:0e.0\x2dpci\x2d10000:e1:00.0\x2dnvme\x2d1.device
2min 5.365s sys-devices-pci0000:00-0000:00:0e.0-pci10000:e0-10000:e0:1c.4-10000:e1:00.0-nvme-nvme0-nvme0n1.device
2min 5.104s sys-devices-pci0000:00-0000:00:02.0-drm-card1-card1\x2deDP\x2d1-intel_backlight.device
2min 3.189s systemd-tmpfiles-setup-dev.service
2min 3.175s systemd-sysctl.service
2min 3.167s systemd-random-seed.service
 1min 334ms lvm2-monitor.service
    33.316s plymouth-read-write.service
    33.308s import-state.service
    33.303s tmp.mount
     4.315s NetworkManager-wait-online.service
     1.937s plocate-updatedb.service
     1.545s dracut-initqueue.service
      913ms initrd-switch-root.service
      753ms fwupd.service
      558ms packagekit.service

There are 220 lines total if you want to see any more.

To update after a long hiatus, for reasons about to be explained.

Shortly after my last post, the system refused completely to boot, citing checksum errors in the filesystem. Several subsequent attempts to to reinstall appeared to work, but each time the resulting system would not boot, usually failing with a timeout.

I had the supplier check out the SSD, but they said it was fine.

With a lot of other things happening, I have only recently got back to this.

I have now got Fedora 39 installed on an external hard drive (which is a nuisance but I can live with it), and so far working.

I have some speculations about what might have happened, but they are only speculations.

Thanks to everyone who tried to help.