My HP-550 laptop with 18.04 (or perhaps 17.10) was starting up in 1:40 (to sign in)/2:55 (to ready), now I’ve installed 18.04.1 it’s taking 3:30/5:00. Any idea what has caused this? It only has 2GB RAM so I have tried it with and without a swap partition - no difference.
Suggest have a look at systemd-analyze and the bootchart as described on the Arch Wiki - often very useful to diagnose what is taking the time during the boot sequence
Everything that takes over 10secs:
1min 30.200s nmbd.service 52.468s apt-daily.service 32.414s plymouth-start.service 31.853s plymouth-quit-wait.service 31.848s lightdm.service 26.335s plymouth-read-write.service 14.025s dev-sda1.device 12.957s ufw.service 11.176s systemd-journal-flush.service
nmbd.service https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840608 this is beyond me! I think it relates to Samba Windows interoperability service - not even sure I need it.
1min 30 suggests it’s a big problem.
https://askubuntu.com/questions/800479/ubuntu-16-04-slow-boot-apt-daily-service suggests that this shouldn’t start at boot, but later. Perhaps boot takes so long that the OS thinks it already is later! The page suggests how to stop it, but it’s a bit out of my comfort zone without advice.
I don’t know the significance of this sequence:
graphical.target @2min 26.013s └─multi-user.target @2min 26.009s └─smbd.service @2min 25.471s +537ms └─network.target @48.274s └─NetworkManager.service @43.982s +4.289s └─dbus.service @43.925s └─basic.target @43.765s └─sockets.target @43.765s └─snapd.socket @43.758s +6ms └─sysinit.target @43.735s └─cryptsetup.target @43.693s └─systemd-ask-password-wall.path @2.996s └─-.mount @2.900s └─system.slice @2.905s └─-.slice @2.900s
it is safe to purge the samba package if you dont connect to and use MS Windows based machines.
Stopping neither made any difference, presumably they weren’t holding anything else up.
I tried Standard Ubuntu in desperation - same problem. What fixed it was this:
This is a bug. To avoid delay you can use workaround. From terminal run:
sudo nano /etc/default/grub
Then add the kernel boot parameter:
video=SVIDEO-1:d, so it will look like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=SVIDEO-1:d"
Just to say though… I don’t see a linked launchpad bug report. So it is highly likely that the kernel devs are not aware of the issue and hence cannot resolve it properly for you.
I have tried reporting things before, but just got moaned at for not having done things that I didn’t understand. On one occasion I got curtly told that I should have run some command to do a memory dump or something - this for a crash which made the whole machine lockup!.. which was clearly stated in my report.
It’s thus best that I leave that sort of thing to more expert users.