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

On Thu, 2025-02-20 at 10:35 +0200, Mikko Rapeli wrote:
> 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?

If you shorten the url you can see the list of steps taken:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/994


The failure in this case is from sbsa-ref and the "Write config" just
before that is step 20 which is:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/994/steps/20/logs/stdio

That at least gives you the config of the build. Step 21 builds it,
then step 22 runs the tests which fail.

> 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.

Thanks, and sorry, I thought that was the same failure for some reason.

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

The builds for meta-arm can be found by going to the autobuilder main page:

https://autobuilder.yoctoproject.org/valkyrie/#/

then "Builds" on the LHS sidebar, "Builders", "meta-arm", i.e.:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/75

where the failing builds are:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/986
https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/991
https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/992
https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/994
https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/1001
https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/1003

Cheers,

Richard