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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211743): https://lists.openembedded.org/g/openembedded-core/message/211743 Mute This Topic: https://lists.openembedded.org/mt/111271598/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
