Running Tumbleweed from clean install 13.2 DVD and KDE environment. I ran 13.2 for a couple of days before upgrading via repository change as newly documented in the wiki.
I spent part of yesterday and today installing nvidia the hard way - I might add I have never encountered problems like this before but this is not the point of this post - all is well in the NVIDIA world now.
To business. Following advice to anothe user in the install/boot/login forum I have collected this data:
linux-7wnl:~ # 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 @1min 21.461s
└─multi-user.target @1min 21.461s
└─cron.service @1min 21.461s
└─postfix.service @1min 20.740s +719ms
└─network.target @1min 20.739s
└─wicked.service @1min 3.704s +17.034s
└─wickedd-nanny.service @1min 3.698s +4ms
└─wickedd.service @1min 3.693s +3ms
└─wickedd-auto4.service @1min 3.670s +22ms
└─SuSEfirewall2_init.service @26.440s +37.215s
└─basic.target @25.677s
└─timers.target @25.676s
└─systemd-tmpfiles-clean.timer @25.676s
└─sysinit.target @25.676s
└─apparmor.service @22.651s +3.024s
└─systemd-tmpfiles-setup.service @22.447s +203ms
└─local-fs.target @22.442s
└─home.mount @13.324s +9.118s
└─systemd-fsck@dev-disk-by\x2duuid-b9856549\x2d3826\x2d429e\x2da015\x2d716f9fd58e3b.service @13.228s +95ms
└─dev-disk-by\x2duuid-b9856549\x2d3826\x2d429e\x2da015\x2d716f9fd58e3b.device @13.227s
As you can see there are delays.
I would also like to say I have also started in init 3 to try and catch error messages and the following is a very short summary of a waittime in the boot sequence.
a start job is running. 4 of 4 3 of 4 1min 30 secondes (appears to becounting down. then references flicking past about services modem; susefirewall and two others.
I saw nothing in dmesg or /var/log/boot that corresponded to delays and am mightily glad I saw the other post and ran thecommand I have posted above.
If anyone has any advice about sorting out the delays,
I didn’t mean init 3 I meant booting without quiet and splash=silent.
I’d been adding 3 to the linux line most of the day and got confused while writing the post.
Sorry.
Also in the meantime I thought I might ditch ‘wicked’ and fix the broken network widget by Reconfiguring the network in Yast.
That now seems to have stalled the boot sequence big time and I need to just verify that.
I hope I haven’t damaged the current installation beyond repair and have to re-install: one loses the chance to troubleshoot.
Oh thank goodness - rebooted and back in the graphical environment.
I’d better include a new data collection now that I’ve changed the network manager. there are still delays.
I also saw the rest of the ‘start jobs running’ that I mentioned above. The two of the four I couldn’t recall were - Xdisplay and /home.
I do have a separate home partition. As mentioned Nvidia the hard way is now installed but the previous driver (if that is referring to Xdisplay) with the delay in the same batch was the default nouveau.
totara:~ # 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 @1min 12.077s
└─multi-user.target @1min 12.077s
└─cron.service @1min 12.076s
└─postfix.service @1min 10.620s +1.177s
└─network.target @1min 10.600s
└─NetworkManager.service @1min 7.787s +2.803s
└─SuSEfirewall2_init.service @41.204s +26.541s
└─basic.target @41.011s
└─timers.target @40.971s
└─systemd-tmpfiles-clean.timer @40.951s
└─sysinit.target @40.809s
└─apparmor.service @40.449s +359ms
└─systemd-tmpfiles-setup.service @40.375s +65ms
└─local-fs.target @40.363s
└─home.mount @8.074s +32.288s
└─systemd-fsck@dev-disk-by\x2duuid-b9856549\x2d3826\x2d429e\x2da015\x2d716f9fd58e3b.service @7.901s +172ms
└─dev-disk-by\x2duuid-b9856549\x2d3826\x2d429e\x2da015\x2d716f9fd58e3b.device @7.877s
The last time I’ve had any doings with 'a start job is running it was to do with incorrect entries in fstab - but I was able to fix that no bother. I am unable to untanglethecurrent delays. Baffled, I am, baffled.
Best wishes,
Hugh
I’m seeing slow boots. I think it is networking, though I’m not sure.
On my system with factory (=tumbleweed) and Nvidia, there was a very long delay after a kernel update. So long, that it seemed permanent. I don’t recall fully the details, but I think I was able to use CTRL-ALT-F1 and get to a terminal session, and reboot from there.
Since then my practice has been:
If this is the first boot after a kernel update, then hit ESC on the Plymouth screen. Allow the boot to complete with text messages on the screen. Then reinstall the nvidia drivers (the hard way). It looks to me as if there is a problem with Plymouth recognizing that the boot is complete even though there is still no graphic mode.
I’m not sure if this was your problem, but from your description it seems a possibility.
Hi thanks for the input. No the delay was there before I installed NVIDIA the hard way.
The first output of
systemd-analyze critical-chain
had wicked as the network connection - this was a default.
When I read the first output I could see that something was going on with network and successfully switched the networking module to the one I’m used to.
The result of that switch seems to have toned down the delay as can be discerned in the second output of
systemd-analyze critical-chain
Thee is still an unusual wait before the desktop appears.
With reference to the delay with new kernels - in my experience with another distro with repo nvidia drivers installed and dkms installed there is always a delay while dkms does its business with rebuilding the drivers.
That’s not my issue here.
The expectancy of reaching the desktop quickly has gone for the time being. I’ll have to experiment a bit more.
# 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 @1min 10.993s
└─multi-user.target @1min 10.993s
└─cron.service @1min 10.993s
└─postfix.service @1min 10.122s +869ms
└─network.target @1min 10.121s
└─NetworkManager.service @1min 6.523s +3.196s
└─SuSEfirewall2_init.service @12.451s +54.071s
└─basic.target @12.003s
└─timers.target @12.003s
└─systemd-tmpfiles-clean.timer @12.003s
└─sysinit.target @12.002s
└─systemd-journald.service @1min 7.381s
└─system.slice
└─-.slice
SuSEfirewall2_init.service and NetworkManager.service are looking fairly guilty.
But what is to be done with them?
In in doubt or you feel life is too short then by golly, reinstall!
And that’s just what I’ve done. Not strictly a reinstall though - I downloaded a current tumbleweed snapshot and installed it in the obliterated partitions.