Raspi are heavily depending on the kind of 'hard disk' you are using, whether it is a SD card (connected via USB2) or an internal SSD Here is the result of a Raspi using a Leap 15 LXQT image: /home/test # systemd-analyze blame 1min 30.071s display-manager.service 1min 18.481s backup-rpmdb.service 14.815s ca-certificates.service 13.788s postfix.service 12.885s btrfsmaintenance-refresh.service 11.001s apparmor.service 10.121s logrotate.service 9.277s backup-sysconfig.service 7.925s ModemManager.service 7.755s lvm2-monitor.service 5.889s NetworkManager.service 5.086s postgresql.service 4.790s initrd-switch-root.service 3.074s systemd-journal-flush.service 2.868s nscd.service 2.721s kbdsettings.service 2.672s sshd.service 2.316s ntpd.service 2.191s avahi-daemon.service 2.153s systemd-udevd.service 1.967s polkit.service 1.959s user(a)1000.service 1.299s systemd-tmpfiles-setup-dev.service 1.171s systemd-remount-fs.service 1.095s sys-kernel-debug.mount 943ms systemd-logind.service 920ms upower.service 803ms wpa_supplicant.service 789ms dev-mqueue.mount 736ms dev-hugepages.mount 715ms boot-efi.mount 598ms udisks2.service 493ms systemd-journald.service 482ms initrd-parse-etc.service 440ms systemd-udev-trigger.service 436ms systemd-modules-load.service 435ms auditd.service 403ms dracut-cmdline.service 348ms systemd-random-seed.service 251ms initrd-cleanup.service 250ms systemd-tmpfiles-setup.service 247ms systemd-sysctl.service 210ms systemd-update-utmp-runlevel.service 207ms dev-disk-by\x2duuid-d90960ec\x2df373\x2d472d\x2d8b3f\x2d27a48d232d7a.swap 193ms systemd-fsck-root.service 184ms plymouth-switch-root.service 170ms sysroot.mount 166ms sys-fs-fuse-connections.mount 159ms systemd-user-sessions.service 151ms kmod-static-nodes.service 112ms systemd-rfkill.service 98ms plymouth-quit.service 97ms plymouth-read-write.service 85ms systemd-vconsole-setup.service 76ms rtkit-daemon.service 60ms dracut-shutdown.service 51ms check-battery.service 51ms systemd-update-utmp.service 21ms initrd-udevadm-cleanup-db.service 18ms sys-kernel-config.mount 16ms plymouth-quit-wait.service Quite strange, btrfsmaintenance and lvm2-monitor enabled, although both are not used. Clearly most time is burned on display-manager and backup of the rpm-db (could this not be moved to a systemd-timer triggered event at a later point in time?) Cheers Axel -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

On 25.01.19 19:59, Bruno Friedmann wrote: I can confirm that the openSUSE boot times on a Raspi 3 are horrendous for several reasons. I tested and tweaked the unstable tumbleweed images, so take it with precaution, Leap might behave different: * It takes quite some time until even grub2 is loaded (u-boot uefi chainload), but it brings a full grub2 with options to load different kernels or even distributions. (So for me this is worth the wait) * It takes quite along time until the handover (uboot, uefi -> kernel) is done: + u-boot slow at reading the actual files (kernel+initrd) + a not compressed kernel image (~24MB uncompressed vs ~8MB compressed) + a initrd which ships (even after first installation and "mkinitrd") several kiwi components * Always triggered backup-*.timer(s) and mandb-timer So to cut boot times idid several things: * remove all kiwi packages -> smaller initrd file * disable the above mentioned triggers -> this might not be applicable on a intended stable system * create and use a kernel with a compressed instead of an uncompressed kernel image [1]. With all this done boot times on my raspi 3 from a slow SD card were cut by around a half (to multi-user console login screen). [1]: https://build.opensuse.org/package/show/home:tobijk:kernel/kernel-default Greetings, Tobias -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

On Thu, 24 Jan 2019 at 11:03, Matthias Brugger <mbrugger(a)suse.com> wrote: First, a non-Rpi 3 aside The biggest hindrance to openSUSE boot times generally was in the past wicked and the way it honours /etc/sysconfig/network WAIT_FOR_INTERFACES and it's default value of "30" For many users unfortunate enough to not have BOTH a working IPv4 AND IPv6 network stack, this means wicked waits 30 seconds, because both of them are mandatory Knocking that down to a much lower number makes boots really fast, but with the obvious caveat that you increase the risk that you boot fast, but network-bound services don't work right. I feel wickeds current behaviour makes perfect sense for servers, but not for desktops. Which is why I changed the desktop system roles in TW and Leap 15.1 to _always_ use NetworkManager now, instead of the previous behaviour of using NetworkManager if we detected you were using a Laptop. NetworkManager doesn't wait for interfaces to work, which is great for fast booting, as long as you don't have any services that need a network. Therefore I would like to consider this long-standing gripe 'solved', and would appreciate it if people broadly communicate the changes made in this area. Please spread the word so we have less of those complaints in the future. Now back to the Rpi 3 On the first boot, our Rpi images do significantly more work than the Debian ones, having to extend the root filesystem to fill the entirety of the SDcard This can take a while on a Rpi It only happens on the first boot of a system after freshly imaging an SDcard - once that is done, I find that my RPis boot faster with openSUSE than any other distro. Looking into ways of speeding things up on that firstboot or alternative approaches are a nice green field for contributions if anyone wishes to tackle this problem. Guillaume (CC'd), as our resident ARM expert, might have some ideas -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org