| Message ID | 20250206144406.1328276-1-mikko.rapeli@linaro.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] systemd: use serial-getty-generator on genericarm64 | expand |
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 <mikko.rapeli@linaro.org> > --- > meta/recipes-core/psplash/files/fb.rules | 1 + > .../{psplash-start.service => psplash-start@.service} | 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 => psplash-start@.service} (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 https://gitlab.com/jonmason00/meta-arm/-/jobs/9155263483 but it doesn't always fail. There were other failures if you look through the meta-arm builds. Cheers, Richard
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 <mikko.rapeli@linaro.org> > > --- > > �meta/recipes-core/psplash/files/fb.rules���������������� | 1 + > > �.../{psplash-start.service => psplash-start@.service}��� | 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 => psplash-start@.service} (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
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 <mikko.rapeli@linaro.org> > > > --- > > > meta/recipes-core/psplash/files/fb.rules | 1 + > > > .../{psplash-start.service => psplash-start@.service} | 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 => psplash-start@.service} (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
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 <mikko.rapeli@linaro.org> > > > > --- > > > > �meta/recipes-core/psplash/files/fb.rules���������������� | 1 + > > > > �.../{psplash-start.service => psplash-start@.service}��� | 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 => psplash-start@.service} (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
diff --git a/meta/recipes-core/psplash/files/fb.rules b/meta/recipes-core/psplash/files/fb.rules new file mode 100644 index 0000000000..accdb8386c --- /dev/null +++ b/meta/recipes-core/psplash/files/fb.rules @@ -0,0 +1 @@ +SUBSYSTEM=="graphics", KERNEL=="fb[0-9]*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="psplash-start@%k.service psplash-systemd.service" diff --git a/meta/recipes-core/psplash/files/psplash-start.service b/meta/recipes-core/psplash/files/psplash-start@.service similarity index 84% rename from meta/recipes-core/psplash/files/psplash-start.service rename to meta/recipes-core/psplash/files/psplash-start@.service index bec9368427..1bc3642fc2 100644 --- a/meta/recipes-core/psplash/files/psplash-start.service +++ b/meta/recipes-core/psplash/files/psplash-start@.service @@ -3,11 +3,10 @@ Description=Start psplash boot splash screen DefaultDependencies=no RequiresMountsFor=/run ConditionFileIsExecutable=/usr/bin/psplash +After=dev-%i.device +Wants=dev-%i.device [Service] Type=notify ExecStart=/usr/bin/psplash RemainAfterExit=yes - -[Install] -WantedBy=sysinit.target diff --git a/meta/recipes-core/psplash/files/psplash-systemd.service b/meta/recipes-core/psplash/files/psplash-systemd.service index e93e3deb35..f9aaa2db3d 100644 --- a/meta/recipes-core/psplash/files/psplash-systemd.service +++ b/meta/recipes-core/psplash/files/psplash-systemd.service @@ -1,14 +1,12 @@ [Unit] Description=Start psplash-systemd progress communication helper DefaultDependencies=no -After=psplash-start.service -Requires=psplash-start.service +After=psplash-start@fb0.service +Requires=psplash-start@fb0.service RequiresMountsFor=/run ConditionFileIsExecutable=/usr/bin/psplash +ConditionFileExists=/run/psplash_fifo [Service] ExecStart=/usr/bin/psplash-systemd RemainAfterExit=yes - -[Install] -WantedBy=sysinit.target diff --git a/meta/recipes-core/psplash/psplash_git.bb b/meta/recipes-core/psplash/psplash_git.bb index 30cf61a2cb..fce5995efe 100644 --- a/meta/recipes-core/psplash/psplash_git.bb +++ b/meta/recipes-core/psplash/psplash_git.bb @@ -11,8 +11,9 @@ PV = "0.1+git" SRC_URI = "git://git.yoctoproject.org/${BPN};branch=master;protocol=https \ file://psplash-init \ - file://psplash-start.service \ + file://psplash-start@.service \ file://psplash-systemd.service \ + file://fb.rules \ ${SPLASH_IMAGES}" UPSTREAM_CHECK_COMMITS = "1" @@ -112,8 +113,10 @@ do_install:append() { if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then install -d ${D}${systemd_system_unitdir} - install -m 644 ${UNPACKDIR}/psplash-start.service ${D}/${systemd_system_unitdir} + install -m 644 ${UNPACKDIR}/psplash-start@.service ${D}/${systemd_system_unitdir} install -m 644 ${UNPACKDIR}/psplash-systemd.service ${D}/${systemd_system_unitdir} + install -d ${D}${sysconfdir}/udev/rules.d + install -m 0644 ${UNPACKDIR}/fb.rules ${D}${sysconfdir}/udev/rules.d/ fi install -d ${D}${bindir} @@ -124,7 +127,7 @@ do_install:append() { } SYSTEMD_PACKAGES = "${@bb.utils.contains('DISTRO_FEATURES','systemd','${PN}','',d)}" -SYSTEMD_SERVICE:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'systemd', 'psplash-start.service psplash-systemd.service', '', d)}" +SYSTEMD_SERVICE:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'systemd', 'psplash-start@.service psplash-systemd.service', '', d)}" INITSCRIPT_NAME = "psplash.sh" INITSCRIPT_PARAMS = "start 0 S . stop 20 0 1 6 ."
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 <mikko.rapeli@linaro.org> --- meta/recipes-core/psplash/files/fb.rules | 1 + .../{psplash-start.service => psplash-start@.service} | 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 => psplash-start@.service} (84%)