1

I am runing the latest MINT Linux Vanessa (Ubuntu 22.04 LTS) on two PCs and I experience the same long boot duration. I followed all hints and tips but I have not found any solution yet. Both installations are BIOS based, no EFI boot procedure.

  • I have removed nosplash and quiet from the grub configuration such that I can see all boot messages.
  • After choosing an option from the boot menu it takes around 20 seconds for the first boot message to appear on the screen. That exactly is my problem. What happens during that phase?
  • All the nice tools for finding out, how much time each boot step takes, do not really help. systemd-analyze tells me about 18 seconds for booting, but exactly the first 20 seconds seem to be not included.
  • The 20 second delay happens independently of cold booting or waking up from hibernation.
  • I followed several hints like adding pci=noaer,nomsi to the boot options without success

My question is: How can I speed up the boot process? At the moment it takes around 45 seconds (which is not really dramatic) but it could take only 18 seconds if understand correctly what's actually going on during booting.

Here some information:

Output of systemd-analyze 
Startup finished in 9.311s (kernel) + 8.854s (userspace) = 18.166s 
graphical.target reached after 8.846s in userspace



Output of systemd-analyze blame
4.211s NetworkManager-wait-online.service
3.463s grub-initrd-fallback.service
2.312s systemd-udev-settle.service
1.103s dev-sda4.device
1.013s tor@default.service
 844ms blueman-mechanism.service
 634ms influxdb.service
 570ms cups.service
 501ms networkd-dispatcher.service
 421ms systemd-resolved.service
 374ms udisks2.service
 311ms accounts-daemon.service
 294ms avahi-daemon.service
 288ms ModemManager.service
 277ms bluetooth.service
 251ms ubuntu-system-adjustments.service
 238ms NetworkManager.service
 226ms apparmor.service
 213ms alsa-restore.service
 200ms systemd-timesyncd.service
 199ms systemd-logind.service
 195ms mono-xsp4.service
 188ms zfs-load-module.service

Although lots of information I add the first part of dmesg output below, thanks for any good idea!

[    0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-11-12
[    0.000000] Linux version 5.15.0-56-generic (buildd@lcy02-amd64-004) (gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 (Ubuntu 5.15.0-56.62-generic 5.15.64)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-56-generic root=UUID=06c00ee6-9db7-4bac-8bbf-efff4eb6ef97 ro resume=UUID=a542e607-0a04-410f-b47e-47fe4c4ae9bc
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Hygon HygonGenuine
[    0.000000]   Centaur CentaurHauls
[    0.000000]   zhaoxin   Shanghai  
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[    0.000000] signal: max sigframe size: 1776
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009c7ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009c800-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000009cf4afff] usable
[    0.000000] BIOS-e820: [mem 0x000000009cf4b000-0x000000009d41dfff] reserved
[    0.000000] BIOS-e820: [mem 0x000000009d41e000-0x00000000a2284fff] usable
[    0.000000] BIOS-e820: [mem 0x00000000a2285000-0x00000000a2342fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000a2343000-0x00000000a2368fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000a2369000-0x00000000a2c98fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000a2c99000-0x00000000a2ffefff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000a2fff000-0x00000000a2ffffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000a3800000-0x00000000a7ffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000456ffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.8 present.
[    0.000000] DMI:  /NUC5i5RYB, BIOS RYBDWi35.86A.0385.2020.0519.1558 05/19/2020
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 1596.228 MHz processor
[    0.000858] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000862] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000872] last_pfn = 0x457000 max_arch_pfn = 0x400000000
[    0.001011] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[    0.001996] total RAM covered: 16288M
[    0.002149]  gran_size: 64K  chunk_size: 64K     num_reg: 10     lose cover RAM: 16M
[    0.002153]  gran_size: 64K  chunk_size: 128K    num_reg: 10     lose cover RAM: 16M
[    0.002155]  gran_size: 64K  chunk_size: 256K    num_reg: 10     lose cover RAM: 16M
[    0.002157]  gran_size: 64K  chunk_size: 512K    num_reg: 10     lose cover RAM: 16M
[    0.002159]  gran_size: 64K  chunk_size: 1M  num_reg: 10     lose cover RAM: 16M
[    0.002161]  gran_size: 64K  chunk_size: 2M  num_reg: 10     lose cover RAM: 16M
[    0.002163]  gran_size: 64K  chunk_size: 4M  num_reg: 10     lose cover RAM: 16M
[    0.002165]  gran_size: 64K  chunk_size: 8M  num_reg: 10     lose cover RAM: 16M
[    0.002167]  gran_size: 64K  chunk_size: 16M     num_reg: 10     lose cover RAM: 16M
[    0.002169]  gran_size: 64K  chunk_size: 32M     num_reg: 10     lose cover RAM: 0G
[    0.002171]  gran_size: 64K  chunk_size: 64M     num_reg: 10     lose cover RAM: 0G
Improve this question
6
  • After selecting the entry in the GRUB menu, the kernel and the initramds are copied into RAM and decompressed. Bottleneck can be the disk and the CPU. In both cases, reducing the size of data to transfer and decompress may help. Reducing the size of the kernel is far from trivial. For reducing the size of the initramfs, you can try mktirfs. I have never used the tool so I do not regard this as a definitive answer.
    – Hermann
    Dec 20, 2022 at 20:29
  • I have one very old laptop, in which I've replaced an IDE HDD with a M.2 SATA SSD on a no-name adapter card from Aliexpress (seems to have a JMicron JM20330 chip). When the Linux kernel starts, the system seems to hang for 20 seconds or so, apparently because the kernel first attempts to use some IDE DMA mode the adapter doesn't support properly (according to dmesg output). After a while the kernel times out, resets the adapter and falls back to another mode, which works just fine after that. Your case might be something similar; would need to check the whole dmesg output to know more.
    – telcoM
    Dec 21, 2022 at 5:04
  • @telcoM: Thanks for the hint! Exactly that was what I expected to find in the dmesg output after experiencing the long boot duration. Unfortunately, the demsg output starts AFTER the 20 seconds delay. The timestamps in the first column of the output increase up to the 18 seconds of systemd-analyze output. That means, the delay does not happen during the "ordinary" startup which is reported by dmesg and there are no messages about timeouts, hanging hardware etc.
    – Jens
    Dec 22, 2022 at 16:00
  • @Hermann: As I wrote tecoM a minute ago, the delay happens before anything is reported. I was also looking in the direction of hard disc access, but at least in the dmesg output everything is running fine (Intenso SSD Sata III, V0414A0, max UDMA/133 followed by some messages without any warning). The two PCs with the same problem have completely different configurations (Intel Nuc vs Fujitsu laptop, Intenso Sata III vs NVMe, and so on).
    – Jens
    Dec 22, 2022 at 16:15
  • @Jens According to my theory, I/O is slow while the kernel is being loaded. The kernel will not produce any output during that time. You can test my theory by adding something like echo 'Loading Kernel' and echo 'Loading initrd' before the respective lines in your grub.cfg. You can also try displaying the progress. I just made a test run with an old laptop of mine: One minute for loading the 11 MB kernel, two minutes for the 35 MB initrd, 15 seconds to the greeter login. Your 20 seconds on less ancient hardware seem totally fine to me.
    – Hermann
    Dec 22, 2022 at 21:54

1 Answer 1

Reset to default
0

Since the 20-second delay happens before even the first kernel messages, it suggests it might have something to do with GRUB, or perhaps with the kernel's earliest interactions with the system firmware (as the kernel receives the e820 memory map, ACPI tables, DMI information and other stuff from the firmware).

If you feel like building a custom kernel, there is a kernel feature called "early printk" which might give additional insights on the very earliest steps of the kernel start-up.

On the other hand, the 20-second delay very much seems like it might be something in GRUB. You could print out your GRUB configuration, then go to GRUB command prompt and try out the commands that are part of your normal Linux boot menu item. That way you could see if some command takes an unusually long time.

GRUB's search command will attempt to access all your disks in whatever order the firmware presents them, until the command finds what it was told to search for. I would recommend testing all relevant search commands to see if any of them is the culprit. Then you might try the commands to load your kernel and initramfs files (as applicable).

You could also try GRUB's TAB completion: type ls (hd, press the TAB key twice, and see how many disks GRUB can see. Then try and identify them. If it turns out that e.g. an old and slow disk is presented before your actual system disk, you might have to swap SATA cables around so that the fastest disks are presented first.

Worst case, you'll find a disk that is getting slow to spin up as a possible sign of imminent hardware failure.

Improve this answer
1
  • Thanks! It is the starting of the initrd, not easy to speed up without capital changes of the Ubuntu/Mint environment…
    – Jens
    Dec 24, 2022 at 13:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .