I accepted the new Software upgrades today, which consisted of OS updates. On first reboot, after the second prompt for the disk encryption password, the OS slowed to a crawl. The progress bar took a long time to switch to the “PureOS” logo, then just “hung” there (or at least was very slow).
Fortunately, Ctrl-Alt-Del rebooted, which got things going again and continued the install.
LMK if anyone else had this issue today or soon after.
I noticed a double reboot (had to enter LUKS decryption password twice) after today’s upgrade. I did not enter the password quickly on the second prompt and it went to a black screen for me.
Ctrl-Alt-Del has never worked for me in the past although I didn’t try it this time. Anyway, I manually rebooted with the power switch and it seems ok
One thing that one can do after a slow boot is to issue this command at the command line;
systemd-analyze blame
That should tell you what was taking a long time during boot.
Good evening,
I have a Librem 15 v4 and was thinking the same as you on the boot up. It definitely hangs during the LUKs decryption sequence. I do not have retype my password, but it almost feels like it will crash at some point.
Has anyone found a remedy to this issue?
Thanks.
Can you describe the issue a bit more? How long does it hang for example? And if you have any corresponding data that might help, like the systemd-analyze blame output or log output that will help in diagnosing issues.
You can always file bugs here: https://tracker.pureos.net/
I didn’t see this delay during this weekend’s OS release.
I reached out to the Support Team. I did indeed run the systemd-analyze blame as well as systemd-analyze.
Here are my results.
systemd-analyze
Startup finished in 51.658s (kernel) + 8.999s (userspace) = 1min 657ms
graphical.target reached after 8.984s in userspace
systemd-analyze-blame
7.593s plymouth-quit-wait.service
853ms tor@default.service
652ms systemd-udev-settle.service
647ms user@1000.service
535ms dev-mapper-luks\x2dcc460a17\x2d8f94\x2d4460\x2d8dca\x2dd4595d63
507ms fwupd.service
434ms systemd-logind.service
413ms dev-loop0.device
408ms dev-loop1.device
382ms snapd.service
330ms ModemManager.service
317ms udisks2.service
274ms acpi-support.service
267ms grub-common.service
249ms accounts-daemon.service
236ms upower.service
213ms bluetooth.service
194ms NetworkManager.service
190ms wpa_supplicant.service
185ms avahi-daemon.service
169ms rsyslog.service
159ms purism-power-optimisations.service
156ms switcheroo-control.service
147ms bolt.service
127ms systemd-timesyncd.service
118ms geoclue.service
116ms keyboard-setup.service
114ms snapd.seeded.service
103ms systemd-cryptsetup@luks\x2d37966be0\x2d757e\x2d4c3a\x2dada3\x2d
95ms systemd-journald.service
81ms apparmor.service
81ms systemd-udev-trigger.service
78ms systemd-fsck@dev-disk-by\x2duuid-dfaf5771\x2d1b67\x2d47ad\x2db4
74ms lvm2-monitor.service
64ms systemd-udevd.service
59ms snap-spotify-34.mount
59ms systemd-backlight@backlight:intel_backlight.service
57ms snap-core-6673.mount
54ms plymouth-start.service
50ms ntp.service
50ms gdm.service
47ms polkit.service
47ms tor.service
46ms pppd-dns.service
43ms systemd-cryptsetup@luks\x2dcc460a17\x2d8f94\x2d4460\x2d8dca\x2d
39ms brltty.service
35ms systemd-rfkill.service
33ms systemd-tmpfiles-clean.service
33ms networking.service
31ms sys-fs-fuse-connections.mount
31ms systemd-modules-load.service
30ms systemd-journal-flush.service
28ms dev-mqueue.mount
28ms ufw.service
26ms systemd-tmpfiles-setup-dev.service
22ms systemd-remount-fs.service
21ms systemd-sysusers.service
19ms systemd-random-seed.service
18ms colord.service
16ms systemd-tmpfiles-setup.service
14ms blk-availability.service
13ms systemd-update-utmp.service
13ms sys-kernel-debug.mount
13ms systemd-update-utmp-runlevel.service
13ms dev-hugepages.mount
12ms plymouth-read-write.service
12ms boot.mount
11ms user-runtime-dir@1000.service
11ms openvpn.service
11ms kmod-static-nodes.service
10ms dev-mapper-luks\x2d37966be0\x2d757e\x2d4c3a\x2dada3\x2da350d627
8ms systemd-user-sessions.service
7ms systemd-sysctl.service
4ms console-setup.service
3ms rtkit-daemon.service
3ms ifupdown-pre.service
2ms tmp.mount
2ms snapd.socket
One thing I have failed to mention in my post is the Support Team has prescribed some remedies that improved my boot up times by approximately 6 seconds.
They were:
sudo apt update
sudo apt install haveged
Restart once or twice to see if the situation improved. If not, then install the other package:
sudo apt install rng-tools
and again install.
The support team was ultra-helpful.
Thanks.
My boot time is similar;
8.464s plymouth-quit-wait.service
1.346s apt-daily-upgrade.service
1.011s user@1000.service
908ms tor@default.service
698ms upower.service
631ms dev-mapper-luks\x2df77bd093\x2d9df3\x2d409e\x2dae24\x2da3ffdf434a8c.device
579ms apt-daily.service
454ms logrotate.service
405ms man-db.service
358ms systemd-cryptsetup@luks\x2d1d87c323\x2d8d00\x2d44c0\x2d9afa\x2d7b76f0651d4b.service
I’ve filed a bug (and assigned it to myself) to try and understand how we can optimize boot a bit better. I think we can get faster start times and I’m hopeful we can avoid hanging on boot.
This happened again with the recent OS upgrade. I let the machine sit, thinking that it would eventually finish, but it sat overnight and never completed the reboot. Sat there with “PureOS” on the screen and the cryptsetup line in the corner. Ctrl-Alt-Del worked, but the systemd-analyze output is that of the later boot.
Not sure if I should open a new topic, but my Librem 15v3 takes quite a lot time to boot, so I looked up how to analyze and after some research I ended up here:
My top services during boot are
systemd-analyze blame
2min 56ms systemd-udev-settle.service
11.415s NetworkManager-wait-online.service
3.973s plymouth-quit-wait.service
...
Idk why systemd-udev-settle.service takes so much time. Any hints how to analyze further.
People also masked services and so on, but I’m a bit afraid that this may break something.
Thanks in advanced for some help. Up to now I just sit and wait but 3 min is quite a long time for a system with an NVMe SSD isn’t it?
Yes, I would just reinstall a new PureOS image at this point; your boot up time should be within single digit seconds.
Thanks for the quick reply, but can you elaborate a it more what is the root cause and why a re-install should solve it?
Actually I “just” reinstalled my system end of 2021. So 2 years later I should do it another time ^^.
I thought this is a Windows thing. 
I chose PureOS because I thought I would have a reasonably relaxed life with it, because of its rolling release characters.
I would not know. My approach to dealing with issues I do not have the time nor interest to understand is to bring the system back to a known good state. It simplifies my situation to binary:
Btw. I didn’t reinstall, in my case it was related to the USB (USB-C) docking stating or a device which is attached to it.
Without having it plugged in the system starts very quickly. So I skipped the re-install.
Okay, mark your post as a solution.
I think I cannot do this (no button visible), as the initial message/question was not written by me.
I understand.