Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: Boot Times are too High

  1. #11

    Default Re: Boot Times are too High

    and for now I removed these:
    Code:
    pla-3-TW:/home/pla # systemctl disable btrfsmaintenance-refresh.service
    Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.path.
    Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service.
    pla-3-TW:/home/pla # systemctl disable ModemManager.service
    Removed /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service.
    Removed /etc/systemd/system/multi-user.target.wants/ModemManager.service.
    pla-3-TW:/home/pla # systemctl disable apparmor.service
    Removed /etc/systemd/system/multi-user.target.wants/apparmor.service.
    pla-3-TW:/home/pla #

  2. #12
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    24,975
    Blog Entries
    15

    Default Re: Boot Times are too High

    Quote Originally Posted by pier_andreit View Post
    and for now I removed these:
    Code:
    pla-3-TW:/home/pla # systemctl disable btrfsmaintenance-refresh.service
    Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.path.
    Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service.
    pla-3-TW:/home/pla # systemctl disable ModemManager.service
    Removed /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service.
    Removed /etc/systemd/system/multi-user.target.wants/ModemManager.service.
    pla-3-TW:/home/pla # systemctl disable apparmor.service
    Removed /etc/systemd/system/multi-user.target.wants/apparmor.service.
    pla-3-TW:/home/pla #
    Hi
    Check on the next boot, if they come back, then mask as well....
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  3. #13

    Default Re: Boot Times are too High

    Quote Originally Posted by pier_andreit View Post
    and for now I removed these:
    Code:
    pla-3-TW:/home/pla # systemctl disable btrfsmaintenance-refresh.service
    Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.path.
    Removed /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service.
    pla-3-TW:/home/pla # systemctl disable ModemManager.service
    Removed /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service.
    Removed /etc/systemd/system/multi-user.target.wants/ModemManager.service.
    pla-3-TW:/home/pla # systemctl disable apparmor.service
    Removed /etc/systemd/system/multi-user.target.wants/apparmor.service.
    pla-3-TW:/home/pla #
    Apparmor is a kernel security module - I wouldn't disable that.

  4. #14

    Default Re: Boot Times are too High

    Quote Originally Posted by fuerstu View Post
    Apparmor is a kernel security module - I wouldn't disable that.
    manythanks, I did this:
    Code:
    pla@pla-3-TW:~> su
    Password: 
    pla-3-TW:/home/pla # systemctl enable apparmor.service
    Created symlink /etc/systemd/system/multi-user.target.wants/apparmor.service → /usr/lib/systemd/system/apparmor.service.
    pla-3-TW:/home/pla #

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

    Default Re: Boot Times are too High

    Today my Leap-15.0-based main rig managed to boot in 1.488 seconds, a new personal record. It was a warm boot into KDE, which is one contributing factor amongst many others. My rig is a self-built Core-i5/ASUS/Samsung-SSD box, nothing special.

    Code:
    ▶ systemd-analyze blame
    
               468ms dev-sda1.device
               164ms initrd-switch-root.service
               111ms upower.service
               108ms display-manager.service
                94ms systemd-journal-flush.service
                80ms NetworkManager.service
                73ms systemd-udevd.service
                67ms polkit.service
                55ms systemd-logind.service
                42ms klog.service
                40ms initrd-parse-etc.service
                34ms systemd-tmpfiles-clean.service
                34ms systemd-udev-trigger.service
                29ms dracut-cmdline.service
                21ms user@1000.service
                19ms initrd-cleanup.service
                19ms systemd-update-utmp.service
                15ms udisks2.service
                15ms systemd-tmpfiles-setup.service
                14ms systemd-tmpfiles-setup-dev.service
                13ms dev-mqueue.mount
                12ms systemd-remount-fs.service
                12ms dev-hugepages.mount
                11ms sys-kernel-debug.mount
                10ms systemd-fsck-root.service
                10ms systemd-sysctl.service
                 7ms dracut-pre-trigger.service
                 6ms sysroot.mount
                 6ms rtkit-daemon.service
                 5ms systemd-journald.service
                 5ms dev-...f.swap
                 4ms systemd-random-seed.service
                 4ms dracut-shutdown.service
                 3ms systemd-update-utmp-runlevel.service
                 2ms systemd-modules-load.service
                 2ms systemd-user-sessions.service
                 2ms kmod-static-nodes.service
                 1ms initrd-udevadm-cleanup-db.service
    
    ▶ systemd-analyze
    
    Startup finished in 237ms (kernel) + 724ms (initrd) + 526ms (userspace) = 1.488s
    My boot params: loglevel=4 systemd.show_status=auto cgroup_disable=memory ipv6.disable=1 fips=0 resume=/dev/disk/...-part2 elevator=deadline

    I use exim instead of postfix, and KDM instead of SDDM, and NetworkManager instead of wicked, all of those start quicker than their SuSE-standard counterparts.
    I also generate a custom, uncompressed initial ramdisk using dracut by tinkering with the following lines in my /etc/dracut.conf.d/01-rig-m.conf:
    Code:
    hostonly="yes"
    omit_dracutmodules+="img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid pollcdrom plymouth btrfs wacom convertfs"
    omit_drivers+="hid-wiimote wacom hv_vmbus rmi_core dm-mod iscsi_if iscsi_tcp dm_multipath parport pcmcia jsm"
    Alternatively, I use variants of the following command (your mileage may vary):
    dracut --hostonly --force --no-compress --omit "img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid pollcdrom plymouth btrfs wacom convertfs"

    I’ve been avoiding EFI boots for 5 years, and I use one large ext4 partition for '/' (i.e., everything but swap). Cheers!

  6. #16
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    526

    Default Re: Boot Times are too High

    Quote Originally Posted by unix111 View Post
    Today my Leap-15.0-based main rig managed to boot in 1.488 seconds, a new personal record. It was a warm boot into KDE, which is one contributing factor amongst many others.
    How do you perform warm boot?

    My rig is a self-built Core-i5/ASUS/Samsung-SSD box, nothing special.
    Would you mind posting output of: inxi -zF

    I use exim instead of postfix, and KDM instead of SDDM, and NetworkManager instead of wicked, all of those start quicker than their SuSE-standard counterparts.
    I am quite happy with postfix, sddm, wicked and others.

    I’ve been avoiding EFI boots for 5 years
    Any comment on: https://wiki.debian.org/BootProcessSpeedup Use Linux Kernel as bootloader: On a system which has UEFI , you can bypass all traditional bootloaders(like Grub,Lilo,syslinux etc) and make the UEFI boot the kernel.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), openSUSE Tumbleweed, KDE Plasma 5

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

    Default Re: Boot Times are too High

    Quote Originally Posted by karlmistelberger View Post
    How do you perform warm boot?
    Reboot or linger a few seconds in the BIOS or the GRUB CLI — that way, CPU caches, instuction pipelines etc seem to have had enough time to fill or get up to speed, and boot times tend to be a few milliseconds faster. Just some thing I noticed.

    Would you mind posting output of: inxi -zF
    Here you go (copy-pasted from xterm):
    Code:
    System:    Host: rig Kernel: 4.12.14-lp150.12.25-default x86_64 bits: 64 Desktop: KDE Plasma 5.12.6
               Distro: openSUSE Leap 15.0
    Machine:   Device: desktop System: ASUS product: All Series serial: N/A
               Mobo: ASUSTeK model: H87I-PLUS v: Rev X.0x serial: N/A
               BIOS: American Megatrends v: 2003 date: 11/05/2014
    Battery    hidpp__0: charge: N/A condition: NA/NA Wh
    CPU:       Quad core Intel Core i5-4670 (-MCP-) cache: 6144 KB
               clock speeds: max: 3800 MHz 1: 3400 MHz 2: 3400 MHz 3: 3400 MHz 4: 3400 MHz
    Graphics:  Card: NVIDIA GP107 [GeForce GTX 1050]
               Display Server: X.Org 1.19.6 driver: nvidia Resolution: 1920x1200@59.95hz
               OpenGL: renderer: GeForce GTX 1050/PCIe/SSE2 version: 4.5.0 NVIDIA 390.87
    Audio:     Card-1 Intel 8 Series/C220 Series High Definition Audio Controller driver: snd_hda_intel
               Card-2 NVIDIA GP107GL High Definition Audio Controller driver: snd_hda_intel
               Sound: Advanced Linux Sound Architecture v: k4.12.14-lp150.12.25-default
    Network:   Card: Intel Ethernet Connection I217-V driver: e1000e
               IF: eth0 state: up speed: 100 Mbps duplex: full mac: <filter>
    Drives:    HDD Total Size: 376.1GB (40.3% used)
               ID-1: /dev/sda model: Samsung_SSD_850 size: 250.1GB
               ID-2: /dev/sdb model: SanDisk_SDSSDP12 size: 126.0GB
    Partition: ID-1: / size: 230G used: 134G (59%) fs: ext4 dev: /dev/sda1
               ID-2: swap-1 size: 8.61GB used: 0.00GB (0%) fs: swap dev: /dev/sdb2
    Sensors:   System Temperatures: cpu: 55.0C mobo: N/A gpu: 32C
               Fan Speeds (in rpm): cpu: 0
    Info:      Processes: 144 Uptime: 7:27 Memory: 1628.9/7908.9MB Client: Shell (bash) inxi: 2.3.40
    I am quite happy with postfix, sddm, wicked and others.
    How about Plymouth? It’s the first thing I’ve disabled since SuSE has been using it by default.

    I find it reassuring to see that console login for a fraction of a second, and Plymouth tries to cover it up. There is some ongoing development (read it on LKML recently), though, to set the native LCD resolution during early boot and never resetting resolution for text mode nor for display manager nor for the desktop GUI. This should reduce flicker during boot and may also save some time (because Xorg doesn’t have to wait for the graphics hardware to re-initialize), and therefore it might look even prettier and smoother than Plymouth. No idea how this would work with multi-display or multi-head support, though.

    Any comment on: https://wiki.debian.org/BootProcessSpeedup Use Linux Kernel as bootloader: On a system which has UEFI , you can bypass all traditional bootloaders(like Grub,Lilo,syslinux etc) and make the UEFI boot the kernel.
    Bypassing anything during boot sounds great to me. There are several things I’d like to try out as soon as I have some additional x86 hardware to install SuSE on. Hopefully, I’ll obtain a mainboard that’s supported by one of the open-source EFI projects so I can have a completely open boot chain. Although… it’s just a hobby (system optimization) within a hobby (computer stuff), so to speak. So, things could change quicker than I may be able to give them a spin.

    It’s tempting to contemplate my ASUS/AMI BIOS directly bootstrapping kernel+initrd, but I don’t trust closed-source EFI stuff, and I don’t like what knowledgeable hackers had to report about several EFI bugs at conferences. So I still use old-style MBR booting using GRUB2, with single-partition /dev/sda1 on SSD, ext4-formatted — none of that newfangled btrfs rubbish!

    The biggest benefit listed in the Debian page you mentioned is, in my view, good ol’ controversial systemd. I see how UNIX purists dislike aspects of systemd, but I prefer it to the stuff I’ve had to deal with professionally all to often: buggy init scripts inexplicably aborting themselves, disrupting other scripts or halting the whole boot process; then, cron/at variants, all with their own peculiar conf-file syntax, and all too many logging demons (syslog/rsyslog etc). And finally, monitoring and profiling the boot process, which system also does out of the box. I like it. Cheers!

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

    Default Re: Boot Times are too High

    This morning, after installing some dracut/systemd updates, an old vconsole-setup error reared its head again (»systemd-vconsole-setup: loadkeys failed with error code 1«, »cannot open include file compose.latin1«, etc). Having experienced this annoyance several times since openSUSE 42.1 (without an official fix on the horizon yet), a few minutes ago I simply overwrote the original /usr/lib/systemd/systemd-vconsole-setup with /usr/bin/true (i.e., do nothing, return success).

    Not only did this solve my recurring vconsole errors, it also sped up boot times again (well, this and the updates, I reckon) — from 1.490s to 1.455s:

    Code:
    ▶ systemd-analyze
    Startup finished in 229ms (kernel) + 675ms (initrd) + 550ms (userspace) = 1.455s
    
    ▶ 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 @546ms
    └─display-manager.service @442ms +100ms
      └─systemd-user-sessions.service @438ms +3ms
        └─network.target @438ms
          └─NetworkManager.service @350ms +87ms
            └─dbus.service @312ms
              └─basic.target @311ms
                └─sockets.target @311ms
                  └─dbus.socket @311ms
                    └─sysinit.target @310ms
                      └─swap.target @310ms
                        └─dev-disk-by\x2duuid…08ff.swap @305ms +5ms
                          └─dev-disk-by\x2duuid…08ff.device @303ms
     ▶ _
    The funny thing: my text console seems to work the same as before.
    Cheers!

  9. #19
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    526

    Default Re: Boot Times are too High

    Quote Originally Posted by unix111 View Post
    How about Plymouth? It’s the first thing I’ve disabled since SuSE has been using it by default.

    I find it reassuring to see that console login for a fraction of a second, and Plymouth tries to cover it up. There is some ongoing development (read it on LKML recently), though, to set the native LCD resolution during early boot and never resetting resolution for text mode nor for display manager nor for the desktop GUI. This should reduce flicker during boot and may also save some time (because Xorg doesn’t have to wait for the graphics hardware to re-initialize), and therefore it might look even prettier and smoother than Plymouth. No idea how this would work with multi-display or multi-head support, though.
    Code:
    erlangen:~ # inxi -zSM
    System:    Host: erlangen Kernel: 4.19.5-1-default x86_64 bits: 64 Console: tty 0 Distro: openSUSE Tumbleweed 20181206 
    Machine:   Type: Desktop Mobo: ASRock model: Z170 Pro4S serial: <filter> UEFI: American Megatrends v: P3.50 date: 06/23/2016 
    erlangen:~ #
    With Kernel 4.19 there is no flicker. System switches between Plymouth and the ASRock logo.

    The biggest benefit listed in the Debian page you mentioned is, in my view, good ol’ controversial systemd. I see how UNIX purists dislike aspects of systemd, but I prefer it to the stuff I’ve had to deal with professionally all to often: buggy init scripts inexplicably aborting themselves, disrupting other scripts or halting the whole boot process; then, cron/at variants, all with their own peculiar conf-file syntax, and all too many logging demons (syslog/rsyslog etc). And finally, monitoring and profiling the boot process, which system also does out of the box. I like it. Cheers!
    Init scripts were annoying. Systemd is great. I never looked closer into startup until it arrived at openSUSE.

    This morning, after installing some dracut/systemd updates, an old vconsole-setup error reared its head again (»systemd-vconsole-setup: loadkeys failed with error code 1«, »cannot open include file compose.latin1«, etc). Having experienced this annoyance several times since openSUSE 42.1 (without an official fix on the horizon yet), a few minutes ago I simply overwrote the original /usr/lib/systemd/systemd-vconsole-setup with /usr/bin/true (i.e., do nothing, return success).
    Had that too. Removed /etc/vconsole.conf and ran "zypper in --force kbd kbd-legacy dracut systemd": https://forums.opensuse.org/showthread.php/533663-Failed-to-start-Setup-Virtual-Console?p=2886062#post2886062

    Code:
    erlangen:~ # rpm -qf /etc/vconsole.conf
    systemd-239-2.1.x86_64
    erlangen:~ # cat /etc/vconsole.conf 
    KEYMAP=de-nodeadkeys
    FONT=eurlatgr.psfu
    erlangen:~ #
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), openSUSE Tumbleweed, KDE Plasma 5

Page 2 of 2 FirstFirst 12

Posting Permissions

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