4️⃣ Here's the 4th post highlighting key new features of the upcoming v261 release of systemd.

[pid_eins@mastodon.social]

4️⃣ Here's the 4th post highlighting key new features of the upcoming v261 release of systemd. #systemd261 #systemd

On many servers and embedded devices serial console console access on boot is absolutely essential. For that reason, firmwares (UEFI), boot loaders, and the kernel itself all support sending their boot time output to a serial port, and receiving input from it.

Configuring serial consoles in the boot loader and Linux is kinda painful though: you need to know some…

[pid_eins@mastodon.social]

…hardware properties, and you need to specify that in config files/kernel command line, and hope for the best.

This is also problematic in secure environments: doing local configuration via the kernel command line breaks certain SecureBoot requirements, and makes measurements less predictable.

[pid_eins@mastodon.social]

With UEFI things became a bit easier on the firmware/boot loader front, as UEFI has a native, standardized understanding of serial ports. As long as the boot loader just uses what the firmware provides, things should be OKish.

But that left a major gap between firmware/boot loader on one hand and Linux on the other. WIth systemd v261 we do something about this: systemd-stub will now query the firmware console output settings, and will synthesize console= kernel command line switches…

[pid_eins@mastodon.social]

…from it, on the fly, without requiring local configuration. Or in other words: serial console configuration of the OS now will automatically follow serial console configuration of firmware/boot loader. Yay!

That said, not everything is perfect about this: this works really well on x86, because serial ports are very very standardized there, i.e. the I/O port numbers, the interrupts and everything, since basically 1981. But on ARM platforms things like that are not a given, hence…

[pid_eins@mastodon.social]

…the logic just disables itself everywhere but on x86.

[purpleidea@mastodon.social]

@pid_eins Amazing! Does this mean on a stock distro I can plug into the serial port and get a console without having to do the GRUB settings dance? What a great idea.

[valpackett@social.treehouse.systems]

@pid_eins wait, how do synthesized console= args interact with args participating in verified boot?

re: Arm platforms, on DT systems serial ports must be fully described by DT (and usually the console one is aliased as serial0.. or serial1 lol.. and if someone cared enough there's also stdout-path = "serial0:115200n8"; or something), and on ACPI systems it's fully described by the SPCR table. Basically there shouldn't ever be any need to configure serial from cmdline ever outside of early bringup of a new platform.

[daandemeyer@mastodon.social]

@valpackett @pid_eins And yet if you try booting a qemu vm without a console= argument in your kernel command line, you'll find you won't get any logs unless you add it.

[pid_eins@mastodon.social]

@purpleidea hmm? you lost me at "grub"...

In 2026 a secure boot chain doesn't do grub anymore. not much of the stuff we do in systemd about booting applies if you do grub instead of systemd-boot/systemd-stub.

[adamw@fosstodon.org]

@pid_eins does it also disable itself if there are explicit console= args?

[wrmsr@peering.social]

@pid_eins Oh this sounds like a good test candidate for my Netgate 6100 firewall at home.

Currently, the UEFI and systemd-boot displays output via serial (this machine has no VGA or the likes) but the kernel stays silent unless I specify the console parameter on the kernel cmdline.