Hi, On Thu, Feb 20, 2025 at 09:20:16AM +0000, Richard Purdie wrote: > On Thu, 2025-02-20 at 10:35 +0200, Mikko Rapeli wrote: > > 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.
Thanks, this clarifies things. > > 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. No worries, patches out for both. Hope that helps. > > > > > 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 These are psplash failures and patch is out. > https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/1001 > https://autobuilder.yoctoproject.org/valkyrie/#/builders/75/builds/1003 In these two ssh communication with target timed out: Traceback (most recent call last): File "/srv/pokybuild/yocto-worker/meta-arm/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) File "/srv/pokybuild/yocto-worker/meta-arm/build/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) File "/srv/pokybuild/yocto-worker/meta-arm/build/meta/lib/oeqa/runtime/cases/ssh.py", line 38, in test_ssh self.fail("ssh failed with \"%s\" (exit code %s)" % (output, status)) AssertionError: ssh failed with " Process killed - no output for 30 seconds. Total running time: 35 seconds." (exit code -15) Either target did not boot correctly or was slow to respond, or I've seen these also when no sshd was on target at all, which is the default for core-image-minimal. Thus something in build config must be adding them to target. dropbear was built but I don't see IMAGE_FEATURES += "ssh-server-dropbear" in the build configuration https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/1545775/raw_inline Also https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/1545905/raw_inline shows "Test requires dropbear, or openssh-sshd to be installed" To me this indicates that image doesn't have sshd at all. For meta-arm kas builds this is added by ci/testimage.yml. So this is a bit confusing to me. I don't think the target image has any ssh daemon installed and thus all tests apart from ping and parselog prepare fail. Some tests depend on ssh test but many just try to run ssh commands which time out. One way to fix this is to add sshd/dropbear to the images or make ssh test depend on either one in the image. This is a bit problematic for anyone who tries to run these tests for local builds. The default configs and images will fail tests. Cheers, -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211770): https://lists.openembedded.org/g/openembedded-core/message/211770 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]] -=-=-=-=-=-=-=-=-=-=-=-
