How to get rid of these warnings at boot?

Thank you - it’s gone now :slight_smile:

Mark solution?

50% is solved :slightly_smiling_face:

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:

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 :wink: )
My issue is, that it takes a relatively long time BEFORE networking starts.
Thanks anyways for your suggestions :slight_smile:

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