Ridiculously long boot time

First a disclaimer/clarification: I’m very very new to OpenSUSE (about 3 weeks) and relatively new to rolling-release distros (about 3 months), but I have some extensive experience with CentOS and Ubuntu.

Now to my issue:
Some weeks ago after a fresh install of Tumbleweed, I realized that the boot time is long (about 4 to 5 times longer than Arch. two weeks ago the boot time took more than 11 minutes and i have been suggested on Freenode’s #SUSE that I’m better off with btrfs, although with help of those kind people we narrowed down the boot time issue of that day to NTP connection that the OpenSUSE wants to make during the boot (to this day I don’t know why on earth you make the boot so much dependent on NTP synchronization!). Last week I format the whole computer, repartitioned again and installed a fresh Tumbleweed and I stuck to the suggestion of IRC people and only and only used zypper dup and YaST GUI for updating. Today I tried to turn on the computer and it took ages until it finally booted. The following is the output of systemd-analyze blame:


➜  ~  systemd-analyze blame
    9min 59.773s chrony-wait.service
    9min 53.629s plymouth-quit-wait.service
          7.854s backup-rpmdb.service
          6.422s NetworkManager-wait-online.service
          3.014s mandb.service
          2.020s logrotate.service
           777ms display-manager.service
           711ms smartd.service
           667ms udisks2.service
           551ms firewalld.service
           485ms apparmor.service
           310ms systemd-udevd.service
           309ms systemd-logind.service
           290ms initrd-switch-root.service
           269ms ModemManager.service
           262ms postfix.service
           244ms upower.service
           209ms systemd-journald.service
           160ms mcelog.service
           120ms user@1000.service
           108ms nscd.service
           108ms systemd-fsck@dev-disk-by\x2duuid-7822e03c\x2d34c3\x2d4c4e\x2daefb\x2db591ac2d12a4.service
           107ms polkit.service
           106ms systemd-journal-flush.service
           104ms kbdsettings.service
           103ms avahi-daemon.service
           102ms initrd-parse-etc.service
            95ms systemd-vconsole-setup.service
            73ms systemd-udev-trigger.service
            61ms home.mount
            41ms auditd.service
            40ms backup-sysconfig.service
            34ms dracut-cmdline.service
            33ms dev-disk-by\x2duuid-4641137e\x2d8518\x2d479d\x2d9a22\x2d3dad48cb1d14.swap
            32ms NetworkManager.service
            26ms rstudio-server.service
            25ms chronyd.service
            25ms plymouth-switch-root.service
            23ms systemd-tmpfiles-setup.service
            20ms iscsid.service
            19ms systemd-update-utmp.service
            18ms dracut-pre-udev.service
            18ms plymouth-start.service
            17ms systemd-tmpfiles-setup-dev.service
            16ms systemd-fsck-root.service
            14ms initrd-cleanup.service
            13ms plymouth-read-write.service
            12ms systemd-tmpfiles-clean.service
            11ms issue-generator.service
            11ms iscsi.service
             9ms systemd-sysctl.service
             9ms sys-kernel-debug.mount
             8ms systemd-modules-load.service
             8ms kmod-static-nodes.service
             8ms systemd-remount-fs.service
             8ms user-runtime-dir@1000.service
             7ms sysroot.mount
             6ms dev-mqueue.mount
             5ms systemd-update-utmp-runlevel.service
             5ms sys-fs-fuse-connections.mount
             4ms systemd-user-sessions.service
             4ms dev-hugepages.mount
             4ms rtkit-daemon.service
             4ms sound-extra.service

My question: What should I do to prevent OpenSUSE to check ANYTHING FROM NETWORK IN ANY FORM during the boot time?!

P.S: when I had the NTP problem, I added some more responsive (compared to OpenSUSE’s defult one) NTP servers to the mix and continues with the same OS for few days to monitor the improvement/change. It clearly got improved, but still is a bottleneck in the whole boot. Also I would like to emphasis that what if the DNS server is down and the OS cannot resolve the names or NTP and other services? Isn’t that a very very very fragile linkage OpebSUSE has in the chain or boot?

There is an earlier thread about this:
Really really strange openSuse booting problem

That might be worth reading. I think there is also an open bug report on the issue.

The bug report is 1145193 – activating chrony-wait.service by default delays booting without network for 10 minutes

I disabled chrony-wait

systemctl disable chrony-wait.service

and changed “/etc/chrony.conf” from “makestep 1.0 3” to “makestep 0.1 1”,
which seemingly accomplishes the same thing as the chrony-wait service, but with no delay.

https://chrony.tuxfamily.org/doc/3.5/chronyc.html#makestep

I’m still waiting for the developers to address this method, but there have been no apparent problems for general home desktop use.

Another option is “initstepslew”, which is pointed to by the “chrony.conf” makestep documentation, which is slightly different from the link above.

The purpose of the initstepslew directive is to allow chronyd to make a rapid measurement of the system clock error at boot time, and to correct the system clock by stepping before normal operation begins. Since this would normally be performed only at an appropriate point in the system boot sequence, no other software should be adversely affected by the step.

If the correction required is less than a specified threshold, a slew is used instead. This makes it safer to restart chronyd whilst the system is in normal operation.

The initstepslew directive takes a threshold and a list of NTP servers as arguments. Each of the servers is rapidly polled several times, and a majority voting mechanism used to find the most likely range of system clock error that is present. A step or slew is applied to the system clock to correct this error. chronyd then enters its normal operating mode.

Edit: The short direct answer to your question is “Disable the chrony-wait service.”