From: Tom Rini <trini@konsulko.com>
To: "Lu.Jiang" <lu.jiang@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 6/7] wic:bootimg-efi:try other place for efi
Date: Wed, 5 Sep 2018 09:41:29 -0400 [thread overview]
Message-ID: <20180905134129.GC26633@bill-the-cat> (raw)
In-Reply-To: <a610db8d-99cc-e256-6c3f-a7a41daf4729@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 6811 bytes --]
On Wed, Sep 05, 2018 at 10:32:32AM +0800, Lu.Jiang wrote:
> 在 2018年09月05日 08:33, Tom Rini 写道:
> >On Tue, Sep 04, 2018 at 10:33:43AM +0800, Lu.Jiang wrote:
> >>在 2018年09月04日 10:26, Tom Rini 写道:
> >>>On Tue, Sep 04, 2018 at 10:15:44AM +0800, Lu.Jiang wrote:
> >>>>在 2018年09月03日 10:01, Lu.Jiang 写道:
> >>>>>在 2018年08月31日 21:52, Tom Rini 写道:
> >>>>>>On Fri, Aug 31, 2018 at 10:15:09AM +0800, Jiang Lu wrote:
> >>>>>>
> >>>>>>>When there is no useful efi in $kerneldir, try copy
> >>>>>>>all efi from EFI/BOOT into boot image.
> >>>>>>>
> >>>>>>>Signed-off-by: Jiang Lu <lu.jiang@windriver.com>
> >>>>>>>---
> >>>>>>> .../wic/files/wic/plugins/source/bootimg-efi.py | 12 ++++++++++++
> >>>>>>> 1 file changed, 12 insertions(+)
> >>>>>>>
> >>>>>>>diff --git
> >>>>>>>a/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
> >>>>>>>b/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
> >>>>>>>index 0eb86a0..d435268 100644
> >>>>>>>--- a/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
> >>>>>>>+++ b/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py
> >>>>>>>@@ -231,6 +231,18 @@ class BootimgEFIPlugin(SourcePlugin):
> >>>>>>> else:
> >>>>>>> raise WicError("unrecognized bootimg-efi loader: %s"
> >>>>>>>%
> >>>>>>> source_params['loader'])
> >>>>>>>+ os.listdir("%s/EFI/BOOT/" % hdddir)
> >>>>>>>+ found_efi = False
> >>>>>>>+ for x in os.listdir("%s/EFI/BOOT/" % hdddir) :
> >>>>>>>+ if x.endswith(".efi"):
> >>>>>>>+ found_efi = True
> >>>>>>>+ break;
> >>>>>>>+ if not found_efi:
> >>>>>>>+ cp_cmd = "cp %s/EFI/BOOT/*.efi %s/EFI/BOOT/" %
> >>>>>>>(kernel_dir, hdddir)
> >>>>>>>+ try:
> >>>>>>>+ exec_cmd(cp_cmd, True)
> >>>>>>>+ except:
> >>>>>>>+ pass
> >>>>>>> except KeyError:
> >>>>>>> raise WicError("bootimg-efi requires a loader, none
> >>>>>>>specified")
> >>>>>>I'm not sure this is the right approach. If you don't have things set
> >>>>>>up for automagic finding you should use bootimg-partition and
> >>>>>>IMAGE_BOOT_FILES. I'm doing this right now for some EFI projects
> >>>>>>because it's also bad form to dump everything into EFI/BOOT and some
> >>>>>>things should end up in EFI/vendorname or similar.
> >>>>>>
> >>>>Hi Tom,
> >>>>
> >>>>By indicating IMAGE_BOOT_FILES for bootimg-partition, can perform copy file
> >>>>work. While we still need the code in bootimg-efi to re-generate grub.cfg.
> >>>>
> >>>>I prefer use bootimg-efi for this case, but we can add a new parameter to
> >>>>distinguish kernel dir & bootloader dir(for efi files)
> >>>I'm still not seeing why we need this, sorry.
> >>>
> >>>If we need files in the ESP in EFI/BOOT/ then in our root filesystem
> >>>they're already in as /boot/efi/EFI/BOOT and we say that we populate
> >>>things from /boot/efi and this also gets us things like
> >>>/boot/efi/EFI/vendor and so forth populated and matches other Linux
> >>>distributions.
> >>>
> >>>If we need something more complex, we have IMAGE_BOOT_FILES available
> >>>and can and should be populating the deploy directory like other
> >>>architectures and loaders do.
> >>>
> >>bootimg-efi performed following for grub boot partition:
> >>
> >>1.copy grub-efi-* from $KERNEL_DIR into $/boot/EFI/BOOT/
> >>
> >>2.copy bzImage from $KERNEL_DIR into $/boot/
> >>
> >>3.generate grub.cfg based select booting device.
> >>
> >>On target system, if we select booting device from running system as source
> >>for booting-efi will meet issue. Because the *.efi & bzImage is not in the
> >>same directory.
> >>
> >>As you suggested, we may invoke booting-partition by feeding
> >>$IMAGE_BOOT_FILES to indicating file need copy, this could done work 1 & 2.
> >>While we still need generated grub.cfg.
> >One of the great strengths of wic is that it can cover a lot of
> >different fairly complex use cases automatically, and still provide an
> >expert "out" for when you're doing something fairly different but still
> >want to leverage wic. While I don't understand the use case of turning
> >a live system into a wic image, it sounds like what you're looking for
> >is the case of "and we provide our own loader config file". You should
> >be including grub.cfg into the IMAGE_BOOT_FILES list and generate this
> >however you need it. Since you've already booted you should already
> >have a correct EFI/ directory to look at (we ought to stop having
> >top-level bzImage, that's not right, but that's orthogonal to this
> >thread).
>
> The grub.cfg is generated in bootimg-efi.py. At least, it need include the
> new generated uuid info for rootfs partition.
Or, you generate the grub.cfg outside of wic and tell wic what newly
generated UUIDs to use, and just use bootimg-partition.py and
IMAGE_BOOT_FILES.
> So we still need a piece of code from bootimg-efi.py to generate grub.cfg at
> runtime.
>
> The issue this patch try to fix is bootimg-efi assume bzImage & grub-*.efi
> located at top level of $KERNEL_DIR.
(aside, OE $DEPLOY_DIR_IMAGE becomes do_prepare_partition() kernel_dir)
Yes, this particular bit of code very much assumes an OE environment as
you don't normally see grub-efi-*.efi nor systemd-*.efi like that on the
system, and a real problem is that we don't package and ship those files
(I know for grub, I guess but didn't check systemd).
> This is true for bitbake's deploy dir. However, it didn't apply to target.
> We need provide a way for adding search path for *.efi.
I disagree that we need to because in this case you only need to because
the EFI binaries don't exist on the target in a normal way.
All of that said, perhaps a different way to look at this would be that
we could try doing both of:
- packaging and shipping grub-efi-*.efi (and systemd-boot equivalents)
- Similar to how plugins/imager/direct.py can fiddle with /etc/fstab add
some option to fiddle the various known loader config files to whack
'root=PARTUUID=well-formatted-uuid' to the new UUID.
Then you shouldn't need to generate a new grub.cfg and should be able to
use IMAGE_BOOT_FILES to map things to where you want them to go and
still get your grub.cfg file updated.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2018-09-05 13:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-31 2:15 [v2] [PATCH 0/7] wic:allow wic compile as an individual package Jiang Lu
2018-08-31 2:15 ` [PATCH 1/7] wic:enable wic compile as " Jiang Lu
2018-08-31 2:15 ` [PATCH 2/7] wic:move wic src into meta/receipt-support/wic Jiang Lu
2018-08-31 13:53 ` Tom Rini
2018-09-03 1:58 ` Lu.Jiang
2018-09-03 2:50 ` Tom Rini
2018-09-03 15:14 ` Tim Orling
2018-09-04 2:10 ` Lu.Jiang
2018-08-31 2:15 ` [PATCH 3/7] image_type_wic:add wic-native into depend Jiang Lu
2018-08-31 2:15 ` [PATCH 4/7] wic:allow wic run outof bb enviroment Jiang Lu
2018-08-31 2:15 ` [PATCH 5/7] wic:direct:remove same entry when updating fstab Jiang Lu
2018-08-31 13:54 ` Tom Rini
2018-09-03 2:00 ` Lu.Jiang
2018-09-03 2:51 ` Tom Rini
2018-08-31 2:15 ` [PATCH 6/7] wic:bootimg-efi:try other place for efi Jiang Lu
2018-08-31 13:52 ` Tom Rini
2018-09-03 2:01 ` Lu.Jiang
2018-09-04 2:15 ` Lu.Jiang
2018-09-04 2:26 ` Tom Rini
2018-09-04 2:33 ` Lu.Jiang
2018-09-05 0:33 ` Tom Rini
2018-09-05 2:32 ` Lu.Jiang
2018-09-05 13:41 ` Tom Rini [this message]
2018-08-31 2:15 ` [PATCH 7/7] wic:mkefidisk:add use-uuid for all partitions Jiang Lu
2018-08-31 13:55 ` Tom Rini
2018-09-07 3:02 ` [v2] [PATCH 0/7] wic:allow wic compile as an individual package Lu.Jiang
2018-09-07 12:19 ` Tom Rini
-- strict thread matches above, loose matches on Subject: below --
2018-08-30 10:01 Jiang Lu
2018-08-30 10:01 ` [PATCH 6/7] wic:bootimg-efi:try other place for efi Jiang Lu
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=20180905134129.GC26633@bill-the-cat \
--to=trini@konsulko.com \
--cc=lu.jiang@windriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.