Lubuntu bionic boots slower than the other Ubuntu flavours with some SSDs

[sudodus]

See this thread at the Ubuntu Forums:

https://ubuntuforums.org/showthread.php?t=2388799

How come the ultra light Lubuntu Bionic needs 40 seconds from the grub menu to the log in screen, while the corresponding Kubuntu and Xubuntu Bionic can do it in 10 seconds in my Toshiba laptop?

All the operating systems were installed from the Bionic Beta-2 desktop 64-bit iso files and made up to date today (and reside in a new SSD connected via the internal SATA bay).

-o-

and to summarize the conclusion

https://ubuntuforums.org/showthread.php?t=2388799&page=2&p=13756324#post13756324

This supports the assumption, that there are problems for Lubuntu to manage SSDs with 4096 byte size physical sectors. But the other flavours of Ubuntu can manage it.

Let us hope that this can help the Lubuntu developer to find and squash the bug.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: lubuntu-desktop 0.93
ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
Uname: Linux 4.15.0-13-generic x86_64
ApportVersion: 2.20.9-0ubuntu4
Architecture: amd64
CurrentDesktop: LXDE
Date: Fri Apr 13 09:59:42 2018
InstallationDate: Installed on 2018-04-06 (7 days ago)
InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Beta amd64 (20180405)
SourcePackage: lubuntu-meta
UpgradeStatus: No upgrade log present (probably fresh install)

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1763611

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[volker kempter (v-kempter)]

exactly same problem for my lubuntu/lxqt bionic 64bit installation in virtualbox: 33.9 sec from the boot menu to login screen. No problems for the other flavours as mentioned above.

No such problems for a 32 bit installation without SSD, again as virtual machine.

[Steve Langasek (vorlon)]

The attached dmesg shows an almost exactly 30-second gap in output from the kernel, with no messages after the gap implying kernel driver timeouts, it just immediately mounts the root filesystem. Not much evidence to suggest that this is an SSD issue. Also, if it's reproducible in a 64-bit virtualbox environment, it's not an SSD issue. I'd suggest starting by looking for timeouts in any lubuntu-specific casper logic.

[Steve Langasek (vorlon)]

Ah, except casper shouldn't be involved at all, because this is an installed system (ext4 root) rather than a live image (squashfs on iso9660).

Still, this delay is certainly happening in the initramfs.

[sudodus (nio-wiklund)]

@Steve Langasek (vorlon),

I agree, that there is not enough evidence to be sure. But how come it makes a difference, when I replace the new SSD with 4096 bytes physical sectors with an older SSD (same size and brand name) with 512 bytes physical sectors? If not an SSD issue, could it be a file system issue (how to manage physical sector size, or is the file system only seeing the logical sector size)?

After some email correspondence on a Lubuntu mailing list, I am not sure that it is the same bug that appears in VirtualBox. Maybe, maybe not.

But this bug was reproduced by a user at the Ubuntu Forums, indicating that the delay depends on SSD physical sector size.

Anyway, the bug is very evident for me, depending on the SSD, and only appearing in Lubuntu. If you can conclude, that we should search for timeouts in some lubuntu-specific program package, fine.

[volker kempter (v-kempter)]

I can report the following:

- Export of a lubuntu-18.04 VM running in VB in a 32bit host with HD. This VM does not show the delay of about 30sec.

- Import of this VM into VB on the 64bit host with SSD; on this host all 64bit lubuntu-18.04 VMs show the 30 sec delay.

- Run the 32bit VM in VB on the 64bit host with SSD -> no delay!

In my opinion, this finding speaks against a problem with the SSD...

[sudodus (nio-wiklund)]

@ volker kempter (v-kempter),

I think we are affected by different bugs. The symptoms are similar or the same, but there can still be different bugs.

The bug that I reported is only manifest when I use an SSD with 4096 B physical sectors but not with an SSD with 512 B physical sectors (in the same computer), and this has been verified/confirmed by another user at the Ubuntu Forums. See this link,

https://ubuntuforums.org/showthread.php?t=2388799

The bug that I reported is affecting Lubuntu, but not for example Xubuntu and Kubuntu (all tested with daily iso files of Bionic Beaver).

[sudodus (nio-wiklund)]

@Steve Langasek (vorlon),

I am ready to do more testing in order to help identify this bug.

Please suggest what I should do and how to report the result.

[Steve Langasek (vorlon)]

This bug will need investigation by the Lubuntu team. But there should be no differences in the kernel between Lubuntu and other flavors.

[volker kempter (v-kempter)]

@nio-wiklund
as I mentioned in #5, also in my case the bug (33sec delay during boot) occurs with lubuntu only (not with xubuntu, kubuntu, mate, ubuntu). Thus, it appears that the bugs reported by us may be related.

[sudodus (nio-wiklund)]

@Steve Langasek (vorlon),

I agree, that there *should* be no difference in the kernel between Lubuntu and other flavors. Yet this happens only in Lubuntu.

@volker kempter (v-kempter),

Yes, it appears that the bugs reported by us may be related.

[volker kempter (v-kempter)]

slow boot:
a description of "my bug" can obviously be found in askubuntu.com, question: 1013830.

I followed the suggestion to modify

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

and replaced the line RESUME=UUID= ..... by RESUME=none

Unfortunately, it did NOT resolve "my bug".

@nio-wiklund
Could you please also try out the procedure described in askubuntu.com?

[volker kempter (v-kempter)]

#15:

after modifying /etc/initramfs-tools/conf.d/resume as described it is necessary to do

sudo update-initramfs -u.

After doing this,the boot is normal; in my case the total boot time is 6.8s.

Apparently, there is a problem with the UUID in /resume.

[sudodus (nio-wiklund)]

@ volker kempter (v-kempter),

Thanks for never giving up and finding that question/answer at AskUbuntu :-)

You are right! I did some checking, and there was also a warning, when running

sudo update-initramfs -u

indicating that i the resume file is used for hibernation.

So I set its content to

RESUME=none

which made Lubuntu boot quickly. Then I crosschecked with the other installed systems (Xubuntu and Kubuntu) and there is no resume file

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

at all, and the RESUME keyword is not found in

/etc/initramfs-tools/

So I think Lubuntu has a left-over file from when it used a swap partition, and a quick fix is to simply remove it and run

sudo update-initramfs -u

Maybe this is also the permanent fix, when done by the Lubuntu Developer ;-)

(Anyway, the swap file, that is created is smaller than the RAM size, so hibernation will not work well anyway. It is outside the scope of this bug report to investigate the conditions for hibernation.)

-0-

I was confused by the fact that Lubuntu was quick to check the partitions in an SSD with 512 B physical sectors but slow to check in an SSD with 4096 B physical sectors.

Now it is no longer a second or two slower than Kubuntu and Xubuntu to boot in an SSD with 512 B physical sectors.

[Simon Quigley (tsimonq2)]

This will get fixed before the release.

[Simon Quigley (tsimonq2)]

This is actually a bug in Ubiquity. Thanks to Bryan's help, I have identified where the problem is, and I will submit a patch tonight.

[sudodus (nio-wiklund)]

Thanks Simon,

Let us keep Lubuntu the fastest flavour of Ubuntu :-)

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 18.04.9

---------------
ubiquity (18.04.9) bionic; urgency=medium

  * Detect the proper name for zram in /proc/swaps (LP: #1763611).

 -- Simon Quigley <email address hidden> Fri, 20 Apr 2018 16:10:29 -0500

[Andreas Berger (hatbollen)]

Just wanted to add that I had this same issue in Kubuntu after upgrading from 17.10 to 18.04. So indeed it had to be in the installer package, and not DE-specific.

[sudodus (nio-wiklund)]

@Andreas Berger (hatbollen),

Interesting that you had it in Kubuntu after upgrading to 18.04, because it does not affect my fresh install of Kubuntu Bionic (18.04). Maybe there was a leftover 'resume' file from 17.10, and you converted to using a swapfile.

Anyway we are looking forward to the next daily iso files, where Simon's fix should squash the bug.

[sudodus (nio-wiklund)]

I installed Lubuntu from the daily Lubuntu Bionic alternate amd64 April 21. This installation is not affected by this bug.

I installed Lubuntu from the daily Lubuntu Bionic desktop amd64 dated April 21 (today's daily iso file). This installation is not affected by this bug. (I tested the corresponding iso file yesterday, and the bug was there).

The bug is squashed :-)

[Simon Quigley (tsimonq2)]

\o/

[Andrej Shadura (andrew.sh)]

I'm also affected by this bug on a normal Ubuntu. Times out the same way in initramfs.

Interestingly, this doesn't seem to happen with another installation of Ubuntu here.

Cc @vorlon

[Dirk F (fieldhouse)]

Please see my comments at https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1644975/comments/12 and https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1644975/comments/10.

In summary, /etc/initramfs-tools/conf.d/resume is obsolete.

The resume process is supposed to be driven by kernel command-line parameters resume and (optionally) resume_offset (which can be set by a script during update-grub) and the script /etc/initramfs-tools/scripts/local-premount/resume.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Andreas (aec67)]

I had same long boot time since upgrade from Ubuntu 16.04 LTS to 18.04 LTS.
I use Mate. (I tried Gnome and Unity but came back to Mate.)

I can confirm that changing /etc/initramfs-tools/conf.d/resume solved it on my Dell Vostroh laptop.

Here some details:

systemd-analyze time:

before:
Startup finished in 35.828s (kernel) + 8.228s (userspace) = 44.056s
graphical.target reached after 8.013s in userspace

now:
Startup finished in 3.762s (kernel) + 8.100s (userspace) = 11.862s
graphical.target reached after 7.973s in userspace

ae@ae-Dell:~/long-boot$ inxi -SMGDPI
System: Host: ae-Dell Kernel: 4.15.0-24-generic x86_64 bits: 64 Desktop: MATE 1.20.1
           Distro: Ubuntu 18.04 LTS
Machine: Device: portable System: Dell product: Vostro 3560 v: A17 serial: N/A
           Mobo: Dell model: 0C05GV v: A00 serial: N/A UEFI [Legacy]: Dell v: A17 date: 04/14/2014
Graphics: Card-1: Intel 3rd Gen Core processor Graphics Controller
           Card-2: Advanced Micro Devices [AMD/ATI] Thames [Radeon HD 7500M/7600M Series]
           Display Server: x11 (X.Org 1.19.6 ) drivers: modesetting,ati,radeon (unloaded: fbdev,vesa)
           Resolution: 1920x1080@60.02hz
           OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile version: 4.2 Mesa 18.0.0-rc5
Drives: HDD Total Size: 1024.2GB (51.2% used)
           ID-1: /dev/sda model: Samsung_SSD_850 size: 1024.2GB
Partition: ID-1: / size: 932G used: 482G (55%) fs: ext4 dev: /dev/sda1
           ID-2: swap-1 size: 8.46GB used: 0.00GB (0%) fs: swap dev: /dev/dm-0
Info: Processes: 253 Uptime: 26 min Memory: 1684.8/7852.1MB Client: Shell (bash) inxi: 2.3.56

[Andreas (aec67)]

I forgot to mention that I use SSD but it has not 4096 byte size physical sector as mentioned somewhere above.

So for me the only reason for long boot time is UUID in file /etc/initramfs-tools/conf.d/resume where I don't know why this was there.

ae@ae-Dell:~/long-boot$ sudo parted -ls
[sudo] Passwort für ae:
Modell: ATA Samsung SSD 850 (scsi)
Festplatte /dev/sda: 1024GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags:

Nummer Anfang Ende Größe Typ Dateisystem Flags
 1 1049kB 1016GB 1016GB primary ext4 boot
 2 1016GB 1024GB 8458MB extended
 5 1016GB 1024GB 8458MB logical linux-swap(v1)

Modell: Linux device-mapper (crypt) (dm)
Festplatte /dev/mapper/cryptswap1: 8457MB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: loop
Disk-Flags:

Nummer Anfang Ende Größe Dateisystem Flags
 1 0,00B 8457MB 8457MB linux-swap(v1)

[Edmund Lodewijks (lquidfire)]

This bug also occurred on a fresh install of Ubuntu Mate 18.04 on two different PCs.

The 30sec wait was removed by changing /etc/initramfs-tools/conf.d/resume and a subsequent sudo update-initramfs -u (according to instructions on https://askubuntu.com/questions/1034359).

[Alexey (dj--alex)]

18.04 and mint 19 x64 hve problem
no file resume

alex@NOUT:~$ /etc/initramfs-tools/conf.d/resume bash: /etc/initramfs-tools/conf.d/resume: Нет такого файла или каталога создал

[Ginés Utrera Pavón (myzras)]

For the versions of Ubuntu in which the file does not exist, we simply create it with the name 'resume', containing within the parameter 'RESUME = none'.