Very Slow Boot after updating from 16.04 to 18.04

Hello, I realize other people have posted similar topics but I'm no computer whizz and have struggled to find a solution. Maybe updating to the 19.04 version will solve the problem but in the meantime my laptop is taking between 5 and 8 minutes to boot compared to less than a minute with 16.04.

Any help much appreciated. So far I've run the command systemd-analyze blame and got the following:

     58.820s apt-daily-upgrade.service
     46.518s apt-daily.service
     19.990s systemd-journal-flush.service
     19.586s dev-sda1.device
     15.320s ufw.service
     12.592s systemd-hwdb-update.service
     10.958s keyboard-setup.service
     10.152s systemd-tmpfiles-setup-dev.service
      8.973s systemd-sysctl.service
      7.723s NetworkManager-wait-online.service
      5.368s snapd.service
      5.077s udisks2.service
      4.730s NetworkManager.service
      4.009s accounts-daemon.service
      3.962s wpa_supplicant.service
      3.733s upower.service
      2.979s dev-loop3.device
      2.972s dev-loop5.device
      2.966s ModemManager.service
      2.955s dev-loop4.device
      2.951s dev-loop2.device
      2.950s dev-loop1.device
      2.939s dev-loop0.device

lines 1-23

Welcome to the UM community. I to have a laptop that is now taking forever to boot after upgrading to 18.04. I noticed that I have an acpi bug error during post that I don't remember being there before. I have changed no bios settings? I tried wiping the drive and installing 16.04.6 64 bit and it didn't fix it. I'm going to try a 32 bit version, or seeing if I saved an earlier iso of 16.04.

systemd's "blame" is often misleading: you should probably try "systemd-analyze critical-chain" instead. (That's also often misleading, but sometimes it's useful). For not being a "computer whiz" though, you're doing pretty well! :slight_smile:

Do you have a mechanical HDD, or an SSD? systemd basically (and openly) "doesn't care" about HDDs, so its defaults often include things that thrash the drive, stalling the entire system, which "blame" etc doesn't properly represent. (It's fixable: it just means such systems will do badly until they're reconfigured).

Hi, thanks for your replies and encouragement. I tried to post the output of systemd-analyze critical-chain but got this pop up message:

Sorry, new users can only mention 2 users in a post

ps AFAIK my hard drive is mechanical, the laptop is a Toshiba Satellite Pro A300.

heh. That'll be the @ signs in the output. Try using the "Blockquote" button. (If that still barfs then the forum software is just broken and you'll have to edit the @s out by hand).

I think you've PROBABLY got two different problems (though this is all guesswork, obviously). One is that some garbage services are just thrashing your hard drive, with one of them potentially also blocking login until it's done; and the other is that Something Fishy is going on, because all of those blame entries COMBINED don't add up to 5+ minutes.

So, when you say "to boot", are you talking about "until I get a graphical login prompt"? Or are you using some other milestone as "okay, this counts as 'booted'"?

Thanks arQon,

I tried to use the blockquote function but must be doing it wrong. Here's the systemd-analyze critical-chain output:

graphical.target [at]1min 2.183s
└─multi-user.target [at]1min 2.181s
└─getty.target [at]1min 2.180s
└─[email protected] [at]1min 2.180s
└─system-getty.slice [at]1min 2.178s
└─setvtrgb.service [at]1min 2.078s +97ms
└─systemd-user-sessions.service [at] 30.989s +20ms
└─network.target [at] 30.987s
└─NetworkManager.service [at] 25.615s +5.370s
└─dbus.service [at] 25.153s
└─basic.target [at] 25.042s
└─sockets.target [at] 25.042s
└─snapd.socket [at] 25.007s +32ms
└─sysinit.target [at] 25.002s
└─swap.target [at] 25.001s
└─dev-disk-by\x2duuid-c5368c23\x2d4757\x2d441a\x2d86
└─dev-disk-by\x2duuid-c5368c23\x2d4757\x2d441a\x2d

I did notice that the times don't add up. By booting I mean the time it takes for the main screen to pop up with toolbars, welcome screen etc. Until then I get a black screen with a cursor for a while, then the Ubuntu logo for a few seconds then more black screen. I think you're right about the services, I do get the impression that the system is fighting with itself unnecessarily for several minutes before it gives up and starts the computer.

Thanks again. Hopefully the output above will shed some light on the process.

The blockquote problem isn't you: I noticed earlier today that it's also responding to # etc, which kind of defeats the purpose of blockquotes. Apparently you need to use "Preformatted text" for it here (though that's got other issues of its own).

ugh. So yeah - systemd is clearly misrepresenting things, as expected, because it's not looking at reality. You can't go from "Started ater 31s and took 20ms" to the next one "Starting at 1min+" and claim that's an accurate list of events.
Problems like this are generally pretty easy to fix if you have the machine in front of you, but very slow to deal with remotely because you just don't have the information you need and have to uncover it a piece at a time. :frowning:

For example, have you done anything like "encrypt my home folder"? Or are using encryped swap, and so on?

The "black screen with a cursor for a while" is probably X starting up, but it depends on what the cursor looks like, and if it was then the time between that and login shouldn't be more than a few seconds at most. I have no idea where any "Ubuntu logo" is coming from, unless that's the boot splash.
My own machines didn't really change at all in boot times when I went from 16.04 to 18.04, but that's probably because I'd removed most of the problematic pieces long ago, so your issue is basically just a lot of guesswork from my end.

One thing I think we can infer is this: if systemd lost track of 30+ seconds of your boot, then the cause of that has to be something that happened prior to that missing time. Two especially-stupid boot delay causing services are snapd and NetworkManager-wait-online, but although those are certainly not helping you they're also not causing disk thrash, so they aren't the mysterious "big" problem.

I think the first thing to do is put yourself in a position where you can see what's going on a little better. This piece may sound scary, but hopefully won't be in practice. :slight_smile:
edit "/etc/default/grub" as root, i.e. "sudo pluma /etc/default/grub" (or whatever editor you're comfortable with). Find the line that says "GRUB_CMDLINE_LINUX_DEFAULT" and if it has "splash" or "quiet" in there, delete those words. That is, what you want is a line that just says
GRUB_CMDLINE_LINUX_DEFAULT=""
If it has anything more complicated than "splash" or "quiet" in there, STOP and post that here first just in case.

That will let you see what's actually happening during boot, and it may become obvious from that alone what the problem is.

You might as well disable the services I mentioned earlier too - like I say, they shouldn't be the problem, but they're basically useless and will save you a few seconds. They can easily be turned back on later if you want them again. We'll take out a couple of others as well for now.
(Note: you can use TAB to fill out the service names. On my machines, a lot of this stuff has been removed entirely, so I'm working from memory and might not get the names exactly right).
$ sudo systemctl disable snapd.service
$ sudo systemctl disable NetworkManager-wait-online.service
$ sudo systemctl disable apt-daily.service

When you reboot, you'll see a lot of text go scrolling by. If that stops scrolling for several (or many) seconds, the last few lines will probably give you a good hint as to why. It's also entirely possible that that part will go fine, and then you'll go to a (black) graphical screen with just a cursor on it and nothing will happen for several minutes, again. At that point, if you use CTRL-ALT-F1 you'll get a tty login prompt. If you can login through THAT right away, that's useful information too. If you do, dmesg |tail after you've logged in will also let you see what's going on in real time. CTRL-ALT-F7 will take you to your graphical login whenever that's ready, if it doesn't take you there automatically at that point.

gl!

Hi arQon, thanks again for all the information and advice, here are my answers so far:

I haven't encrypted the home folder and AFAIK am not using encrypted swap, should I check for that?

In terms of the start up sequence , the cursor looks like an underscore in the top LH corner, but it doesn't blink. A log in dialog flashes up briefly but disappears before I can type anything. Then it's back to a black screen with no cursor for a bit, before the Ubuntu logo/wheel (this might be the boot splash?) appears with a progress bar underneath. That runs for a bit then more black screen until the main screen opens. During the whole time the hard drive light comes on briefly and intermittently and it churns away for a bit then stops and starts again. It's not grinding away constantly during the process, in fact most of the time nothing much seems to be happening.

I put sudo pluma /etc/default/grub into a terminal and got the following lines (there was more but this is the bit you were referring to):

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=lsb_release -i -s 2> /dev/null || echo Debian
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

I deleted "quiet splash" and left it with the two quotation marks as you suggested. I tried the commands to disable the services but the terminal wouldn't let me enter the password. The cursor blinked but I couldn't enter any text.

I'll reboot now and see if removing quiet splash has changed the process.

It won't have, because I was tired and forgot sudo update-grub, which you need to run afterwards, sorry.

"the terminal wouldn't let me enter the password" sounds like you have a serious problem somewhere. Try from the CTRL-ALT-F1 terminal, and if even that doesn't work you should probably boot into the recovery shell (under "Advanced options for Ubuntu" or something like that in the boot menu) and choose the "Check and repair all filesystems" option (again, from memory, probably not the exact wording but hopefully close enough). Except, you were able to when editing the file, so, erm, now I'm very confused...

Hi again,

I've just remembered from somewhere that sometimes the password doesn't show up as you type it. I tried sudo update-grub and got the following:

Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-65-generic
Found initrd image: /boot/initrd.img-4.15.0-65-generic
Found linux image: /boot/vmlinuz-4.15.0-64-generic
Found initrd image: /boot/initrd.img-4.15.0-64-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
done

I tried again with the services and the first two seemed to work:

$ sudo systemctl disable snapd.service
Removed /etc/systemd/system/multi-user.target.wants/snapd.service.
$ sudo systemctl disable NetworkManager-wait-online.service
Removed /etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service.

Nothing seemed to happen with the last one:

$ sudo systemctl disable apt-daily.service

I tried rebooting and it was still slow but I did see the text scrolling past. Then it went into the usual sequence of black screens.

I put dmesg| tail into a terminal and got the following:

[ 350.021664] ESI: 00000001 EDI: c05064a7 EBP: 0000000e ESP: bfcab9e8
[ 350.021667] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 350.021672] Code: 83 c4 0c e9 1a ff ff ff e8 5d 7b 0b d6 8b 45 d0 8d 55 dc e8 22 a6 0f d6 85 f6 0f 85 f9 fe ff ff 57 68 94 b5 fd f7 e8 cf 78 0b d6 <0f> 0b 58 5a e9 e5 fe ff ff 8d b6 00 00 00 00 66 66 66 66 90 55
[ 350.021778] ---[ end trace fb34033ec11338b0 ]---
[ 360.160137] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] ERROR [CRTC:41:pipe B] flip_done timed out
[ 370.400150] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] ERROR [PLANE:35:plane B] flip_done timed out
[ 392.084628] [UFW BLOCK] IN=enp2s0 OUT= MAC=00:1e:33:65:3f:73:e0:b9:e5:1a:b2:a6:08:00 SRC=192.168.1.254 DST=192.168.1.64 LEN=291 TOS=0x00 PREC=0x00 TTL=64 ID=34989 PROTO=UDP SPT=1900 DPT=41066 LEN=271
[ 392.085412] [UFW BLOCK] IN=enp2s0 OUT= MAC=00:1e:33:65:3f:73:e0:b9:e5:1a:b2:a6:08:00 SRC=192.168.1.254 DST=192.168.1.64 LEN=296 TOS=0x00 PREC=0x00 TTL=64 ID=34990 PROTO=UDP SPT=1900 DPT=41066 LEN=276
[ 443.864229] [UFW BLOCK] IN=enp2s0 OUT= MAC=01:00:5e:00:00:01:e0:b9:e5:1a:b2:a6:08:00 SRC=192.168.1.254 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=35129 DF PROTO=2
[ 568.958987] [UFW BLOCK] IN=enp2s0 OUT= MAC=01:00:5e:00:00:01:e0:b9:e5:1a:b2:a6:08:00 SRC=192.168.1.254 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=35145 DF PROTO=2

Thanks for your help btw and no problem about sudo update-grub

I did that too after you mentioned it.

Also see -

Thanks mdooley, that has made a big difference, the boot time is down to two minutes now.

Sweet. :slight_smile:

This section in your syslog:

[ 350.021667] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 350.021672] Code: 83 c4 0c e9 1a ff ff ff e8 5d 7b 0b d6 8b 45 d0 8d 55 dc e8 22 a6 0f d6 85 f6 0f 85 f9 fe ff ff 57 68 94 b5 fd f7 e8 cf 78 0b d6 <0f> 0b 58 5a e9 e5 fe ff ff 8d b6 00 00 00 00 66 66 66 66 90 55
[ 350.021778] ---[ end trace fb34033ec11338b0 ]---

shows that something crashed on startup. Whatever that "something" is, it's worth investigating. Look a few (or possibly a few dozen!) lines above that in the log - usually easiest via dmesg |less, pressing END, and then paging back upwards - and you'll find what the dying process is.

Thanks arQon,

I tried dmesg |less but couldn't find that section in the log, so maybe it's resolved itself? If there's anywhere else I should look then please do let me know.

Thanks again for all your help.

Though i doubt we have the same problem - is your laptop rather old? I found the problem with my Toshiba A305 is any Kernel newer than 4.4, and have read that anything beyond 4.4.0.91 will cause problems. Thing is I had been running various distros, with kernels after 4.4 with no problem until MATE 18.04?

EDIT - NEVERMIND. Thank you mdooley! I did the edit to grub and the first reboot was about 90 seconds instead of 8 minutes, and each subsequent boot takes less than 20 seconds. However, I did this on 19.04 thinking it may help my boot times to upgrade from 18.04 to 19.04 - the upgrade didn't help. I assume mdooley's solution would work in 18.04 as well. That first reboot displayed two "atomic helper"......"kms"...."Flip flop" errors. which I didn't have time to record or even read properly. Thank you again

Just as a point to remember later, the 19.10 beta doesn't appear to need the "video=SVIDEO-1:d" addition to grub that works around the flip_done timed out bug .

This is another bug that has been fixed in the beta.

1 Like

Hi jmarkus, yes, it's pretty old, I bought it second hand but 16.04 was fine on it. Which is why it was so strange when I updated to 18.04 and everything ground to a halt!

Then it's probably from the piece mdooley mentioned, so that's good. :slight_smile:

Two minutes is obviously a big improvement over where you were, but it's still pretty slow. What was it for you on 16.04?
The POST (the part of boot before it even gets to grub) is generally fairly constant, but with the crashy piece seemingly resolved, you should now hopefully be able to get useful diagnostics from systemd. I'd be tempted to run blame and critical-chain reports again and see if the numbers add up properly now.