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

Improve this question
5
  • 1
    Might there be some UEFI conflicts at play, here?
    – Omio
    Oct 27, 2018 at 3:16
  • Very possible. I will have to study UEFI and see what the BIOS screen can tell me.
    – Mike Rosing
    Oct 27, 2018 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, 2018 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, 2018 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, 2018 at 1:59

2 Answers 2

Reset to default
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.

Improve this answer
1
  • 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, 2018 at 16:27
0

I had this problem on my PC. Switching from BIOS legacy (CSM) mode to UEFI solved it. It is risky so I don't recommend it if you can bear the loading time.

I think most computers support UEFI these days (at least, everything from the windows 8 era or newer), but you may have installed linux in legacy mode.

The steps are as follows:

LAST WARNING: please do not even try this if you don't understand all the instructions, if you fail in the middle, the PC will be broken and unusable.

  1. prepare a ubuntu USB stick, and do a full backup of your hard disk.
  2. Start the PC, go into the motherboard's settings, disable CSM and enable UEFI mode (in practice, the setting for me was to change "secure boot" from "disabled" to "setup" mode). With this setting, grub and linux will not be able to boot (but it is still reversible at this point).
  3. Insert the usb stick and start ubuntu. (Do not choose to install ubuntu.)
  4. In the live usb ubuntu session (note: you need internet to work):
    • At this point you should check that ubuntu is indeed booted in UEFI mode. One way to check is ls /sys/firmware/efi. If the folder exists, then you are in UEFI mode. If it doesn't, restart and check your motherboard settings.
    • In the partition editor, shrink the first partition so you have 200MB of free space and move it to the right by 200MB. This takes a lot of time, as it will really just move all the bytes of the partition. It is also quite dangerous, as, between the start and the end of this process, the filesystem is most likely in a broken state.
    • In the same partition editor, create a partition at the beginning of the volume, with the following settings:
      • filesystem is FAT32
      • size is 200MB
      • boot flag enabled
    • install and run boot-repair (sudo add-apt-repository ppa:yannubuntu/boot-repair;sudo apt-get update;sudo apt-get install -y boot-repair;boot-repair). Follow the instructions.

4- reboot, remove the USB stick.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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