Thank you - it’s gone now 
Mark solution?
50% is solved 
Indeed, I also verify that this is solved by adding “plain”. As for boot time it is slow. systemd-analyze blame gives:
6.697s NetworkManager-wait-online.service
5.006s plymouth-quit-wait.service
774ms systemd-udev-settle.service
705ms systemd-logind.service
552ms systemd-journald.service
350ms upower.service
347ms udisks2.service
344ms dev-mapper-luks\x2d35136a84\x2d62a4\x2d4131\x2db371\x2dfad9f2f>
304ms systemd-hostnamed.service
248ms blueman-mechanism.service
235ms systemd-localed.service
203ms grub-common.service
169ms exim4.service
163ms networking.service
159ms switcheroo-control.service
152ms purism-power-optimisations.service
146ms NetworkManager.service
145ms ModemManager.service
136ms e2scrub_reap.service
132ms accounts-daemon.service
131ms lm-sensors.service
127ms wpa_supplicant.service
118ms polkit.service
and a few more. The …waiting for suspend/resume device is still there.
Well, this output seems normal (I have pretty much the same) but I assume, that this “waiting for suspend/resume device” is the issue.
This one takes a long time here too. I wonder what it is doing (or is this simply an umbrella for the entire boot process?)
Edit: apprently yes, it is that: https://askubuntu.com/a/1168249
1 Like
But did systemd-analyze blame produce a list of start-up jobs (i.e. service files) and the time they took? Like this;
$ systemd-analyze blame
9.309s apt-daily.service
1.941s apt-daily-upgrade.service
1.131s nfs-server.service
1.044s man-db.service
988ms systemd-logind.service
806ms systemd-machined.service
705ms tor@default.service
558ms dev-mapper-luks\x2df77bd093\x2d9df3\x2d409e\x2dae24\x2da3ffdf434a8c.device
457ms systemd-journald.service
452ms upower.service
442ms logrotate.service
413ms udisks2.service
393ms dnsmasq.service
308ms apparmor.service
248ms systemd-cryptsetup@luks\x2d1d87c323\x2d8d00\x2d44c0\x2d9afa\x2d7b76f0651d4b.service
248ms networking.service
248ms schroot.service
226ms systemd-udev-trigger.service
216ms ModemManager.service
178ms NetworkManager.service
172ms switcheroo-control.service
169ms ssh.service
168ms phpsessionclean.service
167ms wpa_supplicant.service
165ms etckeeper.service
132ms trousers.service
132ms keyboard-setup.service
121ms binfmt-support.service
112ms polkit.service
112ms purism-power-optimisations.service
105ms lxc.service
102ms apache2.service
101ms libvirtd.service
I assume you know this but for others here you can enable / disable the various services being run with systemd. It is quite an elegant system. Nothing in your list pops out at me except for lm-sensors service as being something that can easily be disabled, but you likely want that running on boot anyway.
OK, but I am sure something is wrong. It takes more than 45 seconds from hitting Enter after writing the disk-decryption password to the login screen with i7 on L13 and the SSD disk it has. This is not normal. ArchLinux on lenovo X61, a machine of the year 2000 originally with WinXP, now with an SSD installed but with those old processors, takes less than 20 seconds to boot up. Manjaro on i5 on an HPtouchSmart takes a few seconds to bootup to the login screen.
I do not want to say that PureOS is worse. I want to say that something is wrong. There must be a bug somewhere. Unless all this time has to do with the encrypted disk. If this is the case, then OK.
Yes it does:
7.702s NetworkManager-wait-online.service
4.196s plymouth-quit-wait.service
2.057s systemd-cryptsetup@luks\x2dbffe30cc\x2dc700\x2d4a3d\x2d8dac\x2>
888ms systemd-logind.service
696ms systemd-machined.service
677ms e2scrub_reap.service
669ms dev-mapper-luks\x2d16dcf3c4\x2dfe0e\x2d4313\x2db905\x2df7056e8>
666ms firewalld.service
560ms upower.service
346ms systemd-hwdb-update.service
327ms systemd-journald.service
296ms udisks2.service
183ms systemd-udev-trigger.service
171ms lm-sensors.service
169ms exim4.service
156ms systemd-cryptsetup@luks\x2d236678b0\x2d271c\x2d44bb\x2d8708\x2>
147ms accounts-daemon.service
134ms winbind.service
132ms purism-power-optimisations.service
This is a wild shot in the dark and spoken from a bit of ignorance on the startup procedure, but since network manager-wait-online.service is taking so long, perhaps its having trouble either connecting or verifying its connected to the internet? Perhaps if you changed to a different DNS server it would speed up?
It may or may not be relevant, but it’s an easy check.
1 Like
DHCP can be troublesome if you are using it. Are you?
Me? I am, but I’m speaking from a time when my internet was taking forever to load web pages, turned out the DNS server (is that like saying ATM machine?) I was using was having issues. I switched to a different one and the issue went away.
Either of you - but mainly @peterpan and specifically in connection with effective boot time, not time to load web pages.
No. DNS == Domain Name System
1 Like
My thought was if its trying to verify it’s connected to the internet by connecting to some site, there might be some DNS shenanigans going on. However, I admit that I don’t know if it’s verifying connection to the internet or just to the network. If it’s the latter than I don’t believe my suggestion to be relevant.
I don’t really have an issue with the networking taking 7 seconds (this may be another forum post 
)
My issue is, that it takes a relatively long time BEFORE networking starts.
Thanks anyways for your suggestions
The following got rid of “Gave up waiting for suspend/resume device” at boot for me, and speeds up the boot time considerably:
# echo "RESUME=none" > /etc/initramfs-tools/conf.d/resume
# update-initramfs -u
Note that this disables resume from hibernation from swap. I do not use this functionality myself (I don’t even know if it can work with random-encrypted swap) but YMMV.
Good point.
I made some investigation for hibernation in this thread:
Now I use Byzantium, there are so frequent package updates that it’s no longer worth it to me.
That was it! Now it’s way faster, but having the possibility to hibernate would be cool as well.
But I’m fine with it as it is.
I also confirm that the above fix works. From pressing Enter after entering the disk decryption password to login screen it was about 45 seconds. With the above fix it now is 13 seconds.
So it takes about 32 seconds to wait for the resume device. Maybe PureOs devs would want to look into this.
1 Like