Re: [PATCH RFC walnascar 1/3] systemd: enable getty generator by default

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Wed, Apr 23, 2025 at 10:40:27AM +0000, Ross Burton wrote:
> On 23 Apr 2025, at 11:18, Mikko Rapeli <mikko.rapeli@linaro.org> wrote:
> >> Restore the existing behaviour by explicitly enabling the serial getty
> >> generator: this means that systemd will automatically bring up a getty
> >> on the first serial console it finds.
> > 
> > Is there a need to be backwards compatible this much? Many things may break
> > or get refactored on master branch between releases and this is just one of them.
> 
> Yes, because this is the behaviour that both fixes the KV260 issue and also doesn’t break all of the selftests due to how testimage+qemu interact.
> 
> > Then with these patches there still is the bug/issue seen in previous state too
> > where systemd tries to start agetty on all SERIAL_CONSOLES defined
> > at build time which slows down boot to "running" or "degraded" state
> > by more than one minute. This happens also on qemu where core-image-base
> > (I've added systemd-analyze with dependencies there to measure these):
> 
> Yes.  As I said, the proper solution here is to actually probe the setup.  Once we’ve got walnascar out of the way I’ll finish my branch that does the same system inspection for sysvinit so we don’t need to hardcode SERIAL_CONSOLES, instead it will bring up a console on the first tty it can find.  That is likely to cause problems with testimage (as it hooks up a second tty for failures) but will be isolated to genericarm64 and not every qemu machine.

Is there some bugzilla ticket or other location for details about the qemu and
testimage issue with serial consoles?

I've been running some selftests on genericarm64 with my proposed patches applied
and have not run into any serial console related problems. I've only seen a lot of
pseudo aborts on aarch64 build machine, e.g. wic touching images created by bitbake.

> > Thus I think this breaking change is fine for master branch and upcoming
> > release and that anyone expecting different, more robust behavior should just use
> > the systemd agetty generator.
> > 
> Absolutely.
> 
> > For genericarm64 I think https://lists.yoctoproject.org/g/poky/message/13592
> > is the way to go to fix both completely missing agetty
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=15830
> > and the slow boot time. Both this series and
> > https://lists.yoctoproject.org/g/poky/message/13592 applied does not
> > seem to work since SERIAL_CONSOLES is now used all the time, so delayed
> > boot issue remains unfixed.
> 
> Making systemd machine-specific would be disastrous for rebuilds as it is the provider of libudev and libsystemd, so would mean that _every_ recipe that uses those is also now machine-specific.
> 
> As was discussed in the Tuesday tech call last week, I suspect a better solution would be to have a machine-specific configuration recipe that can drop in configuration files, mask or enable units, etc.  This way specific machines can configure systemd in specific ways, without actually touching the core recipe.
> 
> Alternatively, splitting systemd into ‘userspace’ and ’system’ recipes where the former is tune-specific and contains the userspace-facing libraries and the latter is machine specific and everything else could make sense.

Ok so machine/BSP config should not change systemd setup then, got it.

Since "poky-altcfg" distro uses systemd by default, could it not also use
systemd to manage agetty startup and ignore SERIAL_CONSOLES from build time?

This sounds like the "efi" support issue I have with systemd. Patches out,
decision pending...

Cheers,

-Mikko