From: Cal Sullivan <california.l.sullivan@intel.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] core-image-minimal-initramfs: use initramfs-framework for initialization
Date: Mon, 5 Feb 2018 17:52:10 -0800 [thread overview]
Message-ID: <fb16c035-aa39-a21f-5bd2-0ebda3dfe3bf@intel.com> (raw)
In-Reply-To: <CAMKF1sp=mb4fMEEu0mkPvvYZYRZXiwtjQ=who4RNVNhQv8=X+Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8241 bytes --]
On 02/05/2018 04:47 PM, Khem Raj wrote:
>
> On Mon, Feb 5, 2018 at 4:15 PM Cal Sullivan
> <california.l.sullivan@intel.com
> <mailto:california.l.sullivan@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@intel.com
>> <mailto:ross.burton@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@intel.com
>> <mailto:california.l.sullivan@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@intel.com
>> <mailto:california.l.sullivan@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@lists.openembedded.org
>> <mailto:Openembedded-core@lists.openembedded.org>
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 18047 bytes --]
next prev parent reply other threads:[~2018-02-06 1:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 22:12 [PATCH] core-image-minimal-initramfs: use initramfs-framework for initialization California Sullivan
2018-01-10 1:00 ` Cal Sullivan
2018-01-31 22:53 ` Cal Sullivan
2018-02-01 14:03 ` Burton, Ross
2018-02-05 23:34 ` Burton, Ross
2018-02-06 0:15 ` Cal Sullivan
2018-02-06 0:47 ` Khem Raj
2018-02-06 1:52 ` Cal Sullivan [this message]
2018-02-06 19:03 ` Cal Sullivan
2018-02-26 20:34 ` Cal Sullivan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb16c035-aa39-a21f-5bd2-0ebda3dfe3bf@intel.com \
--to=california.l.sullivan@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox