ridiculous long bootup time

solskogen · 2022-11-22 11:53:02

For some strange reason my old Lattepanda board hangs for quite some time in "loader" whatever that means. Does anyone have a clue what the hell it does there?

systemd-analyze
Startup finished in 3.815s (firmware) + 39.486s (loader) + 1.524s (kernel) + 3.234s (initrd) + 2.956s (userspace) = 51.016s

solskogen · 2022-11-22 11:58:54

And it doesn't always happen either

systemd-analyze
Startup finished in 10.516s (firmware) + 8.642s (loader) + 1.491s (kernel) + 3.352s (initrd) + 3.272s (userspace) = 27.275s
graphical.target reached after 3.258s in userspace.

seth · 2022-11-22 12:06:56

That's your bootloader (grub, systemd-boot) which typically waits for you to tell it which kernel to load - but what it does exactly is hard to tell w/o even knowing which bootloader and how it's configured.

Slithery · 2022-11-22 12:12:03

'loader' means the bootloader.
Which one are you using?
How is it configured - is there a long timeout for the menu?

solskogen · 2022-11-22 12:14:17

I've tried both grub and systemd-boot. On both GPT and MBR. The grub menu comes up quite quickly, and it starts to load both the kernel and initrd after 5sec. It seems to me that it hangs after (or when) it loads the initrd.

Czarnodziej · 2022-11-22 13:17:10

EDIT: moved to https://bbs.archlinux.org/viewtopic.php?id=281529
I think I have similar issue:
systemd-boot:

Startup finished in 16.046s (firmware) + 20.635s (loader) + 1.352s (kernel) + 1min 14.220s (userspace) = 1min 52.255s

refind:

Startup finished in 10.071s (firmware) + 2.990s (loader) + 1.329s (kernel) + 1min 7.880s (userspace) = 1min 22.272s

Issue started to appear after systemd-update https://github.com/archlinux/svntogit-p … 6ed3979142

There is +10 seconds of delay before systemd-boot menu appears on screen during bootup.

Last edited by Czarnodziej (2022-11-23 11:03:57)

twelveeighty · 2022-11-22 15:49:20

If you have 'quiet' on the kernel parameter startup line, remove it and see if there's any errors or messages shown during (early) boot?

xerxes_ · 2022-11-22 17:15:51

Post output of commands:

init --version
systemd-analyze && systemd-analyze critical-chain && systemd-analyze blame
sudo journalctl -b

solskogen · 2022-11-22 19:18:11

"Loading initial ramdisk" is where it hangs sometimes. Grub timeout is 5sec.

[solskogen@tamra ~]# init --version
systemd 252 (252.1-2-arch)
+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified

[solskogen@tamra ~]$ systemd-analyze && systemd-analyze critical-chain && systemd-analyze blame
Startup finished in 3.814s (firmware) + 46.708s (loader) + 3.467s (kernel) + 3.207s (userspace) = 57.197s
graphical.target reached after 3.207s in userspace.
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 @3.207s
└─multi-user.target @3.206s
  └─systemd-logind.service @2.817s +388ms
    └─basic.target @2.735s
      └─sockets.target @2.735s
        └─dbus.socket @2.734s
          └─sysinit.target @2.730s
            └─systemd-timesyncd.service @2.459s +270ms
              └─systemd-tmpfiles-setup.service @1.879s +303ms
                └─local-fs.target @1.854s
                  └─run-credentials-systemd\x2dtmpfiles\x2dsetup.service.mount @1.888s
                    └─local-fs-pre.target @1.086s
                      └─systemd-tmpfiles-setup-dev.service @956ms +129ms
                        └─systemd-sysusers.service @865ms +58ms
                          └─systemd-remount-fs.service @687ms +146ms
                            └─systemd-journald.socket @593ms
                              └─-.mount @548ms
                                └─-.slice @548ms
1.050s dev-mmcblk0p2.device
 652ms systemd-udev-trigger.service
 559ms user@1000.service
 391ms systemd-networkd.service
 388ms systemd-logind.service
 347ms ldconfig.service
 303ms systemd-tmpfiles-setup.service
 270ms systemd-timesyncd.service
 245ms systemd-journald.service
 218ms systemd-backlight@backlight:intel_backlight.service
 200ms systemd-udevd.service
 185ms systemd-journal-catalog-update.service
 151ms systemd-fsck@dev-disk-by\x2dlabel-BOOT.service
 146ms systemd-remount-fs.service
 129ms systemd-tmpfiles-setup-dev.service
  86ms modprobe@fuse.service
  86ms dbus.service
  77ms boot.mount
  76ms systemd-modules-load.service
  66ms systemd-update-utmp.service
  63ms modprobe@configfs.service
  61ms modprobe@drm.service
  58ms systemd-sysusers.service
  57ms dev-hugepages.mount
  57ms dev-mqueue.mount
  57ms user-runtime-dir@1000.service
  53ms sys-kernel-debug.mount
  50ms sys-kernel-tracing.mount
  47ms kmod-static-nodes.service
  44ms systemd-network-generator.service
  35ms systemd-sysctl.service
  34ms systemd-journal-flush.service
  34ms systemd-update-done.service
  33ms systemd-user-sessions.service
  29ms systemd-random-seed.service
  17ms tmp.mount
  16ms sys-kernel-config.mount
  14ms var-log.mount
  13ms sys-fs-fuse-connections.mount
  11ms alsa-restore.service

For journalctl:
https://dpaste.com//HR696YS4C

Last edited by solskogen (2022-11-22 19:20:39)

solskogen · 2022-11-22 19:22:02

Looking at it I see a warning:

Nov 22 20:11:04 tamra kernel: **********************************************************
Nov 22 20:11:04 tamra kernel: **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
Nov 22 20:11:04 tamra kernel: **                                                      **
Nov 22 20:11:04 tamra kernel: ** trace_printk() being used. Allocating extra memory.  **
Nov 22 20:11:04 tamra kernel: **                                                      **
Nov 22 20:11:04 tamra kernel: ** This means that this is a DEBUG kernel and it is     **
Nov 22 20:11:04 tamra kernel: ** unsafe for production use.                           **
Nov 22 20:11:04 tamra kernel: **                                                      **
Nov 22 20:11:04 tamra kernel: ** If you see this message and you are not debugging    **
Nov 22 20:11:04 tamra kernel: ** the kernel, report this immediately to your vendor!  **
Nov 22 20:11:04 tamra kernel: **                                                      **
Nov 22 20:11:04 tamra kernel: **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
Nov 22 20:11:04 tamra kernel: **********************************************************

seth · 2022-11-22 19:36:07

https://bbs.archlinux.org/viewtopic.php … 5#p1958905 - what if you blacklist atomisp ?
Edit: though the module shows up late - it's thus probably not in the initramfs, hence not the cause of a stall at this point.

Last edited by seth (2022-11-22 19:37:32)

solskogen · 2022-11-23 07:19:58

That was a red herring

seth · 2022-11-23 10:10:09

Entropy issue?
What does your mkinitcpio.conf look like?
If you add some "echo '... done loadinit initrams'" to your /boot/grub/grub.cfg after the "initrd /initramfs-…" line, does that respond quickly?
Can you break the delay by typing away nonsense on your keyboard?

Arch Linux

#1 2022-11-22 11:53:02

ridiculous long bootup time

#2 2022-11-22 11:58:54

Re: ridiculous long bootup time

#3 2022-11-22 12:06:56

Re: ridiculous long bootup time

#4 2022-11-22 12:12:03

Re: ridiculous long bootup time

#5 2022-11-22 12:14:17

Re: ridiculous long bootup time

#6 2022-11-22 13:17:10

Re: ridiculous long bootup time

#7 2022-11-22 15:49:20

Re: ridiculous long bootup time

#8 2022-11-22 17:15:51

Re: ridiculous long bootup time

#9 2022-11-22 19:18:11

Re: ridiculous long bootup time

#10 2022-11-22 19:22:02

Re: ridiculous long bootup time

#11 2022-11-22 19:36:07

Re: ridiculous long bootup time

#12 2022-11-23 07:19:58

Re: ridiculous long bootup time

#13 2022-11-23 10:10:09

Re: ridiculous long bootup time

Board footer