Bug 15337

Looking a bit further into it, it looks like ttyrun does not quite do it's job or at least behaves differently compared to the old behavior.

SUMMARY = "Start the program if the specified terminal device is available."
DESCRIPTION = "ttyrun is typically used to prevent a respawn through the \
init(8) program when a terminal is not available."
HOMEPAGE = "https://github.com/ibm-s390-linux/s390-tools"

-----

What ttyrun does is just to see if it can open the device, which means if /dev/xxx is available and it can open it, it's fine.

With the old method also a check was made against /proc/consoles

root@multi-v7-ml:~# cat /proc/consoles
ttymxc1              -W- (EC p  )  207:17

I guess this is what broke it.

Currently I am doing a build with the old approach, but probably something like this would be enough:

+pkg_postinst:${PN} () {
+# run this on host and on target
+if [ "${SERIAL_CONSOLES_CHECK}" = "" ]; then
+       exit 0
+fi
+}
+
+pkg_postinst_ontarget:${PN} () {
+# run this on the target
+if [ -e /proc/consoles ]; then
+       tmp="${SERIAL_CONSOLES_CHECK}"
+       for i in $tmp
+       do
+               j=`echo ${i} | sed -e s/^.*\;//g -e s/\:.*//g`
+               k=`echo ${i} | sed s/^.*\://g`
+               if [ -z "`grep ${j} /proc/consoles`" ]; then
+                       if [ -z "${k}" ] || [ -z "`grep ${k} /proc/consoles`" ] || [ ! -e /dev/${j} ]; then
+                               sed -i -e /^.*${j}\ /d -e /^.*${j}$/d /etc/inittab
+                       fi
+               fi
+       done
+       kill -HUP 1
+else
+       exit 1
+fi
+}
+

If I replace meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb with the previous version all seems to work as expected.

I also replaced meta/recipes-core/busybox/busybox-inittab_1.36.1.bb, but this does not matter for my current use case.

...
Configuring packages on first boot....
 (This may take several minutes. Please do not power off the machine.)
update-rc.d: /etc/init.d/run-postinsts exists during rc.d purge (continuing)
 Removing any system startup links for run-postinsts ...
  /etc/rcS.d/S99run-postinsts
...

Now it /etc/inittab looks like this:

# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
mxc1:12345:respawn:/sbin/getty 115200 ttymxc1 vt102

Created attachment 5001 [details]
reintroduce SERIAL_CONSOLES_CHECK

in order to restore the "old behavior" with SERIAL_CONSOLES_CHECK this patches reintroduce SERIAL_CONSOLES_CHECK in combination with ttyrun

Created attachment 5002 [details]
reintroduce SERIAL_CONSOLES_CHECK inittab

in order to restore the "old behavior" with SERIAL_CONSOLES_CHECK this patches reintroduce SERIAL_CONSOLES_CHECK in combination with ttyrun

First comment: we (I) removed SERIAL_CONSOLES_CHECK because it alters the rootfs on first boot, which means it's impossible to use machines that use it with a read-only rootfs (as you can't edit it on boot) or any form of package management on /etc/inittab (as an upgrade of base-files would delete the changes).

@Ross:

Yes I am aware of the behavior with a read only rootfs as documented here:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=13921

My problem is, the change in behavior.

Before it was possible with a read only rootfs just not to use it.

Now with a read/write rootfs consoles are just recognized as such when it's possible to open them even if they are not in /proc/consoles.

With a read only rootfs plus overlayfs it might work.

> Now with a read/write rootfs consoles are just recognized as such when it's
> possible to open them even if they are not in /proc/consoles.

Sounds like the solution is to add a /proc/consoles check to ttyrun?

... also it would be interesting to investigate what happens with systemd. Some checks are done on every boot, but I did not investigate it further with the latest version.