From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mail.openembedded.org (Postfix) with ESMTP id CC0526E666 for ; Tue, 6 Feb 2018 19:03:39 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 11:03:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,469,1511856000"; d="scan'208,217";a="32521471" Received: from clsulliv.jf.intel.com ([10.7.201.36]) by orsmga002.jf.intel.com with ESMTP; 06 Feb 2018 11:03:40 -0800 From: Cal Sullivan To: Khem Raj References: <20171219221234.21699-1-california.l.sullivan@intel.com> <8686fa07-e2a8-1080-e646-7380437e7338@intel.com> <49611977-aff9-6e13-ab7a-0233208e49b3@intel.com> Message-ID: Date: Tue, 6 Feb 2018 11:03:40 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Cc: OE-core Subject: Re: [PATCH] core-image-minimal-initramfs: use initramfs-framework for initialization X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 19:03:40 -0000 Content-Type: multipart/alternative; boundary="------------D0CA8B0A63233E2382DAE363" Content-Language: en-US --------------D0CA8B0A63233E2382DAE363 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 >> > > 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 >> > 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 >>> >> > 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 >>> >> > >>> --- >>>   >>> meta/recipes-core/images/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 >>> >>> b/meta/recipes-core/images/core-image-minimal-initramfs.bb >>> >>> index 5794a25952a..a9ba91bd310 100644 >>> --- >>> a/meta/recipes-core/images/core-image-minimal-initramfs.bb >>> >>> +++ >>> b/meta/recipes-core/images/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 >>> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >>> >>> >>> >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> > --------------D0CA8B0A63233E2382DAE363 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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@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> 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> 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>
---
  meta/recipes-core/images/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 b/meta/recipes-core/images/core-image-minimal-initramfs.bb
index 5794a25952a..a9ba91bd310 100644
--- a/meta/recipes-core/images/core-image-minimal-initramfs.bb
+++ b/meta/recipes-core/images/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
http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


--------------D0CA8B0A63233E2382DAE363--