How to get rid of these warnings at boot?

Software PureOS
1

Running PureOS byzantium and have a quite long boot sequence, which I’m trying to fix.

I have two warnings, which are probably a hint for the relatively long boot time:
From cryptsetup: couldn't determine device type, assuming default (plain).
I get this warning about 12 times at each boot.

A search on the internet doesn’t really show me any useful solutions about this…

The second one is: Gave up waiting for suspend/resume device

This seems to be a more known issue, but the proposed solutions aren’t really informative, because the file name which is mentioned there, doesn’t exist: https://superuser.com/questions/1204627/deleted-a-partition-now-getting-gave-up-waiting-for-suspend-resume-device-mes

I’m really thankful for any help :slight_smile:

2

After boot, can you run sudo systemd-analyze blame to determine what is taking time during boot?

2 Likes
3

I just got rid of this by adding plain to the options for the swap partition (not the root partition!) in /etc/crypttab and running update-initramfs -u. It’s “plain” (as in no luks header) so the assumption makes sense.

2 Likes
4

Does that mean, it isn’t encrypted as well?

So you mean, adding plain to these options “just work”?
swap,cipher=aes-xts-plain64,size=256

5

Thank you, it seems the long wait time comes from something before systemd has something to analyze.

1 Like
6

That’s what I did. I put it as first option. “plain” here doesn’t mean unencrypted, it means that there is no header to identify the encryption algorithm and such, which would be fairly pointless when using a random key every boot. Explicitly specifying it avoids an auto-detection step.
(Though I haven’t noticed an improvement in boot speed)

1 Like
8

Thank you - it’s gone now :slight_smile:

9

Mark solution?

10

50% is solved :slightly_smiling_face:

11

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.

12

Well, this output seems normal (I have pretty much the same) but I assume, that this “waiting for suspend/resume device” is the issue.

13

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
14

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
15

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.

16

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.

17

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

18

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
19

DHCP can be troublesome if you are using it. Are you?

20

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.

21

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