From: Patrick Ohly <patrick.ohly@intel.com>
To: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] bootimg-efi.py: Use IMGDEPLOYDIR instead of DEPLOY_DIR_IMAGE for initrd
Date: Sat, 01 Jul 2017 17:09:50 +0200 [thread overview]
Message-ID: <1498921790.5259.34.camel@intel.com> (raw)
In-Reply-To: <c36489e7-90fa-ebc5-afac-6a56525e2f35@linux.intel.com>
On Fri, 2017-06-30 at 15:38 -0500, Alejandro Hernandez wrote:
> Hey Patrick,
>
>
> On 06/30/2017 01:43 PM, Patrick Ohly wrote:
> > On Fri, 2017-06-30 at 10:53 -0700, Alejandro Hernandez wrote:
> >> When using wic to create an image from a certain build, wic is expecting
> >> to find initrd at the final destination of our images (DEPLOY_DIR_IMAGE),
> >> which is wrong, since the initrd file has not been copied to the final
> >> directory yet, so instead of trying to use an initrd file from
> >> DEPLOY_DIR_IMAGE we get it from IMGDEPLOYDIR, which is the directory
> >> where the resulting images are placed before their final destination,
> >> and its where we can find the correct initrd file for our image.
> > Can you give an example with some real image and initramfs recipe where
> > this works? In other words, provide an example where the old behavior
> > fails and the new one works?
> Sure, so the problem comes when you add "wic" to IMAGE_FSTYPES (which is
> not default for core-image-minimal nor core-image-minimal-initramfs).
> If you do this, do_image_wic will be executed automatically, and if it
> tries to use foo.cpio.gz file as initrd, it will fail to find it on
> DEPLOY_DIR_IMAGE (unless a previous build was completed without
> executing do_image_wic) since this file is still on IMGDEPLOYDIR and hasnt
> been copied to DEPLOY_DIR_IMAGE yet.
>
> So a real example on real hardware:
>
> if you build:
> DISTRO="poky-tiny"
> MACHINE="intel-corei7-64"
> bitbake core-image-tiny-initramfs
>
> You'll get an error stating that the foo.cpio.gz file cant be found.
Just for completeness, foo.cpio.gz =
core-image-tiny-initramfs-intel-corei7-64.cpio.gz, which is the
initramfs image produced by the recipe itself.
Is it really intended that do_image_wic runs for
core-image-tiny-initramfs? How and where is the output of
core-image-tiny-initramfs used?
From the DESCRIPTION:
core-image-tiny-initramfs doesn't actually generate an image but
rather generates boot and rootfs artifacts into a common
location that can subsequently be picked up by external image
generation tools such as wic.
If core-image-tiny-initramfs is meant to produce an initramfs, similar
to core-image-minimal-initramfs, then it shouldn't use "wic" in its
IMAGE_FSTYPES. Currently "wic" is listed:
# don't actually generate an image, just the artifacts needed for one
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES} wic"
Does the recipe still work as intended without your patch when you
remove wic here?
> I did a build for both core-image-minimal and
> core-image-minimal-initramfs and I dont see how theyre affected, the
> necessary files are
> on IMGDEPLOYDIR in both cases as well.
Are you sure that core-image-minimal copies an initrd in bootimg-efi.py?
It checks source_params, but systemd-bootdisk.wks does not specify an
initrd in its sourceparams:
part /boot --source bootimg-efi --sourceparams="loader=systemd-boot"
--ondisk sda --label msdos --active --align 1024
That's different for the systemd-bootdisk-tiny64.wks that is used for
core-image-tiny-initramfs, which has:
part /boot --source bootimg-efi
--sourceparams="loader=systemd-boot,initrd=core-image-tiny-initramfs-intel-corei7-64.cpio.gz" --ondisk sda --label msdos --active --align 1024
I still think your patch breaks images which use the initrd parameter to
reference an initrd produced by some other recipe.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2017-07-01 15:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-30 17:53 [PATCH] bootimg-efi.py: Use IMGDEPLOYDIR instead of DEPLOY_DIR_IMAGE for initrd Alejandro Hernandez
2017-06-30 18:43 ` Patrick Ohly
2017-06-30 20:38 ` Alejandro Hernandez
2017-07-01 15:09 ` Patrick Ohly [this message]
2017-07-01 21:48 ` Alejandro Hernandez
2017-07-03 6:45 ` Patrick Ohly
2017-07-03 9:06 ` Ed Bartosh
2017-07-03 8:36 ` Ed Bartosh
2017-07-03 9:27 ` Patrick Ohly
2017-07-03 12:44 ` Ed Bartosh
2017-07-03 14:10 ` Patrick Ohly
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=1498921790.5259.34.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=alejandro.hernandez@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
/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