Ubuntu Mate 18.04 SLOW boot on old hardware vs. 16.04

Support & Help Requests
, ,
1

I have a somewhat ANCIENT Dell Latitude 2100 notebook which originally shipped with Ubuntu 9.04. It has been a great little toy and for the past several years has served as a jukebox in my workshop. It is powered by an Intel Atom processor, has a decent SSD and the maximum of 2 GB of RAM.

In its role as a jukebox it originally had 12.04 or 14.04 I am not sure. It has been do-release-upgrade updated through to 18.04. Following the upgrade to 18.04 it seemed that it was much slower to boot. I replaced it with a Raspberry Pi3B+ this past weekend and did a clean install of 18.04 - in case the multiple upgrades were an issue. It seems they were not.

18.04 takes 80 seconds from power on to the login screen and 40 seconds from submitting my credentials until the panel will respond and launch a terminal.

I installed 16.04 and the same tasks take 25 and 20 seconds respectively.

Any suggestions as to how to improve the 18.04 boot time?

I have read that 16.04 Mate is only supported through April 2019 where as the base Ubuntu is supported through 2021. Can someone confirm that this is true?

I am sort of in a quandary as to which version to run.

TIA,

Ken

2

It really depends on your intended use. The Atom CPU is too slow for most things.

If you stay with 16.04, many apps will be lighter than they are in 18.04 due to library bloat, gtk2 vs gtk3, etc.

I am keeping all of my 32-bit only systems at 16.04 and will not be upgrading them. I expect them to be just about "used up" by 2021:slight_smile:

djb

3

Thanks Dave_Barnes,

But it gets a bit stranger… I just unpacked a new Raspberry Pi 3B+. I have booted it from MicroSD cards containing configured and updated UM 16,04 and 18.04. They both boot in about 25 seconds - same as the Atom on 16.04. I suspect there is some conflict between the Atom laptop and 18.04. I am restoring my Clonezilla image of 18.04 to the Atom and will do some investigation.

Ken

4

Update:

I removed quiet and splash from the grub kernel options so I could see what was going on. /scripts/local-premount seemed to be taking a long time. I did some searching on that and found a bug having to do with the UUID for the swap partition on some SSDs. The fix appeared to be:

edit /etc/initramfs-tools/conf.d/resume and change
RESUME= (the UUID) to
RESUME=none
then run update-initramfs -u

That saved about half a minute. I observed that the grub menu was not displayed. I enabled that and found it was sitting there for 10 seconds. I dealt with that as well.

I have cut the boot time to less than 40 seconds - a little more than half of what I first observed. Still, I wonder why 16.04 is so much quicker on this machine but the same on the Raspberry Pi machine???

I can live with this but will probably keep poking at it :grin:

Ken

5

Interesting. I wonder what caused you to have a resume conf.d file as I have nothing in the conf.d directory nor in the scripts/local-premount directory.

6

From what I read it seemed to be related to doing a do-release-upgrade (which I did not do, this was a clean install) and/or certain SSDs. I think I just commented out the UUID. I guess I need to go back see if it matches anything on my machine.

Well I did and I did just now look at it. The UUID in resume does not match any device on the machine. I guess that is why it spent a lot of time trying to bring up a device which was not there. Unless it was the flash drive I used for the install. Unfortunately I re-imaged that drive when I did the 16.04 install.

Perhaps I will install again and make note of the UUID of the flash drive. Better yet, let me burn the same image to the same flash drive. The UUID should be in the image.

Looks like it is in the image. However, the image restores to an HPFS/NTFS file system. The UUID is shorter than a Linux file system UUID. Nice try but no cigar.

I have no idea why the offending file was there.

Ken

7

Now I remember:) I’m getting slow…

This fix is somewhere on this site.
Slow Boot fix:

$!/bin/bash

if [[ -e /etc/initramfs-tools/conf.d/resume ]]; then

   echo "Remove unneeded hibernation file (resume)..."

   sudo rm /etc/initramfs-tools/conf.d/resume

   sudo update-initramfs -u

fi

exit
1 Like
8

Thanks Dave_Barnes,

I believe I accomplished the same by commenting out the non-existent UUID and specifying RESUME=none in the file. I guess deleting the file would also do the trick.

As for hibernation - I do not think I have ever done that in Linux. I “suspend” all the time but as far as hibernating where memory is written to disk? Not that I know of.

Ken