Slow boot times on Pop OS, that used to be fine before

Operating Systems & Open Source Linux
1

[SOLVED] here

I was dual booting Bazzite (Fedora Atomic) and PopOS on my laptop and would always get to each of the login screens in seconds. Never actually checked it, but I’m sure it was like 5-10s. Around 7 months back, after deleting the Bazzite partitions (as the one game I play started crashing there for some reason), the time to login screen was very slow (approx 1m50s to get to login screen).

I have tried asking this in Stack Exchange, but no joy. Gave up on it cuz IRL but after watching Wendell talk about the forum for the 100th time, decided to ask it here. I am pretty sure that a reinstall would fix it (maybe I’d go Fedora Cosmic next), but I just dont have the time to re configure everything right now. Following are some details I’ve seen people on siilar situations post. Any help is appreciated.

das@pop-os:~$ systemd-analyze
Startup finished in 7.572s (firmware) + 3.126s (loader) + 10.234s (kernel) + 2min 6.536s (userspace) = 2min 27.469s 
graphical.target reached after 1min 40.436s in userspace

das@pop-os:~$ 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 @1min 40.436s
└─multi-user.target @1min 40.435s
  └─plymouth-quit-wait.service @1min 34.539s +5.895s
    └─systemd-user-sessions.service @1min 34.519s +13ms
      └─network.target @1min 34.482s
        └─wpa_supplicant.service @1min 34.351s +130ms
          └─basic.target @1min 34.280s
            └─dbus-broker.service @1min 34.230s +47ms
              └─dbus.socket @1min 34.218s
                └─sysinit.target @1min 34.214s
                  └─snapd.apparmor.service @1min 33.906s +308ms
                    └─apparmor.service @1min 33.800s +93ms
                      └─local-fs.target @1min 33.798s
                        └─run-user-1000-doc.mount @1min 47.336s
                          └─run-user-1000.mount @1min 44.395s
                            └─local-fs-pre.target @4.063s
                              └─systemd-tmpfiles-setup-dev.service @3.820s +242ms
                                └─systemd-sysusers.service @3.734s +72ms
                                  └─systemd-remount-fs.service @3.682s +40ms
                                    └─systemd-journald.socket @3.640s
                                      └─-.mount @3.607s
                                        └─-.slice @3.607s

das@pop-os:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0     4K  1 loop /snap/bare/5
loop1         7:1    0  73,9M  1 loop /snap/core22/1908
loop2         7:2    0  73,9M  1 loop /snap/core22/1963
loop3         7:3    0  68,4M  1 loop /snap/cups/1085
loop4         7:4    0  67,2M  1 loop /snap/cups/1100
loop5         7:5    0 505,1M  1 loop /snap/gnome-42-2204/176
loop6         7:6    0   516M  1 loop /snap/gnome-42-2204/202
loop7         7:7    0  91,7M  1 loop /snap/gtk-common-themes/1535
loop8         7:8    0  44,4M  1 loop /snap/snapd/23771
loop9         7:9    0  50,9M  1 loop /snap/snapd/24505
zram0       251:0    0   7,6G  0 disk [SWAP]
nvme0n1     259:0    0 465,8G  0 disk 
├─nvme0n1p1 259:1    0  1022M  0 part /boot/efi
├─nvme0n1p2 259:2    0     4G  0 part /recovery
└─nvme0n1p3 259:3    0 460,8G  0 part /
2

Welcome!

What does “alarmingly slow” mean (approximately)? Is it 15 seconds, 1 min 40 s, 2 min 30 s, or something else?

How did you delete the Bazzite partitions?

If I’m reading the systemd-analyze output correctly, local-fs-pre.target starts at 4.063 s, but then run-user-1000.mount doesn’t start until 1 min 44 s? Perhaps it’s trying to mount (or does some kind of scanning of) the no-longer-existing Bazzite partitions there and waits until it times out and fails? I have no idea about Pop OS’s boot process so I can’t give more precise help.

3

Thank you for your reply.

sorry for the exclusion. i was thinking that the systemd-analyse output gave the time. anyway, i timed it manually and from pressing the power button to my password entry prompt, it takes approx. 1m50s.

To be honest, it was over 7 months ago at this point so i do not remember accurately. I recall deleting the partitions and editing some configs, grub maybe? I’m sorry, that’s all I can remember at the moment.

One observation I have regarding this is that it seems to go into PopOS and then the waiting still copntinues for a minute or so. I say this due to the fact that my lock screen background (of PopOS) loads up for the majority of the wait (although without any other icons or text).

4

I realise this may be totally unrelated, because of the timing of you deleting the Bazzite partition, but I was having a similar issue with long boot times, it was across all my OS’s so I thought there was a hardware issue with the motherboard or something failing.

Turned out it was a Microsoft Xbox controller dongle that was failing. I removed it and I was back to normal boot up.

You might not have one of these, but have you tried removing all USB devices and having only your keyboard and mouse and monitor plugged in? In case it’s something else causing it?

5

Thanks for chiming in. Tried it now, doesnt help.

Thing is since I dont usually turn off my system daily, I only noticed the issue more than a month after the Bazzite removal. I’m pretty sure I followed a tutorial somewhere that seemed legit so didnt think to check this stuff at the time.

Well, thanks anyway. I’ll just redo the OS install at some point if this starts to bother me.

6

PopOS uses kernelstub instead of GRUB to configure boot options.

You could try following these instructions to disable the boot splash screen and enable boot messages. That way you can see the boot operation output and it may help you figure out what the system is hanging on during boot. You can always reverse the instructions to undo enable the splash screen again.

1 Like
7

Great suggestion! I dont know why I didn’t think to do this before.

Any how, I think this confirms what @homeserver78 suggested, as I can see most of the waiting is done to try to mount two devices /dev/disk/by-uuid/cd781c08-b1c2-4dac-9273-41f7bd3739cf and /dev/mapper/cryptswap, neither of which is in my lsblk or fstab.

I now have to figure out who is asking them to be mounted and how to stop it from happening.

8

[SOLVED]

After identifyling the problem devices by looking at verbose boot messages, used grep -r UUID /etc to find the corresponding entries and commented them out (in files /etc/crypttab and /etc/fstab in my case).

Boot time is now approx 10s. Thank you all for the help.

3 Likes