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.
cat /proc/cmdline
to your post? – Simon Sudler May 31 '19 at 08:44fstab
entries and rebooting -dmesg
still shows approximately 90 second gap. However, now it happened before therandom:
lines. – Przemek D May 31 '19 at 09:48fsck
on the NVMe partition - do you have any idea on how could I verify that it's the case or disable that check? AFAIK it should be routinely conducted every n boots, but not everytime. – Przemek D May 31 '19 at 11:12fastboot
afterquiet splash
– WinEunuuchs2Unix Jun 03 '19 at 11:49dmesg
. – Przemek D Jun 04 '19 at 08:47