On 02/05/2018 04:47 PM, Khem Raj wrote:
On Mon, Feb 5, 2018 at 4:15 PM Cal Sullivan
<[email protected]
<mailto:[email protected]>> wrote:
Looking at the test and the output, its expecting /dev/sda3 to be
mounted as /media and /dev/sda4 to be mounted as /mnt. With this
test result, there is no /media, and instead /dev/sda3 is mounted
to /mnt.
That seems odd to me unless that partition either wasn't created
or went entirely undetected.
I'll take a closer look, I think there's more going on here.
Udev trigger sometimes get ignored have seem that in past
Thanks for the info Khem! I think its an intermittent issue unrelated to
this patch.
I ran the following with my patch applied on top of master and only
SANITY_TESTED_DISTROS changed in local.conf:
MACHINE=qemux86-64 oe-selftest -r wic.Wic.test_qemu
And it didn't fail.
I'm going to run this test a few hundred times overnight without my
patch and see if I can hit it.
Thanks,
Cal
---
Cal
On 02/05/2018 03:34 PM, Burton, Ross wrote:
This is causing the qemu boot wic test to fail in oe-selftest:
2018-02-05 15:08:41,786 - oe-selftest - INFO - FAIL [64.639s]:
test_qemu (wic.Wic)
2018-02-05 15:08:41,786 - oe-selftest - INFO -
----------------------------------------------------------------------
2018-02-05 15:08:41,786 - oe-selftest - INFO - Traceback (most
recent call last):
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/core/decorator/__init__.py",
line 32, in wrapped_f
return func(*args, **kwargs)
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/selftest/cases/wic.py",
line 58, in wrapped_f
return func(*args, **kwargs)
File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/selftest/cases/wic.py",
line 637, in test_qemu
self.assertEqual(output, '/dev/root /\r\n/dev/sda1
/boot\r\n/dev/sda3 /mnt')
AssertionError: '/dev/root /\r\n/dev/sda1 /boot\r\n/dev/sda3
/media\r\n/dev/sda4 /mnt' != '/dev/root /\r\n/dev/sda1
/boot\r\n/dev/sda3 /mnt'
/dev/root /
/dev/sda1 /boot
- /dev/sda3 /media
- /dev/sda4 /mnt? ^
+ /dev/sda3 /mnt? ^
Presumably this is the initramfs mounting more stuff
automatically? I don't have an opinion right now as to whether
this is a problem with the initramfs or the test case being too
strict...
Ross
On 1 February 2018 at 14:03, Burton, Ross <[email protected]
<mailto:[email protected]>> wrote:
Sorry, missed this. I'll pull it into MUT and throw it at
the autobuilder...
Ross
On 31 January 2018 at 22:53, Cal Sullivan
<[email protected]
<mailto:[email protected]>> wrote:
Ping.
---
Cal
On 01/09/2018 05:00 PM, Cal Sullivan wrote:
Anything wrong with this? Haven't seen it hit any mut
branches.
Thanks,
Cal
On 12/19/2017 02:12 PM, California Sullivan wrote:
initramfs-framework is more modular and
expandable. This change was
proposed in commit
28fc6ba761ed4a47efa7c43e7f7dff5e2fe72b5e
"core-image-minimal-initramfs: use
initramfs-framework by default" but
reverted due to the selftests
runqemu.RunqemuTests.test_boot_machine_iso
and runqemu.RunqemuTests.test_boot_deploy_hddimg
failing. Since then,
the kinks have been worked out, and missing
functionality that had been
missed (non-EFI installation module) has been added.
Since the PACKAGE_INSTALL variable was getting so
long with all these
individual modules getting added, I also
introduced a new
INITRAMFS_SCRIPTS variable to the
core-image-minimal-initramfs recipe.
This variable makes the recipe look much cleaner,
and also allows easier
replacement or additions to the scripts.
Fixes [YOCTO #10987].
Signed-off-by: California Sullivan
<[email protected]
<mailto:[email protected]>>
---
meta/recipes-core/images/core-image-minimal-initramfs.bb
<http://core-image-minimal-initramfs.bb> | 10
+++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
a/meta/recipes-core/images/core-image-minimal-initramfs.bb
<http://core-image-minimal-initramfs.bb>
b/meta/recipes-core/images/core-image-minimal-initramfs.bb
<http://core-image-minimal-initramfs.bb>
index 5794a25952a..a9ba91bd310 100644
---
a/meta/recipes-core/images/core-image-minimal-initramfs.bb
<http://core-image-minimal-initramfs.bb>
+++
b/meta/recipes-core/images/core-image-minimal-initramfs.bb
<http://core-image-minimal-initramfs.bb>
@@ -3,7 +3,15 @@ DESCRIPTION = "Small image
capable of booting a device. The kernel includes \
the Minimal RAM-based Initial Root Filesystem
(initramfs), which finds the \
first 'init' program more efficiently."
-PACKAGE_INSTALL = "initramfs-live-boot
initramfs-live-install initramfs-live-install-efi
${VIRTUAL-RUNTIME_base-utils} udev base-passwd
${ROOTFS_BOOTSTRAP_INSTALL}"
+INITRAMFS_SCRIPTS ?= "\
+ initramfs-framework-base \
+ initramfs-module-setup-live \
+ initramfs-module-udev \
+ initramfs-module-install \
+ initramfs-module-install-efi \
+ "
+
+PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS}
${VIRTUAL-RUNTIME_base-utils} udev base-passwd
${ROOTFS_BOOTSTRAP_INSTALL}"
# Do not pollute the initrd image with rootfs
features
IMAGE_FEATURES = ""
--
_______________________________________________
Openembedded-core mailing list
[email protected]
<mailto:[email protected]>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
[email protected]
<mailto:[email protected]>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
