My Xubuntu 18.04 system experiences a very slow boot - looks like the kernel hangs for approximately 90 seconds during the boot (before handing off control to systemd).
For comparison, Windows 10 as a secondary system boots up in 10-15 seconds. This is what I would expect from a workstation running dual Xeon Silver 4110 and booting off of a NVMe SSD - not an over 2 minute boot time.

I tried analyzing the times as the OP in this question, here is the output of systemd-analyze:
Startup finished in 1min 34.506s (kernel) + 39.871s (userspace) = 2min 14.377s
graphical.target reached after 11.494s in userspace
What the heck is the kernel doing for so long?

systemd-analyze blame says this (these are only the first 5 entries - all others combined take less than 10 seconds, for a grand total of about 48 seconds):

     15.608s apt-daily.service
     14.775s apt-daily-upgrade.service
      6.261s NetworkManager-wait-online.service
      2.021s postfix@-.service
      1.155s zfs-fuse.service

I checked dmesg as well, seeking for any gaps as suggested here. There's a lot of stuff going on for the first 3 seconds, and then...

[    3.177248] sr 13:0:0:0: Attached scsi generic sg3 type 5
[    3.180142] random: fast init done
[    3.180463] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[    3.180494] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[    3.180505] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[   94.416745] EXT4-fs (nvme0n1p5): mounted filesystem with ordered data mode. Opts: (null)
[   94.538084] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[   94.558536] systemd[1]: Detected architecture x86-64.

91 seconds spent on what exactly? I tried to check what does the EXT4-fs line mean and found this bug in Fedora 18, which gave the suggestion to check mounts. Here's the relevant line from mount output:

/dev/nvme0n1p5 on / type ext4 (rw,relatime,errors=remount-ro)

What is going on here? As I suppose it might be relevant, here's my partition layout (blkid):

/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/nvme0n1: PTUUID="92606867" PTTYPE="dos"
/dev/nvme0n1p1: UUID="e202280b-c8bb-4420-96d5-7b61ef8d9cca" TYPE="swap" PARTUUID="92606867-01"
/dev/nvme0n1p3: LABEL="ZastrzeM-EM-<one przez system" UUID="04B86A80B86A6FDA" TYPE="ntfs" PARTUUID="92606867-03"
/dev/nvme0n1p4: UUID="F4766BFA766BBBCC" TYPE="ntfs" PARTUUID="92606867-04"
/dev/nvme0n1p5: UUID="875adb3f-9abd-43f7-a909-aa8a77676004" TYPE="ext4" PARTUUID="92606867-05"
/dev/sda: LABEL="tank" UUID="9630541256789858078" UUID_SUB="7514627587335991623" TYPE="zfs_member"
/dev/sdb: LABEL="tank" UUID="9630541256789858078" UUID_SUB="7746526721653217213" TYPE="zfs_member"
/dev/sdc: LABEL="tank" UUID="9630541256789858078" UUID_SUB="15647716461375923660" TYPE="zfs_member"

There's an NVMe SSD drive that I boot from, it has a "msdos" partition table (as reported by gparted), partitioned as follows:

  • p1: linux-swap
  • p2: extended partition containing p5, which contains the Xubuntu system
  • p3: windows 10 boot partition (language is Polish, hence the weird name)
  • p4: windows 10 system

There are also 3 HDDs in a ZFS matrix but they shouldn't matter. No idea what all those loops are.

As per Simon's request, here's the output of cat /proc/cmdline:

BOOT_IMAGE=/boot/vmlinuz-4.18.0-20-generic root=UUID=875adb3f-9abd-43f7-a909-aa8a77676004 ro quiet splash vt.handoff=1

Update: I found this question but neither the rng-tools answer nor the RESUME one improved the situation. I also tried to set the resume volume UUID directly as suggested here but to no avail.

  • Can you add the output from cat /proc/cmdline to your post? – Simon Sudler May 31 at 8:44
  • @SimonSudler Done. – Przemek D May 31 at 8:51
  • strange.... but I don't think the delay is comming from the NVM. Do you have a additional network device, that is maybe waiting for a DHCP replay? – Simon Sudler May 31 at 8:57
  • I do mount some Samba shares but they do not influence the boot time - verified by removing related fstab entries and rebooting - dmesg still shows approximately 90 second gap. However, now it happened before the random: lines. – Przemek D May 31 at 9:48
  • have you tried booting into the rescue system? Do you see the 90 seconds there as well? – Simon Sudler May 31 at 9:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.