2

My system thinks it is booting quickly. journlctl -k reports:

-- Logs begin at Wed 2018-10-24 20:44:45 CDT, end at Fri 2018-10-26 21:52:05 CDT. --
Oct 26 20:53:11 Neurosprite kernel: Linux version 4.15.0-38-generic (buildd@lcy01-amd64-023) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #41-Ubuntu SMP Wed Oct 10 10:59
Oct 26 20:53:11 Neurosprite kernel: Command line: BOOT_IMAGE=/vmlinuz-4.15.0-38-generic root=UUID=d22f3d07-d029-4bb9-8157-44c0a42bb7d5 ro
Oct 26 20:53:11 Neurosprite kernel: KERNEL supported cpus:
Oct 26 20:53:11 Neurosprite kernel:   Intel GenuineIntel
Oct 26 20:53:11 Neurosprite kernel:   AMD AuthenticAMD
Oct 26 20:53:11 Neurosprite kernel:   Centaur CentaurHauls
Oct 26 20:53:11 Neurosprite kernel: x86/fpu: x87 FPU will use FXSAVE
Oct 26 20:53:11 Neurosprite kernel: e820: BIOS-provided physical RAM map:
Oct 26 20:53:11 Neurosprite kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
Oct 26 20:53:11 Neurosprite kernel: BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
Oct 26 20:53:11 Neurosprite kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
Oct 26 20:53:11 Neurosprite kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000cfdeffff] usable
Oct 26 20:53:11 Neurosprite kernel: BIOS-e820: [mem 0x00000000cfdf0000-0x00000000cfdf0fff] ACPI NVS
Oct 26 20:53:11 Neurosprite kernel: BIOS-e820: [mem 0x00000000cfdf1000-0x00000000cfdfffff] ACPI data
Oct 26 20:53:11 Neurosprite kernel: BIOS-e820: [mem 0x00000000cfe00000-0x00000000cfefffff] reserved
O
:
:
Oct 26 20:53:14 Neurosprite kernel: IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
Oct 26 20:53:16 Neurosprite kernel: r8169 0000:03:00.0 enp3s0: link up
Oct 26 20:53:16 Neurosprite kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
Oct 26 20:53:18 Neurosprite kernel: usblp0: removed
Oct 26 20:53:18 Neurosprite kernel: usblp 8-2:1.0: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0028
Oct 26 20:53:19 Neurosprite kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff windo
Oct 26 20:53:19 Neurosprite kernel: caller os_map_kernel_space.part.7+0xda/0x120 [nvidia] mapping multiple BARs
Oct 26 20:53:25 Neurosprite kernel: rfkill: input handler disabled

that is 12 seconds. Looking at systemd-analyze blame I find:

          7.102s configure-printer@usb-008-002.service
          2.349s NetworkManager-wait-online.service
          1.594s dev-sdb5.device
           732ms fwupd.service
           709ms snapd.service
           558ms lvm2-pvscan@8:50.service
           488ms udisks2.service
           316ms systemd-journal-flush.service
           304ms openvpnas.service
           294ms dev-loop0.device
           283ms dev-loop2.device
           271ms dev-loop1.device
           266ms dev-loop8.device
           264ms systemd-logind.service
           260ms dev-loop6.device
           259ms dev-loop3.device
           257ms dev-loop9.device
           250ms dev-loop13.device
           246ms dev-loop4.device
           237ms dev-loop5.device
           236ms dev-loop10.device
           234ms NetworkManager.service
           230ms dev-loop11.device
           229ms dev-loop7.device
           226ms dev-loop12.device
           177ms dev-mapper-centos\x2dswap.swap
           161ms systemd-udevd.service
           157ms snap-gnome\x2dsystem\x2dmonitor-57.mount
           156ms snap-core-5662.mount
           147ms systemd-resolved.service
           146ms networkd-dispatcher.service
:
:

Consistent with 12 seconds. Except, it takes well over 5 minutes before any of this starts!

Removing "splash" and "quiet" from /etc/default/grub I get 2 lines on a purple background

Loading linux-4.15.0-38-generic...
Loading initial ramdisk...

And then 5 minutes later it actually boots.

The system is a fresh install on an SSD. Once running, it runs fast. The boot logs don't even start until after the problem is over.

This is not the same problem others have listed - it does not hang, and the actual booting goes quickly when it starts going. It just does not start for 5 minutes. Anyone have any ideas on why?

Thanks, Mike

  • 1
    Might there be some UEFI conflicts at play, here? – Omio Oct 27 '18 at 3:16
  • Very possible. I will have to study UEFI and see what the BIOS screen can tell me. – Mike Rosing Oct 27 '18 at 13:19
  • According to this page: itsfoss.com/check-uefi-or-bios I have legacy BIOS, not UEFI. So this could be a problem - the boot code expects UEFI and then times out and goes to legacy BIOS. There must be something in grub config that will force it to go straight to BIOS?? – Mike Rosing Oct 27 '18 at 13:31
  • I have it backwards. BIOS loads GRUB. What is taking a long time is loading initrd.img-4.15.0-38-generic which is 66,240,456 bytes. BIOS knows how to read the disk, but GRUB does not use the same routines - maybe?? 12.04 does not have this problem, but it is booting from HDD. Since the SDD is on SATA, it should look like a standard hard drive. – Mike Rosing Oct 27 '18 at 14:17
  • I think this is caused by your BIOS has problem hooking int13 on your SSD. If booting from HDD is not a problem, may be you can try install grub and /boot on HDD and use rootfs on SSD. This happens because CSM has not improving for years. – Alvin Liang Oct 28 '18 at 1:59
0

A lot more digging and I found this article: https://unix.stackexchange.com/questions/89923/how-does-linux-load-the-initrd-image Because the BIOS can only see 1 MB at a time, and the initrd is 66 MB, it takes it a long time to read in a block, switch to 32 or 64 bit mode, move it and switch back to 16 bit mode for the next block. 12.04 initrd is only 14 MB, so it seems faster.

It's time a for a new computer that uses UEFI so it can see larger disk and ram automatically. For now, I just have to wait - there is no way to make it faster (other than rewrite the BIOS!!) At least I learned more about how my computer works.

  • 1
    Lots of people use BIOS Legacy (CSM) booting instead of UEFI booting and often times it doesn't noticeably impact boot speed. I would keep looking for other solutions. – WinEunuuchs2Unix Oct 27 '18 at 16:27

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.