I just upgraded from v. 12.3 to v. 13.1 (64-bit) using the DVD method.
There is a long pause after I make my selection in the GRUB2 screen and before the appearance of the login screen. The pause is about 70 seconds! This problem already existed when I had v. 12.3 installed, and I just decided to put a stop to this.
Any ideas as to what could be causing such a long delay?
Install the package “systemd-analyze” if needed and have a look at the output of:
systemd-analyze blame
You can see then what service takes so long to start.
Do I have to add a special repository for downloading systemd-analyze? YaST2 → Software Management does not find it…
Should be in the regular repos. It may be part of another package so in search tick the box for provides
sometimes, as soon as you have started the boot process from grub, hit Esc.
you see boot messages, you may see the delay and message associated with it
Got it! It is part of the “systemd” package.
this is the output of systemd-analyze blame:
# systemd-analyze blame
21.916s network.service
20.843s network@eth0.service
2.359s ntp.service
2.134s systemd-udev-root-symlink.service
2.124s cycle.service
2.026s lvm2-activation-early.service
1.832s kmod-static-nodes.service
1.443s systemd-vconsole-setup.service
1.185s systemd-modules-load.service
1.144s systemd-remount-fs.service
1.000s plymouth-start.service
889ms systemd-udev-settle.service
788ms systemd-tmpfiles-setup.service
626ms systemd-readahead-replay.service
625ms systemd-readahead-collect.service
624ms dev-hugepages.mount
623ms dev-mqueue.mount
623ms sys-kernel-debug.mount
546ms lvm2-activation.service
528ms systemd-fsck@dev-disk-by\x2did-ata\x2dST3500320AS_9QMAETGT\x2dpart3.service
527ms ModemManager.service
505ms avahi-daemon.service
370ms console-kit-log-system-start.service
370ms alsa-restore.service
323ms user@1000.service
304ms polkit.service
294ms bluetooth.service
270ms irq_balancer.service
231ms systemd-hostnamed.service
219ms plymouth-read-write.service
196ms apparmor.service
180ms NetworkManager-dispatcher.service
166ms systemd-logind.service
132ms rsyslog.service
129ms rpcbind.service
107ms xdm.service
107ms wpa_supplicant.service
83ms systemd-random-seed.service
67ms systemd-sysctl.service
53ms home.mount
50ms console-kit-daemon.service
32ms systemd-tmpfiles-setup-dev.service
29ms rtkit-daemon.service
26ms udisks2.service
14ms systemd-udev-trigger.service
5ms dev-disk-by\x2did-ata\x2dST3500320AS_9QMAETGT\x2dpart1.swap
4ms upower.service
4ms systemd-update-utmp.service
4ms systemd-user-sessions.service
4ms rc-local.service
3ms systemd-journal-flush.service
3ms sys-fs-fuse-connections.mount
2ms systemd-update-utmp-runlevel.service
2ms var-run.mount
2ms systemd-readahead-done.service
1ms systemd-udevd.service
1ms var-lock.mount
I am not much of an expert but there seems to be a problem with the network service. Any suggestions as to how to rectify the problem?
I’d suggest using kde’s network manager
try adding the loopback https://dl.dropboxusercontent.com/u/10573557/All_Network/Hostname.png
also disable IPv6
reboot
Yes, sorry.
In 12.3 it was an extra package…
Both the change hostname and assign hostname options are already checked.
AFAIK the above indicates ntp as the cause of the delay (my 2 cents)
Thanks for this. This is very cool.
yes traditional network makes this happen
switch to networkmanager solved for me on 5 pc’s.
And how did you do that? The suggestion by caf4926 did not bring anything new as I already have Change Hostname and Assign Hostname selected…
YaST->Network Devices->Network Settings->Global Options
Okay, I’ve gone there and selected User Controlled With NetworkManager. Added the appropriate widget to the panel. Rebooted. It did not make an iota of difference…
Just throwing this out. Since this is an upgrade could it have to do with the change of naming of the Net devices? Maybe some config (which does not change on an upgrade) may still use the old names and there is a timeout due to not finding the new before looking for the old.
Check the net cards in Yast and see if you are some new device names. If so edit the new one(s) and to point to the card/chip and remove the old
See the release doc for more info on the name convention change
