pc: no message on the screen for ~30s on fast HW

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1879290

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Based on the video it looks like the first kernel messages which appear on the screen have timestamps >20s, so it seems likely at least part of the delay is in the kernel. If you can supply dmesg we might be able to get some idea of where this delay is happening.

This delay appears to be occurring because grub passes "console=ttyS0" on the commandline.

I finally managed to install a beta image on a Thinkcentre m920 (by removing the tpm module in grub before booting). Console output appears at the 32s mark, see full dmesg below. Some interesting console-related excerpts:

[ 0.049211] printk: console [tty1] enabled
[ 14.088918] printk: console [ttyS0] enabled
[ 17.020856] fbcon: Taking over console
[ 32.840867] efifb: probing for efifb
[ 32.883328] efifb: framebuffer at 0x40000000, using 4128k, total 4128k

I think the answer here is to stop passing "console=ttyS0". This is something that is typically only done for debugging.

dmesg shows a 14 second delay between the "console [tty1] enabled" and "console [ttyS0] enabled" messages. I suspect that because console=ttyS0 is passed the kernel is going to dump all the messages accumulated in dmesg so far to the serial port when it is registered as a console device. Because this is a slow device this consumes significant time, and it happens in an initcall so it blocks boot progress. Then boot from that point on is slowed down by printing messages out on the serial port every time something is printed to the kernel log.

And, "console=ttyS0" on it's own is particularly bad because it seems to default to a baud rate of 9600 (at least, setting it to 115200 on my NUC improved things considerably, but the boot is still slower than without the serial console option). Add that to the fact that the kernel is quite noisy on the console at startup (no "quiet")...

UC18 on the same hardware starts to display kernel messages at the 14s mark. UC18 logs shows no delay between the "console [tty1] enabled" and "console [ttyS0] enabled" messages, but otherwise the behavior is similar (blank screen for some time and slow output rate).

[ 0.000000] console [tty1] enabled
[ 0.000000] console [ttyS0] enabled

Result of systemd-analyze in both systems on the Thinkcentre machine:

uc18:
Startup finished in 30.880s (kernel) + 4.727s (userspace) = 35.608s
graphical.target reached after 4.721s in userspace

uc20:
Startup finished in 38.338s (kernel) + 17.902s (userspace) = 56.240s
graphical.target reached after 17.892s in userspace

Has anything happened that would change the status of this bug or does it still need fixing for uc20?

There was more discussion at https://github.com/snapcore/pc-amd64-gadget/issues/48, but no I don't think this has changed, we still have the serial tty in the kernel cmdline at the very least.

Last we talked about it in a meeting, Claudio measured that indeed the UC20 kernel regressed as compared to UC18 in this respect. There are delays in both cases but the delay is longer on UC20.