console=ttyS0 is too slow and useless

[xnox]

console=ttyS0 is specified in the gadget by default, in UC20, for all modes: recovery, install, and run mode.

However, on the hardware that does not have serial console (majority of real x86 hardware) this option significantly delays the boot, as the kernel is polling for the serial console to appear, delaying the boot by 90s.

Furthermore if the serial console is present, the baud rate is not set to be high enough, resulting in painfully slow boots still.

I would like to drop serial console option from the pc gadget.
If not completely, I can see the value of keeping it for the recover mode.
Alternatively I think we should publish a separate serial pc gadget, that specifies only the serial console with a high baud rate.

Could we make console a grubenv paramenter? such that ubuntu-image / snap-prepare-image can modify it, and it would persist from install mode, to sealed secrets, run/recover modes?

Also see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1879290

[xnox]

Or for example only enable and run console-conf on it, and not make kernel/journald slowly push messages to serial console delaying the whole boot.

[anonymouse64]

Note that changes to the kernel command line should probably not be done immediately until snapd has support to read the kernel command line from from the gadget.yaml / otherwise because right now the snapd snap has the kernel command line we seal the TPM to hard-coded so changing this will break FDE.

I believe @bboozzoo was working on the feature to read the kernel command-line from the gadget, do you have a status update on that?

[xnox]

@anonymouse64 i am aware of the current duplication / disconnect of the gadget vs sealing code, so yeah will not push out an update to this uncoordinated.

[ogra1]

all x86 IoT gateways i have touched yet (as well as most servers) do default to using a serial console ... dropping it completely doesn't smell like a good plan ...

[xnox]

as well as most servers

The current reference target for the pc gadget is Intel NUC, which does not have serial console by default.

Ubuntu Core does not target servers.

Can you please elaborate on the "IoT gateways" => can they run the stock PC gadget, or have custom ones? I thought they all have custom gadgets and do not use the reference PC gadget.

[xnox]

Also clouds may or may not have serial console, but they should be forking their own gadget anyway.

[xnox]

@anonymouse64 @bboozzoo if it helps, we can turn console=* values into a variable in either the stock grubenv file or a custom grubenv file i.e. install-settings.conf grubenv file which has like overrides for the consoles= to use/seal, and like cloud-init datasources to use/seal.

[anonymouse64]

My 2¢ here is that we should probably:

• always leave the serial console on for run mode and recover modes in the default gadget
• always have the serial console go as fast as possible when enabled
• make the kernel cmdline for using the serial console configurable when building the pc gadget in a very easy way that is encoded into the built snap (i.e. not something that gets dropped into the image to modify the behavior, it must be in the .snap file)

I agree with @ogra1, it might be the case that the Intel NUC doesn't have a serial, but for example another IoT amd64 edge gateway we enabled UC16 for was the Dell gateways which do have physical serial ports.

[ogra1]

Can you please elaborate on the "IoT gateways" => can they run the stock PC gadget, or have custom ones? I thought they all have custom gadgets and do not use the reference PC gadget.

well, the dell gateways (which admittedly currently come with a custom gadget) would be an example, all advantech ones i have touched yet. but also 90% of other Industrial PCs that might "just install" x86 focused images we provide on cdimage.

after all the typical IoT or industrial PC is often headless, yet an x86 base often means you can use an uncustomized image on them, unlike with arm devices where you can not have a generic image easily due to HW specific bootloaders.

EDIT: i mentioned servers simply because IoT GWs are typically a cut down server, not a cut down desktop ...

[anonymouse64]

x86 base often means you can use an uncustomized image on them

servers simply because IoT GWs are typically a cut down server

This is precisely why I think we should leave serial on by default in the pc gadget so that folks can "test-drive" UC on their IoT devices by just flashing a released default image and login with console-conf via serial without needing to build their own gadget snap/image.

[xnox]

My 2¢ here is that we should probably:

• always leave the serial console on for run mode and recover modes in the default gadget
• always have the serial console go as fast as possible when enabled
• make the kernel cmdline for using the serial console configurable

That will cost us a lot of boot time out of the box. Even "as fast as possible" is very slow. 30s+ of additional boot time.

Note, this is about dropping "console=" from the kernel command line to stop forcing kernel to slow down it's boot to the speed of being able to push kmsg to the serial console.

This is not about stopping/preventing consoleconf to run on serial consoles. By default it is spawned on them all.

[xnox]

EDIT: i mentioned servers simply because IoT GWs are typically a cut down server, not a cut down desktop ...

It's an embedded platform. Neither desktop or server. Because for something to be called a server, I expect 1TB of RAM, 1PT of NVME storage, RAID, infiniband, etc.

[ogra1]

while console-conf will indeed still come up, are there not menu bits at the initrd level now that would also use the defined console= ?

indeed, if it is just kernel boot messages we lose thats completely neglectable and i'd fully agree with the removal, but AFAIK there are potentially interactive bits before systemd kicks in as well

[anonymouse64]

This is not about stopping/preventing consoleconf to run on serial consoles. By default it is spawned on them all.

So w/o console=ttyS0 in the kernel commandline for run mode, what would the user experience be like? They plug in their device look at a blank serial console for ... however many minutes and then magically at some point console-conf shows up?