The initial screen of Plymouth takes 20 minutes to appear (Groovy live)

Bug #1900715 reported by Diego Germán Gonzalez
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
plymouth (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

The initial screen of Plymouth takes 20 minutes to appear when starting an installation media from a flash drive
The installation media were created with
-Ubuntu disk creation tool
-Fedora Media Writer
-Balena Etcher

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: plymouth 0.9.5-0ubuntu2
ProcVersionSignature: Ubuntu 5.8.0-25.26-generic 5.8.14
Uname: Linux 5.8.0-25-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu50
Architecture: amd64
BootLog: Error: [Errno 13] Permiso denegado: '/var/log/boot.log'
CasperMD5CheckResult: skip
CasperVersion: 1.455
CurrentDesktop: ubuntu:GNOME
Date: Tue Oct 20 11:26:44 2020
DefaultPlymouth: /usr/share/plymouth/themes/bgrt/bgrt.plymouth
LiveMediaBuild: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201020)
MachineType: Gigabyte Technology Co., Ltd. GA-78LMT-S2
ProcCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/username.seed maybe-ubiquity quiet splash ---
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=es_ES.UTF-8
 SHELL=/bin/bash
ProcFB: 0 nouveaudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/username.seed maybe-ubiquity quiet splash ---
RebootRequiredPkgs:
 linux-image-5.8.0-25-generic
 linux-base
SourcePackage: plymouth
TextPlymouth: /usr/share/plymouth/themes/ubuntu-text/ubuntu-text.plymouth
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/14/2012
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F4
dmi.board.name: GA-78LMT-S2
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF4:bd08/14/2012:svnGigabyteTechnologyCo.,Ltd.:pnGA-78LMT-S2:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-78LMT-S2:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-78LMT-S2
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

Revision history for this message
Diego Germán Gonzalez (diegogermangonzalez) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Do you really mean plymouth or some other screen? If unsure then please attach photos of what you see during and after the 20 minutes.

Also, can you please reproduce the problem again and then start a live session and run:

  journalctl -b0 > journal.txt

and attach the resulting text file here?

Changed in plymouth (Ubuntu):
status: New → Incomplete
Revision history for this message
Diego Germán Gonzalez (diegogermangonzalez) wrote :
Revision history for this message
Diego Germán Gonzalez (diegogermangonzalez) wrote :

After the initial screen of the grub you see a black screen with a white dash blinking in the upper left corner for about twenty minutes.

Then text and then the screen with the Ubuntu logo and the integrity check
I am trying to make a capture of the text.

Revision history for this message
Steve Langasek (vorlon) wrote :

The journal you've attached unfortunately doesn't show timing information for anything that happened before systemd started, so it's impossible to say what is causing a 20-minute delay (the timestamps in the journal only cover a 3-minute period). Would it be possible for you to also attach the output of 'dmesg' from after one of these 20-minute boots, so that we can see where the kernel is spending its time before the root filesystem is mounted?

Also, there are these very strange entries in the journal:

oct 21 16:46:22 ubuntu kernel: EXT4-fs (sda6): INFO: recovery required on readonly filesystem
oct 21 16:46:22 ubuntu kernel: EXT4-fs (sda6): write access will be enabled during recovery
oct 21 16:46:22 ubuntu kernel: random: crng init done
oct 21 16:46:22 ubuntu kernel: EXT4-fs (sda6): orphan cleanup on readonly fs
oct 21 16:46:22 ubuntu kernel: EXT4-fs (sda6): 24 orphan inodes deleted
oct 21 16:46:22 ubuntu kernel: EXT4-fs (sda6): recovery complete
oct 21 16:46:22 ubuntu kernel: EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
[...]
oct 21 16:46:22 ubuntu kernel: EXT4-fs (sdb4): mounted filesystem with ordered data mode. Opts: (null)
[...]

I know of no reason that we should be mounting ext4 filesystems from the host system prior to actually starting the installer. That seems like a casper bug. But given that you had an ext4 filesystem that required journal recovery, that could certainly contribute to the boot taking some time.

Revision history for this message
Steve Langasek (vorlon) wrote :

> I know of no reason that we should be mounting ext4 filesystems from the
> host system prior to actually starting the installer.

Digging into the casper code, this is because from the initramfs we don't automatically know what device contains the isofs that needs to be mounted in order to get to the root filesystem, so available devices are scanned in order to locate it based on contents. Which means that an available ext filesystem on /dev/sda is going to be mounted first, and if it's in bad shape, it may take some time in order for the mount operation to complete.

Revision history for this message
Diego Germán Gonzalez (diegogermangonzalez) wrote :
Revision history for this message
Diego Germán Gonzalez (diegogermangonzalez) wrote :

By creating the installer with UNetbootin the problem does not occur.
UNetbootin creates its own boot loader.
I've attached the dmesg output with UNetbootin so you can compare.
Thank you.

Revision history for this message
Steve Langasek (vorlon) wrote :

So this dmesg is from a 20-minute boot? Because it shows systemd starting at 108 seconds after kernel init.

Revision history for this message
Steve Langasek (vorlon) wrote :

(and systemd, to be clear, doesn't start until after plymouth, in a live CD)

Revision history for this message
Diego Germán Gonzalez (diegogermangonzalez) wrote :

To be able to run the command I had to select the option to try Ubuntu and that restarts the session.
That was my mistake
Anyway, it's a matter of waiting until tomorrow. If no one else complains it's a problem with my hardware

Revision history for this message
Diego Germán Gonzalez (diegogermangonzalez) wrote :

Tanks Steve

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for plymouth (Ubuntu) because there has been no activity for 60 days.]

Changed in plymouth (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.