Results 1 to 8 of 8

Thread: Slow boot times caused by 'initrd'

  1. #1
    Join Date
    Jul 2018
    Posts
    2

    Default Slow boot times caused by 'initrd'

    I have recently installed Tumbleweed on an Ideapad 110 and get slow boot times of around 2 minutes 10 seconds according to systemd-analyze. The slowest processes in systemd-analyze blame are around 6 seconds, but if I create the graphical svg then it shows 'initrd' is taking over a minute to boot.


    Why is this and what can I do to speed it up?

    Apologies for the large image, I can upload the svg file if that would be useful.

    Any help would be appreciated.

  2. #2

    Default Re: Slow boot times caused by 'initrd'

    Post the command
    Code:
    systemd-analyze blame
    I do not have enough view to read what is written on that screen you posted
    ------------------------------------
    Correct me if I'm wrong .
    ------------------------------------

  3. #3
    Join Date
    Jul 2018
    Posts
    2

    Default Re: Slow boot times caused by 'initrd'

    Quote Originally Posted by enziosavio View Post
    Post the command
    Code:
    systemd-analyze blame
    I do not have enough view to read what is written on that screen you posted
    Here is the result of systemd-analyze blame

    6.350s firewalld.service
    6.253s ca-certificates.service
    6.220s btrfsmaintenance-refresh.service
    4.118s initrd-switch-root.service
    3.836s display-manager.service
    3.495s ModemManager.service
    3.176s apparmor.service
    2.960s plymouth-quit-wait.service
    2.834s postfix.service
    2.367s home.mount
    1.592s boot-efi.mount
    1.523s polkit.service
    1.103s dev-disk-by\x2duuid-3b2dcaf2\x2d12f5\x2d4b88\x2da4f7\x2ddbfc72c47cff.swap
    1.094s avahi-daemon.service
    1.078s systemd-udevd.service
    1.038s nscd.service
    783ms kbdsettings.service
    776ms NetworkManager.service
    774ms udisks2.service
    738ms upower.service
    699ms sysroot.mount
    529ms systemd-remount-fs.service
    498ms sys-kernel-debug.mount
    491ms boot-grub2-x86_64\x2defi.mount
    489ms dev-hugepages.mount
    488ms usr-local.mount
    487ms dev-mqueue.mount
    485ms var.mount
    482ms boot-grub2-i386\x2dpc.mount
    475ms srv.mount
    468ms opt.mount
    466ms root.mount
    463ms tmp.mount
    454ms plymouth-start.service
    440ms systemd-logind.service
    419ms bluetooth.service
    407ms rtkit-daemon.service
    352ms systemd-udev-trigger.service
    289ms initrd-parse-etc.service
    254ms systemd-journal-flush.service
    231ms systemd-modules-load.service
    218ms auditd.service
    209ms systemd-journald.service
    208ms iscsi.service
    183ms systemd-tmpfiles-setup-dev.service
    158ms user@1000.service
    151ms systemd-tmpfiles-setup.service
    144ms dracut-cmdline.service
    126ms systemd-backlight@backlight:intel_backlight.service
    115ms plymouth-read-write.service
    113ms systemd-random-seed.service
    101ms wpa_supplicant.service
    99ms systemd-fsck-root.service
    93ms systemd-sysctl.service
    78ms systemd-tmpfiles-clean.service
    46ms systemd-update-utmp.service
    35ms systemd-user-sessions.service
    35ms dracut-pre-trigger.service
    34ms initrd-cleanup.service
    33ms systemd-vconsole-setup.service
    33ms sys-fs-fuse-connections.mount
    20ms dracut-shutdown.service
    19ms \x2esnapshots.mount
    19ms kmod-static-nodes.service
    18ms mcelog.service
    18ms systemd-update-utmp-runlevel.service
    13ms initrd-udevadm-cleanup-db.service
    13ms plymouth-switch-root.service
    11ms systemd-rfkill.service

    This is the result from just systemd-analyze

    Startup finished in 4.390s (firmware) + 12.413s (loader) + 4.524s (kernel) + 1min 33.079s (initrd) + 22.920s (userspace) = 2min 17.328s
    graphical.target reached after 22.894s in userspace

  4. #4
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    1,478

    Default Re: Slow boot times caused by 'initrd'

    Quote Originally Posted by enziosavio View Post
    I do not have enough view to read what is written on that screen you posted
    Right click on the image and select view image. With only the image loaded it should either automatically resize to your window, or you should be able to click the image to toggle it between full size and shrunk to fit your window.

    This delay sounds like one I have on some installations that I've never found a solution for:
    https://www.linuxquestions.org/quest...em-4175599620/
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 42.3,TW,15.0 & 13.1 on Haswell w/ RAID
    Secondary: eComStation (OS/2)&42.3 on 965P/Radeon
    Tertiary: TW,15.0,42.3,Fedora,Debian,more on Kaby Lake,Q45,Q43,G41,G3X,965G,Cedar,Caicos,Oland,GT218&&&

  5. #5
    Join Date
    Jan 2017
    Location
    Nürnberg, Germany
    Posts
    142

    Default Re: Slow boot times caused by 'initrd'

    Quote Originally Posted by FT View Post
    Why is this and what can I do to speed it up?
    Try looking for any initrd-related messages:
    Code:
    journalctl -b | grep -i initrd
    My output, for example:
    Code:
    Aug 05 07:01:56 rig kernel: Freeing initrd memory: 17416K
    Aug 05 07:01:57 rig systemd[1]: Reached target Initrd Root Device.
    Aug 05 07:01:57 rig systemd[1]: Reached target Initrd Root File System.
    Aug 05 07:01:57 rig systemd[1]: Reached target Initrd File Systems.
    Aug 05 07:01:57 rig systemd[1]: Reached target Initrd Default Target.
    Aug 05 07:01:57 rig systemd[1]: Stopped target Initrd Default Target.
    Aug 05 07:01:57 rig systemd[1]: Stopped target Initrd Root Device.
    Aug 05 07:01:58 rig systemd[1]: Startup finished in 1.347s (kernel) + 878ms (initrd) + 632ms (userspace) = 2.858s.
    It could be further worthwile to have a closer look at the kernel messages that occured during the relevant time interval (07:01:56 to 07:01:58 in my case):
    Code:
    dmesg -dT
    What does your kernel report during that critical time? Looking forward to your posts.



    As you guys are interested in short boot times, so have I been from the time on I built my first Linux rig with an actual SSD. I managed to achieve boots in under 2.2s until a few months ago when those Meltdown and Spectre patches added over a second to my openSUSE Leap 42.3 boot times. Now upgraded to Leap 15.0, I’m just under 3 seconds. Here are the speed boosts I’ve used:


    • use a fast SSD (I still think this may been the greatest improvement to any system with moderate mass storage requirements)
    • use one common ext4 boot+root partition (I have no use for btrfs)
    • use one swap partition (I dabbled with swap-less systems, had problems hibernating though)
    • if SSD-based, use partitions strictly aligned to SSD memory blocks (mind those 2048KiB boundaries — good for speed and good for SSD health)
    • disable Plymouth (unnecessary eye candy)
    • disable AppArmor (arguably no evidence of additional security)
    • use kdm as a display manager (fastest initialisation time compared to gdm and sddm)
    • use exim (postfix takes a while to initialize)
    • use NetworkManager (I don’t need wicked’s complexity and slow boot-time initialisations)
    • disable SuSEfirewall and other iptables-based filters if you have a separate firewall
    • in YaST’s »Services Manager«, disable as many services as you are comfortable with, for example smartd, ModemManager, iscsi, nmb+Samba and — again — Plymouth.
    • customize your initrd with dracut, e.g. issuing as root user something like:
      Code:
      dracut --hostonly --force --omit "img-lib cifs fcoe fcoe-uefi multipath iscsi qemu lvm mdraid dm dmraid pollcdrom plymouth btrfs"
      (caution! Your needs may differ from mine)
    • make the kernel just write warnings or errors during boot onto the screen, nothing else; relevant kernel parameters:
      Code:
      loglevel=4 systemd.show_status=auto


    My current outputs of »systemd-analyze blame« …
    Code:
               712ms dev-sda1.device
               176ms initrd-switch-root.service
               120ms systemd-journal-flush.service
               114ms upower.service
               110ms display-manager.service
                88ms NetworkManager.service
                77ms systemd-udevd.service
                76ms polkit.service
                60ms systemd-tmpfiles-clean.service
                48ms initrd-parse-etc.service
                40ms systemd-tmpfiles-setup.service
                33ms backup-sysconfig.service
                32ms systemd-udev-trigger.service
                29ms dracut-cmdline.service
                28ms klog.service
                28ms systemd-update-utmp.service
                24ms systemd-tmpfiles-setup-dev.service
                23ms user@1000.service
                22ms logrotate.service
                17ms rtkit-daemon.service
                17ms initrd-cleanup.service
                16ms udisks2.service
                13ms sys-kernel-debug.mount
                12ms dev-hugepages.mount
                12ms systemd-fsck-root.service
                12ms dev-mqueue.mount
                10ms systemd-remount-fs.service
                10ms check-battery.service
                 9ms systemd-sysctl.service
                 8ms dracut-pre-trigger.service
                 7ms sysroot.mount
                 7ms systemd-logind.service
                 6ms dev-disk-by\x2duuid-f4481d3c\x2d1a74\x2d40a7\x2d9cb2\x2dda5e32db08ff.swap
                 5ms systemd-user-sessions.service
                 5ms systemd-journald.service
                 4ms kmod-static-nodes.service
                 4ms systemd-update-utmp-runlevel.service
                 4ms dracut-shutdown.service
                 4ms systemd-modules-load.service
                 3ms systemd-random-seed.service
                 1ms initrd-udevadm-cleanup-db.service
    … and of »systemd-analyze critical-chain«:
    Code:
    graphical.target @621ms
    └─display-manager.service @510ms +110ms
      └─systemd-user-sessions.service @504ms +5ms
        └─network.target @503ms
          └─NetworkManager.service @414ms +88ms
            └─dbus.service @384ms
              └─basic.target @384ms
                └─sockets.target @384ms
                  └─iscsid.socket @384ms
                    └─sysinit.target @383ms
                      └─swap.target @383ms
                        └─dev-disk-by\x2duuid-f4481d3c\x2d1a74\x2d40a7\x2d9cb2\x2dda5e32db08ff.swap @376ms +6ms
                          └─dev-disk-by\x2duuid-f4481d3c\x2d1a74\x2d40a7\x2d9cb2\x2dda5e32db08ff.device @374m
    Caveats: I am sure this list is incomplete and I’ve forgot something. Will post any further tricks I might remember here. Obviously, some of my »improvements« are a bit more tricky and dangerous as others, so you should experiment with a fresh installation where no personal data is in danger.

    Happy optimizing!

  6. #6
    Join Date
    Jan 2017
    Location
    Nürnberg, Germany
    Posts
    142

    Default Re: Slow boot times caused by 'initrd'

    After the update of my NVidia drivers (to version 390.87) and an unoptimized initrd generation with dracut (an automated procedure, probably triggered by a postinstall script) I retract my recommendation about »dracut --hostonly --force --omit …« because it doesn’t seem to matter much. I get boot times between 2.8s and 3.1s either way.

    Here’s my boot chart from this afternoon:


  7. #7
    Join Date
    Jan 2017
    Location
    Nürnberg, Germany
    Posts
    142

    Default Re: Slow boot times caused by 'initrd'

    Booting the standard kernel with uncompressed (instead of per-default compressed) initrd improved my boot time from 2.727s this morning down to a mere 1.757s just now.
    Here’s what I did:
    • stumbled over the talk »A Pragmatic Guide to Boot-Time Optimization« by Chris Simmonds on YouTube — https://youtu.be/gIK1he6Ocpg — wherein he mentioned »bootgraph«.
    • added following boot options to the kernel:
      • printk.time=1
      • initcall_debug

    • rebooted my openSUSE Leap 15.0 install. Then, typed the following in xterm (use the CLI of your choice):
    • dmesg | perl /usr/src/linux-4.12.14-lp150.12.16/scripts/bootgraph.pl > ~/Desktop/bootgraph0.svg (your kernel version may vary; for the perl script to exist, install the kernel-default-devel package, i.e. the kernel sources.)
    • noticed that, during boot, my kernel spends most of its time executing the populate_rootfs() call — within it, over a second for decompressing and executing stuff in initrd (see screenshot beneath)
    • built an uncompressed, customized version of your initrd image. As root user, issue a command like this:
      dracut --hostonly --force --no-compress --omit "img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid pollcdrom plymouth"
      (your list of unnecessary modules to be omitted may vary.)
    • rebooted again. Invoked the dmesg+bootgraph line with bootgraph1.svg instead of bootgraph0.svg:
    • dmesg | perl /usr/src/linux-4.12.14-lp150.12.16/scripts/bootgraph.pl > ~/Desktop/bootgraph1.svg
    • compared the two SVG files in a web browser (Chromium, because SeaMonkey can’t scale SVGs; funny because of what the »S« in »SVG« stands for).


    The result:



    As you can see, the kernel now finishes populate_rootfs() in about 0.1s.
    Here are the systemd-analyze times compared:


    • Startup finished in 1.363s (kernel) + 729ms (initrd) + 634ms (userspace) = 2.727s (compressed standard initrd image)
    • Startup finished in 239ms (kernel) + 748ms (initrd) + 770ms (userspace) = 1.757s (uncompressed custom initrd image)


    The nice thing: regardless of initrd compression, the kernel automatically does the right thing with the initrd image.
    For completeness, here is the corresponding diagram generated by systemd-analyze plot:

  8. #8
    Join Date
    Jan 2017
    Location
    Nürnberg, Germany
    Posts
    142

    Talking Re: Slow boot times caused by 'initrd'

    Small update.
    In part due to luck and in part due to more deactivated systemd services, my new personal best boot time is now 1.419s:
    Code:
    rig:~ ▶ systemd-analyze
    Startup finished in 211ms (kernel) + 704ms (initrd) + 503ms (userspace) = 1.419s
    rig:~ ▶ systemd-analyze critical-chain
    The time after the unit is active or started is printed after the "@" character.
    The time the unit takes to start is printed after the "+" character.
    
    graphical.target @500ms
    └─display-manager.service @428ms +71ms
      └─systemd-user-sessions.service @425ms +2ms
        └─network.target @424ms
          └─NetworkManager.service @332ms +91ms
            └─dbus.service @284ms
              └─basic.target @282ms
                └─sockets.target @282ms
                  └─dbus.socket @282ms
                    └─sysinit.target @280ms
                      └─swap.target @280ms
                        └─dev-disk-by\x2duuid-f4481d3c\x2d1a74\x2d40a7\x2d9cb2\x2dda5e32db08ff.swap @275ms +5ms
                          └─dev-disk-by\x2duuid-f4481d3c\x2d1a74\x2d40a7\x2d9cb2\x2dda5e32db08ff.device @274ms
    rig:~ ▶ _
    Again, the times of several services just happened to be short on this boot, on average it’s more like 1.6s to 1.7s (power button → BIOS → grub2 → kernel + initrd → KDM → KDE/Plasma5). If the stars align correctly, boot times under 1.4s should be possible with my Core i5-4670 and SATA-SSD. (For example, during other boots NetworkManager.service was able to start in 78ms instead of the above 91ms, and so on.) Who knows what a fast Ryzen or i9 with a M.2 SSD could do…

    Further optimisations for my initial RAM disk are probably a big part of this good result. My dracut command line is currently:
    dracut --verbose --hostonly --force --no-compress --omit "img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid cdrom pollcdrom plymouth btrfs wacom convertfs wicked ipv6 mtp-probe"

    So long for 2018, forum. Keep having fun, and all the best for 2019.
    Cheers!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •