Re: [poky] [PATCH 2/2] psplash: start via udev if framebuffer device detected

Hi,

On Wed, Feb 19, 2025 at 03:59:59PM +0000, Richard Purdie wrote:
> On Thu, 2025-02-06 at 16:44 +0200, Mikko Rapeli via lists.yoctoproject.org wrote:
> > psplash-start.service expected to find /dev/fb0 and failed
> > if device was not found. This failure breaks systemd
> > oeqa runtime test with "runqemu nographic". Starting
> > psplash based on detected framebuffer device fixes systemd
> > boot status and systemd oeqa runtime tests for qemu
> > boots with and without graphics support.
> > 
> > Note that psplash-systemd.service still depends on /dev/fb0
> > so startup with multiple framebuffer devices may not work
> > correctly. I don't have devices with multiple framebuffer
> > devices to test with.
> > 
> > On qemu machine with graphics, psplash displays yocto
> > logo correctly and boot progress bar as well. Once boot completes
> > to systemd "running" state, the logo is replaced by login prompt.
> > On qemu machine without graphics, boot completes without psplash
> > or failures and login over serial console works normally.
> > Tested with genericarm64 machine poky-altcfg distro and core-image-base
> > image on qemu. AMD kv260 tested as well but graphics stack is not yet
> > working there so boot is similar to qemu without graphics.
> > 
> > Signed-off-by: Mikko Rapeli <[email protected]>
> > ---
> > �meta/recipes-core/psplash/files/fb.rules���������������� | 1 +
> > �.../{psplash-start.service => [email protected]}��� | 5 ++---
> > �meta/recipes-core/psplash/files/psplash-systemd.service� | 8 +++-----
> > �meta/recipes-core/psplash/psplash_git.bb���������������� | 9 ++++++---
> > �4 files changed, 12 insertions(+), 11 deletions(-)
> > �create mode 100644 meta/recipes-core/psplash/files/fb.rules
> > �rename meta/recipes-core/psplash/files/{psplash-start.service => [email protected]} (84%)
> 
> Unfortunately I think this has introduced an intermittent QA test
> failure showing up in meta-arm in particular. Examples:
> 
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/994/steps/22/logs/stdio

Feb 19 01:26:42 sbsa-ref psplash-systemd[261]: Error unable to open fifo

This means psplash.service did not start or did not yet create it. Can I somehow see the
build and boot configuration?

Feb 19 01:27:12 sbsa-ref systemd[1]: /usr/lib/systemd/system/psplash-systemd.service:8: Unknown key 'ConditionFileExists' in section [Unit], ignoring.
Feb 19 01:27:26 sbsa-ref systemd[1]: /usr/lib/systemd/system/psplash-systemd.service:8: Unknown key 'ConditionFileExists' in section [Unit], ignoring.

psplash.service is of type notify and fifo is created before systemd is notified, but
the fifo creation could also fail due to other reasons which I can't see from the logs.

Fixing the condition will fix the systemd test failure but plsplash and progress
bar may have functional failures.

I will send a patch.

> https://gitlab.com/jonmason00/meta-arm/-/jobs/9155263483

This looks like something completely different:

2025-02-17 22:43:20 - INFO     - AssertionError: 3 != 0 : SYSTEMD_BUS_TIMEOUT=240s systemctl status --full --failed
2025-02-17 22:43:20 - INFO     - x dev-disk-by\x2duuid-38d0b388\x2d9989\x2d4744\x2d8a0a\x2d3e6be1135f5a.swap - /dev/disk/by-uuid/38d0b388-9989-4744-8a0a-3e6be1135f5a
2025-02-17 22:43:20 - INFO     - Loaded: loaded (/etc/fstab; generated)
2025-02-17 22:43:20 - INFO     - Active: failed (Result: exit-code) since Mon 2025-02-17 22:41:32 UTC; 20min left
2025-02-17 22:43:20 - INFO     - Invocation: 6e51ad1d846f4e8cbb129f05d75ac240
2025-02-17 22:43:20 - INFO     - What: /dev/disk/by-uuid/38d0b388-9989-4744-8a0a-3e6be1135f5a
2025-02-17 22:43:20 - INFO     - Docs: man:fstab(5)
2025-02-17 22:43:20 - INFO     - man:systemd-fstab-generator(8)
2025-02-17 22:43:20 - INFO     - Mem peak: 1.7M
2025-02-17 22:43:20 - INFO     - CPU: 198ms
2025-02-17 22:43:20 - INFO     - 
2025-02-17 22:43:20 - INFO     - Feb 17 22:41:32 sbsa-ref systemd[1]: Activating swap /dev/disk/by-uuid/38d0b388-9989-4744-8a0a-3e6be1135f5a...
2025-02-17 22:43:20 - INFO     - Feb 17 22:41:32 sbsa-ref swapon[210]: swapon: /dev/sda3: swap format pagesize does not match.
2025-02-17 22:43:20 - INFO     - Feb 17 22:41:32 sbsa-ref swapon[210]: swapon: /dev/sda3: reinitializing the swap.
2025-02-17 22:43:20 - INFO     - Feb 17 22:41:32 sbsa-ref swapon[212]: mkswap: invalid option -- 'U'
2025-02-17 22:43:20 - INFO     - Feb 17 22:41:32 sbsa-ref swapon[212]: BusyBox v1.37.0 () multi-call binary.
2025-02-17 22:43:20 - INFO     - Feb 17 22:41:32 sbsa-ref swapon[212]: Usage: mkswap [-L LBL] BLOCKDEV [KBYTES]
2025-02-17 22:43:20 - INFO     - Feb 17 22:41:32 sbsa-ref systemd[1]: dev-disk-by\x2duuid-38d0b388\x2d9989\x2d4744\x2d8a0a\x2d3e6be1135f5a.swap: Swap process exited, code=exited, status=255/EXCEPTION
2025-02-17 22:43:20 - INFO     - Feb 17 22:41:32 sbsa-ref systemd[1]: dev-disk-by\x2duuid-38d0b388\x2d9989\x2d4744\x2d8a0a\x2d3e6be1135f5a.swap: Failed with result 'exit-code'.
2025-02-17 22:43:20 - INFO     - Feb 17 22:41:32 sbsa-ref systemd[1]: Failed to activate swap /dev/disk/by-uuid/38d0b388-9989-4744-8a0a-3e6be1135f5a.

So these could be fixed by adding util-linux-mkswap to the images instead of
relying on busybox?

I will send a patch.

> but it doesn't always fail. There were other failures if you look
> through the meta-arm builds.

Link to the builds?

Cheers,

-Mikko