[OE-core] [PATCH] core-image-minimal-initramfs: use initramfs-framework for initialization

Cal Sullivan california.l.sullivan at intel.com
Tue Feb 6 19:03:40 UTC 2018


Shortly after leaving work last night I realized that this error should 
have nothing to do with the initrd/initramfs, as this wic image is not 
using one.

Also, in 300 runs of this test the error didn't occur once, so it 
appears to be very rare.

---
Cal

On 02/05/2018 05:52 PM, Cal Sullivan wrote:
>
>
> On 02/05/2018 04:47 PM, Khem Raj wrote:
>>
>> On Mon, Feb 5, 2018 at 4:15 PM Cal Sullivan 
>> <california.l.sullivan at intel.com 
>> <mailto:california.l.sullivan at intel.com>> 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 <ross.burton at intel.com
>>>     <mailto:ross.burton at intel.com>> 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
>>>         <california.l.sullivan at intel.com
>>>         <mailto:california.l.sullivan at intel.com>> 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
>>>                     <california.l.sullivan at intel.com
>>>                     <mailto:california.l.sullivan at intel.com>>
>>>                     ---
>>>                      
>>>                     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
>>>             Openembedded-core at lists.openembedded.org
>>>             <mailto:Openembedded-core at lists.openembedded.org>
>>>             http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>>
>>>
>>
>>     --
>>     _______________________________________________
>>     Openembedded-core mailing list
>>     Openembedded-core at lists.openembedded.org
>>     <mailto:Openembedded-core at lists.openembedded.org>
>>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180206/b0406f7c/attachment-0002.html>


More information about the Openembedded-core mailing list