0

I have Lubuntu 18.04 LTS i386 installed on an SD card on Intel Classmate PC laptop.

I have recently cloned the 16GB card to a 64GB one using Win32DiskImager and resized it using GParted LiveUSB.

The boot is absurdly slow now, and I have looked around and tried all the solutions but it seems the problem lies somewhere in GRUB, but I'm kinda fresh to Linux so I don't know here to start looking to identify it.

I disabled splash to see the kernel boot messages and found out the boot is stalling for exactly 2 minutes (120 seconds) in grub, before loading the kernel (with blank screen, no cursor), which would suggest some kind of a timeout event, but I don't know where to start looking for the cause behind it.

So far I tried solutions form other similar questions:

  • /etc/fstab shows the correct UUID for disk (matching blkid one)
  • blockdev --getalignoff /dev/sdb1 shows 0
  • swap is a file, not a partition
  • /etc/crypttab doesn't exist
  • /etc/initramfs-tools/conf.d is epmty
  • I ran update-grub
  • I ran update-initramfs -uk all
  • systemd-analyze doesn't account for the entirety of boot time
  • dmesg shows nothing interesting, as boot messages only start showing up after 2 minutes of grub limbo

It seems the stall is somewhere in grub. I have checked to make sure that /boot/grub/grub.cfg shows UUID matching blkid one everywhere. /var/boot.log is empty journalctl -b starts at the same point dmesg does (after 2 minutes)

Any ideas as to where I could start looking to identify the problem would be greatly appreciated!

Improve this question
4
  • Is the other SD card used? and thus you have two or more volumes with the same UUID (which is a problem), are you using swapfile or swap partition? (swap partitions usually aren't resized, but deleted & re-created which can change UUID). I have assumed BIOS and not UEFI given you've mentioned x86, is this correct?
    – guiverc
    Feb 10, 2020 at 10:29
  • No, it's just the new SD card, the old one is retired. And yes, it's BIOS, not UEFI. I'm using swapfile (at /swapfile, listed without UUID in /etc/fstab ).
    – Sos Sosowski
    Feb 10, 2020 at 10:36
  • Run systemd-analyze critical-chain and systemd-analyze blame to see what part of the boot tha takes the time.
    – Soren A
    Feb 10, 2020 at 10:41
  • systemd-analyze shows 30 seconds total boot time, whereas the entire boot takes over 2 minutes. Whatever happens happens inside grub / boot, before kernel loads, but I don't know how to debug that
    – Sos Sosowski
    Feb 10, 2020 at 12:31

1 Answer 1

Reset to default
0

Ok, I found the reason behind this.

I typed set debug=all in grub console which allowed me to trace down everything that happens and loading initial ramdisk is what's the slowest. Here's why.

In non-uefi mode GRUB needs to load initrd kernel image from disk using BIOS commands, switching in and out of protected mode to read every block. This plus SDXC card latency creates a lot of lag when reading the kernel image. Kernel image is over 60MB in size and GRUB is configured to load it by smaller chunks in BIOS mode by default to avoid running out of memory. Here is the GRUB bug associated with this: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/944347

The smaller card was simply a tad faster, not by much but GRUB lazy loading scheme amplified the difference by far.

Improve this answer

You must log in to answer this question.

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