UM 18.04 taking long time (like 5 minutes) to complete boot

My PC (Ubuntu Mate 18.04) use to start in less than a minute, closer to 20-30 seconds. Now it is taking minutes. The login goes as normal, the desktop screen background is displayed, sometimes with my desktop icons, sometimes not. But the cursor is spinning. I can open items from the task bar and proceed as normal, but the cursor is still spinning on the desktop for minutes. Seems like something is timing out. I tried the post here with no success. Any suggestions are appreciated.

1 Like

Can you open the system monitor app or HTOP to view any process that may be consuming your resources

I did, nothing seemed to be using excessive memory or cpu.

How about restarting with the network card, including wireless and other IOT disabled. At least you can eliminate external sources

slow_booting.txt notes. Please see -

This guy explains how he chased down the causes of slow boot times on 18.04. Very good.

More slow boot times. - Thread includes removing snaps and using several systemd tools such as

systemd-analyze critical-chain      
systemd-analyze blame

Also see -

Good luck jaybo.

1 Like

I have reviewed those links again. I have tried the following, all resulting in no improvement.

  1. Changed Grug line to:
    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"

  2. Changed networking.service line to:

  3. Run “sudo rm /etc/initramfs-tools/conf.d/resume” followed by “sudo update-initramfs -u”

  4. Changed lines in /etc/systemd/system.conf to:
    This change did bring up the desktop instantly, but the desktop was unusable, you could not click on an icon until the boot process finished.

  5. $ systemd-analyze

Startup finished in 4.009s (kernel) + 5.767s (userspace) = 9.776s reached after 5.757s in userspace
$ 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. 5.757s
└─ 5.757s
└─smbd.service 5.678s +78ms
└─nmbd.service 5.606s +70ms
└─ 5.604s
└─NetworkManager-wait-online.service 1.834s +3.768s
└─NetworkManager.service 1.522s +305ms
└─dbus.service 1.303s
└─ 1.291s
└─ 1.291s
└─snapd.socket 1.290s +1ms
└─ 1.284s
└─systemd-timesyncd.service 838ms +445ms
└─systemd-tmpfiles-setup.service 821ms +13ms
└─systemd-journal-flush.service 309ms +510ms
└─systemd-journald.service 183ms +118ms
└─syslog.socket 181ms
└─system.slice 172ms
└─-.slice 170ms

$ systemd-analyze blame
3.768s NetworkManager-wait-online.service
1.417s dev-sda1.device
1.073s snapd.service
853ms udisks2.service
516ms vboxdrv.service
510ms systemd-journal-flush.service
445ms systemd-timesyncd.service

Nothing stands out to me. This issue started after a recent updates. It does seem like some sort of timeout issue before displaying the desktop. The task bars do come up immediately and are usable.

I am willing to try restarting with the network card, including wireless and other IOT disabled. But I am not sure how.

@jaybo Pull out the ethernet cable to ensure wired networking is disabled. Click on the wireless connection icon in the upper panel and uncheck Enable Networking. System, Shut Down..., Restart. That should do it.

Thanks. So that identified the problem. I even rebooted again to ensure it was not a fluke. After re-enabling the network, the issue returned. Now I do have network connectivity prior to the desktop being enabled. Also, there is no wifi or bluetooth interface, just ethernet.

See this link to a post of mine responding to a similar problem.

You should try disabling NetworkManager-wait-online.service .

Thanks for the suggestion, but I noticed no difference in boot time. I do have network activity instantly, and composed and posted this entire post before my desktop was displayed.

What happens when you disconnect/disable all networking, reboot, give your system about 5 seconds to settle down, enable networking (only) and then plug in your ethernet cable? Does the spinner display or does everything work just fine?

All worked just fine. I then hit disconnect and unchecked Enabled networking, but leaving the ethernet plugged in, rebooted. All came up fine, re-enabled the networking and all worked fine without delay.

So it appears that something to do with your wireless is at the root of your slow boot problem. Perhaps there is something you can do about your wireless/bluetooth driver? Happy googling @jaybo .

As I mentioned earlier in the thread, my hardware does not have bluetooth or wifi. Thanks anyway for your help.

I misunderstood your comment in post #8. So your problem is solved? post #13?

If I understand you correctly, you suspect for some reason my system is trying to use Bluetooth and/or wifi drivers even though the hardware never existed. Is this correct?

That was my understanding, yes, based on your response in post #8, "there is no wifi or bluetooth interface" and in post #6, "restarting with the network card, including wireless and other IOT disabled".

To me (mistakenly) that meant that your slow boot was due to some interference from the non-existent hardware or their drivers. You might check what is being automatically sought after in your start-up items.

And is your problem solved?

I can't find anything in the start-up items. I disabled a few, but no change.

Not sure if this means anything but the syslog showed the following errors:

Jul 8 21:40:31 UM18 system-tools-ba[2804]: No such method ServicesConfig->getFiles
Jul 8 21:41:37 UM18 gvfsd-metadata[2612]: g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed
Jul 8 21:41:40 UM18 gvfsd-metadata[2612]: message repeated 15 times: [ g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed]

Earlier mentioned all my apps are usable. But I found Caja is not. Not sure if this means anything.

Also, I have read many had this problem due to swap partition on another drive being used. My 18.04 system is using a swap file. I do have another SSD with UM 16.04 with a swap partition. However, I assumed this issue was eliminated when the system boots normally with the network disabled.

So not solved yet. The business of the problem seemingly vanishing with networking disabled is pointing at the solution. And enabling your network after booting will eventually become an annoyance even if this workaround does the job today.

You might check my notes below for whatever applies to your situation regarding SWAP. Just take the following as things to read. If you want more help, you're gonna have to tell me what your system actually is.

And to do that, please post the results of inxi -F I'll look at it as soon as time permits.

resume_variable - notes

See -

If you change your hard drive, you might have to set the RESUME variable. Check /etc/initramfs-tools/conf.d/resume Since you have a swap file, maybe RESUME=NONEis appropriate.

Make sure that fstab has the correct UUID for a swap device (if any). On my newton box, I have no swap whatsoever not ever using hibernate and having 16 GiB RAM. My upstairs laptop benefited from following the fix outlined in the forum page above.

I learned that not only fstab should be correct but that /etc/initramfs-tools/conf.d/resume needs to have the correct UUID for swap.

After correcting the resume file, I ran this code - sudo update-initramfs -u -k all My boot images were processed without a message like the one below:

initramfs-tools configuration sets RESUME=UUID=6752bc85-87bd-4f55-a01d-d966557ff115W: but no matching swap device is available. A couple more lines and then this: Set the RESUME variable to override this.

And more -