Very slowwwww boot process ...since last update

Issues & Assistance Newbies
#1

Just updated 2021-04-26 11h am Eastern time.

Suddenly it takes an eternity to boot .

I have ran systemd-analyse blame and here is what I get for the first worst time :

[[email protected] ~]# systemd-analyze blame
10.163s lvm2-monitor.service
 9.882s dev-mapper-luks\x2d18c56783\x2d809e\x2d43cd\x2db687\x2d7377c138a95b.device
 7.541s systemd-vconsole-setup.service
 6.709s systemd-swap.service
 6.364s systemd-guest-user.service
 5.814s iwd.service
 5.583s ldconfig.service
 5.226s connman.service
 4.675s systemd-remount-fs.service
 4.664s avahi-daemon.service
 4.597s ead.service
 3.983s ananicy.service
 3.873s bluetooth.service
 3.454s ofono.service
 3.434s systemd-logind.service
 3.157s systemd-journal-flush.service
 2.695s [email protected]
 2.621s systemd-modules-load.service
 2.494s systemd-guest-config.service
 2.223s systemd-tmpfiles-setup.service
 1.620s polkit.service
 1.028s systemd-udevd.service
 1.009s systemd-sysusers.service

I have an HP pavillion G6 laptop with an AMD cpu and a radeon graphic card 6Gb memory.
I boot over a USB disk encrypted with luks. I have 2 encrypted partition one for root and all (btrfs with subvolumes) and another for swap. I don't use LVM on the USB disk, but I have another linux on my laptop harddisk (opensuse encrypted with LVM partitions).

Do you have any clues on where should I start to reduce that startup time that seems to never end ???

Regards,
BT

#2

As we haven't seen a bunch of similar posts on this, and the average user isn't setting up their system with full disk encryption I'd put my money on it somehow being related to your encryption setup.

None of the distro Devs use this type of setup, so searching recent posts online might be your best bet until someone with familiarity with your issue happens to stumbble upon your thread.

Not a fix of course, but you could try rolling back your system with timeshift if you make no progress and simply want to restore your boot times. Be sure to read the Garuda Wiki on restoring your system with timeshift.

Best of luck, and hello from BC.

1 Like
#3

There's nothing in there that would indicate something taking an "eternity". Could you be more specific, and perhaps look at systemd-analyze, systemd-analyze --user blame, and systemd-analyse critical-chain too?

#4

I have outputed the other systemd-analyze :

> [[email protected] ~]# systemd-analyze 
> Startup finished in 30.647s (kernel) + 21.810s (userspace) = 52.458s 
> graphical.target reached after 21.810s in userspace

> ❯ systemd-analyze --user blame                                                                                                                                      
> 50.212s xdg-desktop-portal.service
>  8.917s psd-resync.service
>  1.220s pulseaudio.service
>   518ms psd.service
>   244ms xdg-desktop-portal-wlr.service
>    28ms xdg-document-portal.service
>    20ms xdg-user-dirs-update.service
>    18ms gvfs-daemon.service
>    17ms at-spi-dbus-bus.service
>    10ms dbus.socket
>     9ms xdg-permission-store.service

> [[email protected] ~]# systemd-analyze critical-chain
> graphical.target @21.810s
> └─greetd.service @21.808s
>   └─plymouth-quit-wait.service @21.041s +762ms
>     └─systemd-user-sessions.service @20.997s +39ms
>       └─network.target @20.992s
>         └─connman.service @13.180s +7.810s
>           └─dbus.service @13.175s
>             └─basic.target @13.165s
>               └─sockets.target @13.165s
>                 └─dbus.socket @13.165s
>                   └─sysinit.target @13.064s
>                     └─systemd-timesyncd.service @12.926s +137ms
>                       └─systemd-tmpfiles-setup.service @12.699s +221ms
>                         └─systemd-journal-flush.service @10.865s +1.831s
>                           └─var-log.mount @10.704s +158ms
>                             └─[email protected]\x2d18c56783\x2d809e\x2d43cd\x2db687\x2d7377c138a95b.service @10.648s +44ms
>                               └─dev-mapper-luks\x2d18c56783\x2d809e\x2d43cd\x2db687\x2d7377c138a95b.device @3.332s +7.314s

I have noticed that it takes about 15 seconds after I give the disk password for the grub menu to come. So yes the encryption must slow the start. And since the swap is also encrypted on a separate partition, it must take about the same time to decrypt. But isn't systemd supposed to do this stuff in parallel ?

The network seems to take a long time to start too. I have a good rooter and a fast enough internet. I don't have any idea why it would be so long to start. My laptop is connected on wire but connman connect with the wifi too. Could that be a problem ?

Regards,
BT

#5

According to that output, you reach the login screen 21 seconds after the kernel loads. That seems pretty reasonable?

This is a known issue with GRUB.

Not sure if this is part of the same issue of a "slowwwww boot" or something tangential?

#6

I have rebooted and noticed it was faster than the previous time.
May be my previous last boot did a fsck of the filesystem ? That's why it would be longer.
So may be I have complained too fast !

Anyway than you for your kind help . I didn't know about the "critical-path" analyze it a very usefull report.

Regards,
BT :+1:

1 Like
#7

You could also try disabling your WiFi connection in your bios (if possible).

There is a possibility WiFi could be contributing to your delay, so it wouldn't hurt to take it out of the equation if you are only using Ethernet

1 Like
#8

I want to keep the possibility to wander in the house with the laptop!
I have to keep the wifi for that.

Thanks!

2 Likes
#9

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.