Boot stuck for 15 Minutes

Hi,

I have installed Ubuntu MATE on a USB stick running in a MacBook. Everything works fine, but the boot takes about 15 minutes.
With dmesg this can also be traced, however, I now no longer know what to do.

[    2.789097] usb 2-1.8.1.3: Product: Bluetooth USB Host Controller
[    2.789101] usb 2-1.8.1.3: Manufacturer: Apple Inc.
[    3.356208] scsi 6:0:0:0: Direct-Access     JetFlash Transcend 64GB   1100 PQ: 0 ANSI: 6
[    3.356690] sd 6:0:0:0: Attached scsi generic sg1 type 0
[    3.357648] sd 6:0:0:0: [sda] 123404288 512-byte logical blocks: (63.2 GB/58.8 GiB)
[    3.358099] sd 6:0:0:0: [sda] Write Protect is off
[    3.358103] sd 6:0:0:0: [sda] Mode Sense: 43 00 00 00
[    3.358620] sd 6:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn t support DPO or FUA
[    3.395005]  sda: sda1 sda2 < sda5 sda6 >
[    3.397060] sd 6:0:0:0: [sda] Attached SCSI removable disk
[  939.023822] fbcon: Taking over console
[  939.037852] Console: switching to colour frame buffer device 160x50
[  958.861229] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
[  959.394125] systemd[1]: Inserted module autofs4

Does anyone have any tips for me? :slight_smile:

systemd-analyze should show in a couple of lines how long the bootup process took.

systemd-analyze blame will list each service and how long it took. That should give you an idea where the system is spending time during boot.

You can post here the top 10 lines with systemd-analyze blame | head

2 Likes

The last reboot took 15 minutes again, however dmesg now says it only went about a minute.

When I did systemd-analyze last time, it showed a few seconds for userspace and several minutes for kernel.

For systemd-analyze blame the times were not really high either, the highest entry was a few seconds.

I have tried it several times now and the log entries only start after I have entered my passphrase to decrypt the hard drive.

Post output of systemd-analyze critical-chain so we can see what's going on ...

Here is the output:

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @13.591s
└─multi-user.target @13.591s
  └─kerneloops.service @13.571s +19ms
    └─network-online.target @13.566s
      └─NetworkManager-wait-online.service @5.732s +7.833s
        └─NetworkManager.service @4.137s +1.593s
          └─dbus.service @4.134s
            └─basic.target @4.107s
              └─sockets.target @4.107s
                └─snapd.socket @4.106s +769us
                  └─sysinit.target @4.083s
                    └─snapd.apparmor.service @4.031s +51ms
                      └─apparmor.service @3.703s +326ms
                        └─local-fs.target @3.702s
                          └─boot-efi.mount @3.675s +27ms
                            └─boot.mount @3.651s +20ms
                              └─[email protected]\x2duuid-34a9ac9b\x2ddee0\x2d4bc5\x2d899a\x2d454eefc459da.service @3.491s +159ms
                                └─dev-disk-by\x2duuid-34a9ac9b\x2ddee0\x2d4bc5\x2d899a\x2d454eefc459da.device @3.490s

But the time is not really relevant, since it is only seconds, but my laptop takes 15 minutes from grub to disk password.

Searched for "too long from grub to disk password" ... when setting up the encryption did you set the --iter-time flag? It controls the length of time spent running password hash iterations; defaults to 2000 ms.

https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode

No, I didn't set a specific value, so I guess it will have the default value in it.

However, I installed Linux on the stick in a VM and now I use it directly on the laptop.

Should I change the value and if so, to which one?

I have deleted my old passphrase and set a new one. This should have adjusted the default value for my hardware?! Unfortunately it is still not better.

Now I have found it. Since the kernel is not in the encrypted partition, I ruled out encryption as the cause. Then when I noticed that there is an EFI partition on the stick, but the GRUB comes through the BIOS, I suspected that as the cause. So I installed the GRUB into the EFI partition and now the computer boots fast too. Maybe it helps someone else to solve the problem.

1 Like

Thanks for coming back with your solution.

1 Like