Investigating Slow Grub Boot

I have just installed Zorin 17 alongside Zorin 16 and dual boot using Grub. Booting has never been rapid but since the install It now stands at over 3 minutes from pressing the return at the Grub menu to the presentation of login. It takes 2m 20s from the grub menu to displaying booting activity. In the 2m 20s period the screen is blank. Also this is the same regardless of booting Z16 or Z17.

I am asking for suggestions to help me determine where the problem lies:

  • Can I get additional debug on the screen during the blank screen period.
  • What logs are relevant and where are they?


Please paste this command below into your terminal and show us the output. Are there any errors? (Marked with red)

journalctl -b

1 Like

You also can run

systemd-analyze blame

to see a layout of what is causing boot to clog up. Please take No Action based on that output right away, since removing certain entries can be destructive.
Analyzing it is the first step.

m@m-HP-Z800-Workstation:~$ systemd-analyze blame
9.869s e2scrub_reap.service
7.644s NetworkManager-wait-online.service
5.042s logrotate.service
4.678s systemd-journal-flush.service
4.540s udisks2.service
4.435s systemd-udev-settle.service
4.181s networkd-dispatcher.service
3.137s accounts-daemon.service
3.015s fwupd.service
2.893s cups.service
2.679s power-profiles-daemon.service
2.315s NetworkManager.service
2.298s avahi-daemon.service
2.056s switcheroo-control.service
2.034s wpa_supplicant.service
2.021s thermald.service
2.017s systemd-logind.service
2.015s systemd-machined.service
1.963s libvirtd.service
1.580s gpu-manager.service
1.445s dev-sdb6.device
1.435s snapd.seeded.service
1.416s zfs-load-module.service
1.236s gdm.service
1.121s user@127.service
1.073s smartmontools.service
1.047s rsyslog.service
681ms apparmor.service
551ms colord.service
443ms lm-sensors.service
439ms systemd-udev-trigger.service
426ms nvidia-persistenced.service
383ms user@1000.service
371ms update-notifier-download.service
353ms packagekit.service
348ms systemd-modules-load.service
329ms sysstat.service
299ms polkit.service
295ms systemd-udevd.service
285ms systemd-resolved.service
261ms keyboard-setup.service
230ms libvirt-guests.service
230ms systemd-journald.service
206ms modprobe@drm.service
189ms systemd-oomd.service
187ms systemd-tmpfiles-setup.service
184ms systemd-sysusers.service
183ms systemd-random-seed.service
173ms systemd-timesyncd.service
164ms lvm2-monitor.service
156ms setvtrgb.service
146ms zfs-volume-wait.service
138ms systemd-tmpfiles-setup-dev.service
131ms qemu-kvm.service
127ms swapfile.swap
125ms upower.service
121ms systemd-sysctl.service
119ms snapd.service
83ms snapd.apparmor.service
76ms systemd-user-sessions.service
76ms zfs-mount.service
71ms systemd-tmpfiles-clean.service
70ms plymouth-read-write.service
67ms alsa-restore.service
64ms ufw.service
56ms dev-hugepages.mount
54ms dev-mqueue.mount
53ms systemd-binfmt.service
52ms sys-kernel-debug.mount
51ms sys-kernel-tracing.mount
46ms zsys-commit.service
46ms console-setup.service
45ms finalrd.service
42ms zsys-gc.service
41ms kmod-static-nodes.service
39ms systemd-remount-fs.service
37ms modprobe@configfs.service
36ms rtkit-daemon.service
35ms kerneloops.service
33ms systemd-update-utmp.service
32ms modprobe@fuse.service
27ms ubiquity.service
25ms libvirtd.socket
24ms proc-sys-fs-binfmt_misc.mount
20ms openvpn.service
18ms user-runtime-dir@127.service
18ms zsysd.service
12ms zfs-share.service
10ms systemd-update-utmp-runlevel.service
10ms user-runtime-dir@1000.service
9ms sysstat-collect.service
8ms run-qemu.mount
4ms snapd.socket
3ms sys-fs-fuse-connections.mount
3ms modprobe@efi_pstore.service
3ms sys-kernel-config.mount
2ms plymouth-quit-wait.service

Thanks d4f5409d
I need to investigate some of these services further as I don't understand why they are even running, zfs related services for example but I'm not sure how this helps?

m@m-HP-Z800-Workstation:~$ journalctl -xb does report some errors that need investigation (only the red entries listed):

Jan 09 05:25:16 m-HP-Z800-Workstation kernel: ioremap memtype_reserve failed -22

Jan 09 05:25:16 m-HP-Z800-Workstation kernel: ACPI BIOS Error (bug): Failure creating named object [_SB.PCI0._OSC.CAPD], AE_ALREADY_EXISTS (20221020/dsfield-1>
Jan 09 05:25:16 m-HP-Z800-Workstation kernel: ACPI Error: AE_ALREADY_EXISTS, CreateBufferField failure (20221020/dswload2-477)

Jan 09 05:25:16 m-HP-Z800-Workstation kernel: ACPI Error: Aborting method _SB.PCI0._OSC due to previous error (AE_ALREADY_EXISTS) (20221020/psparse-529)

Jan 09 05:25:16 m-HP-Z800-Workstation systemd-fstab-generator[357]: Failed to create unit file /run/systemd/generator/-.mount, as it already exists. Duplicate entry in /etc/fstab?

Jan 09 05:25:16 m-HP-Z800-Workstation systemd[348]: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.

Jan 09 05:25:36 m-HP-Z800-Workstation gnome-session-binary[1304]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' failed
Jan 09 05:25:36 m-HP-Z800-Workstation gnome-session-binary[1304]: GLib-GIO-CRITICAL: g_bus_get_sync: assertion 'error == NULL || *error == NULL' failed

Jan 09 05:36:21 m-HP-Z800-Workstation gdm-password][1667]: gkr-pam: unable to locate daemon control file

Jan 09 05:36:25 m-HP-Z800-Workstation systemd[1681]: Failed to start Application launched by gnome-session-binary.

Jan 09 05:36:29 m-HP-Z800-Workstation systemd[1681]: Failed to start Application launched by gnome-session-binary.

There are over 6000 entries and the latter ones appear to be related to when the OS is actually booting so I'll stop here.

Anything shouts out as relevant to issue in question?

Nothing in either stands out as a cause of slowness.
Your analyze-blame output is pretty quick, actually.
The log errors show mostly minor issues that are harmless or can be ignored.

Maybe the issue is with the hard drive, not OS?
Not entirely but this can prove half way my theory:

I admit I also think the problem may be the hard drive(s) but not any failures but a partitioning issue. The reason I think partitioning may be a issue is because I had extreme issues trying to install Zorin 17 along side existing Zorin 16.

> my hard is now partitioned thus:
>      /dev/sdb1 primary partition format FAT32, flags: boot,
>      /dev/sdb2 extended partition containing:
>          /dev/sdb5 logical partition, format ext4 label Zorin 16
>          /dev/sdb6 logical partition, format ext4 label Zorin 17

Could this be the issue? Its definitely not how Zorin 16 was installed with Windows 10.

The PC is an hp Z800 which is BIOS boot only by the way.

The sdb usually means the drive is secondary. Is it plugged in by USB?
If so, the USB port itself may be the bottleneck, reducing speed.

1 Like

The hp Z800 has two disk interfaces one is the usual four SATA and the second is four SAS managed by a hardware disk system. The single sda disk is a SATA disk used for system and user data backups. The sdb disk is mirrored array .

$ lsblk
sda      8:0    0   1.8T  0 disk 
├─sda1   8:1    0   1.3T  0 part 
└─sda2   8:2    0 490.1G  0 part 
sdb      8:16   0 556.9G  0 disk 
├─sdb1   8:17   0   512M  0 part 
├─sdb2   8:18   0     1K  0 part 
├─sdb5   8:21   0 176.8G  0 part 
└─sdb6   8:22   0 379.7G  0 part /
sr0     11:0    1  1024M  0 rom  
sr1     11:1    1  1024M  0 rom
$ sudo fdisk -l
Disk /dev/sdb: 556.93 GiB, 597998698496 bytes, 1167966208 sectors
Disk model: Logical Volume  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xccd9ccd9

Device     Boot     Start        End    Sectors   Size Id Type
/dev/sdb1  *         2048    1050623    1048576   512M  b W95 FAT32
/dev/sdb2         1052670 1167964159 1166911490 556.4G  5 Extended
/dev/sdb5         1052672  371730431  370677760 176.8G 83 Linux
/dev/sdb6       371732480 1167964159  796231680 379.7G 83 Linux

Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD2003FYYS-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 91D17CA0-2D6D-11EB-A5E3-78ACC03C2C48

Device          Start        End    Sectors   Size Type
/dev/sda1        2048 2879275007 2879272960   1.3T Linux filesystem
/dev/sda2  2879275008 3907028991 1027753984 490.1G Linux filesystem

And I have just noticed something odd: Why is "Disklabel type: gpt" for /dev/sda but "Disklabel type: dos" for /dev/sdb. Perhaps its not a issue since /dev/sda is the boot disk.

DOS is the default until something writes over to change that, for example, to GPT.

I did setup sdb as msdos and I think the disk used for sda came from a NAS.

I have just completed removing the Zorin 16 partition. I also moved the Zorin 17 to a Primary partition. The partition table is now just a single partition. Doing this did not improve the boot time. Still 2mins 20 sec before boot messages an a total of 3min 38sec to login screen.

I really need to see what grub is doing when the screen is blank, the 2min 20ses period.

An update: appears to be associated with "Loading initial ramdisk". A common complaint it appears.

Further digging:

I set the Grub environment variable debug using:

sudo grub-editenv - set debug=-all

and ran

sudo update-initramfs -u -v

This spews out a huge amount of not very helpful messages. I was hoping to notice the messages pause for approximately 2 minutes but nothing was obvious. I therefore concluded booting takes a long time but I was not happy with this.

I did some reading of the initramfs docs together with global search for other similar issues. Two things popped up:

  1. the initramfs configuration parameter MODULES, and
  2. compiling the kernel with INSTALL_MOD_STRIP

Trying MODULES=dep reduced the size of initrd.img to 116mB from 125mB but I was hoping to bet nearer 50mB.

item 2. is a bit out of my capability so cannot take that any further. I also think that would make the install a custom setup and I don't want that.

If you are not seeing any log entries that show it; I would highly recommend checking the cable connections and contacts.

thanks. However I would then expect to see other issues with applications loading very slowly, failing, backups failing and other issues relating to the whole disk backups but I'm not seeing that. Granted using a hard disk is a lot slower than SSD but I can live with that. No I think it the size of the initrd.img file. It appears to contain every module that has ever been written. I also use Fedora and the size of its initrd.img file is circa 45mB and boots a lot faster.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.