From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mail.openembedded.org (Postfix) with ESMTP id D62257782F for ; Fri, 29 Sep 2017 13:46:39 +0000 (UTC) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP; 29 Sep 2017 06:46:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,452,1500966000"; d="scan'208";a="317685875" Received: from linux.intel.com ([10.54.29.200]) by fmsmga004.fm.intel.com with ESMTP; 29 Sep 2017 06:46:40 -0700 Received: from linux.intel.com (vmed.fi.intel.com [10.237.72.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by linux.intel.com (Postfix) with ESMTPS id AB0065802BB; Fri, 29 Sep 2017 06:46:39 -0700 (PDT) Date: Fri, 29 Sep 2017 16:44:54 +0300 From: Ed Bartosh To: Tom Rini Message-ID: <20170929134454.w4hm54uvbjbpwmba@linux.intel.com> Reply-To: ed.bartosh@linux.intel.com References: <1505923407-31734-1-git-send-email-trini@konsulko.com> <20170928154707.362zfbhccbydkdox@linux.intel.com> <20170928174429.GO3112@bill-the-cat> <20170929112757.xrhavs2uctb6iog7@linux.intel.com> <20170929123542.GU3112@bill-the-cat> MIME-Version: 1.0 In-Reply-To: <20170929123542.GU3112@bill-the-cat> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: NeoMutt/20170421 (1.8.2) Cc: Christopher Larson , openembedded-core@lists.openembedded.org Subject: Re: [PATCH] wic: Generate startup.nsh for EFI cases if none found 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: Fri, 29 Sep 2017 13:46:40 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 29, 2017 at 08:35:42AM -0400, Tom Rini wrote: > On Fri, Sep 29, 2017 at 02:27:57PM +0300, Ed Bartosh wrote: > > On Thu, Sep 28, 2017 at 01:44:29PM -0400, Tom Rini wrote: > > > On Thu, Sep 28, 2017 at 06:47:07PM +0300, Ed Bartosh wrote: > > > > On Wed, Sep 20, 2017 at 12:03:27PM -0400, Tom Rini wrote: > > > > > In the case of non-wic images there is logic today to generate a > > > > > startup.nsh file that will be executed by EFI to run the loader that the > > > > > image contains. In the WIC case is currently depends on that file being > > > > > generated elsewhere and placed in DEPLOY_DIR_IMAGE and only used if > > > > > present there. > > > > > > > > What's wrong with this approach? > > > > > > No one ever provides a startup.nsh and everyone that wants one creates > > > the same one line trivial example. The end result is that no WIC images > > > are Just Bootable on UEFI systems unless you first go and spell that out > > > as the desired booting device. This isn't an awesome workflow which is > > > why the non-WIC cases make the required startup.nsh :) > > > > Would it be better if EFI providers create this file? > > > > I still believe that wic should't hack the filesystem content unless > > it's really unavoidable. So far I know only one exception: updating > > /etc/fstab. And even that is not always needed (see --no-update-fstab > > patchset for further details.) > > Well, it depends on your view of who is supposed to do what. Today, in > wic BootimgEFIPlugin mirrors the efi_populate() function of > systemd-boot/grub-efi.bbclass. I'd call this unnecessary duplication. This content should be prepared by EFI provider class or recipe and taken by wic as is, without modification. I did some work on this: http://lists.openembedded.org/pipermail/openembedded-core/2017-May/136656.html If this or similar approach is accepted wic wouldn't need most of boot plugings. Boot partition can be prepared out of bootfs directory using rootfs plugin. > That's where startup.nsh is made because > it needs to know the name of the EFI application (also technically the > path, but EFI\BOOT\ is spec mandatated I believe). So we can't > easily make the deploy functions create startup.nsh without duplicating > logic from the bbclasss. > > > > > I'd be happy to make wic to do only partitioning and assembling the > > > > image and avoiding to modify image content as much as possible. > > > > That would make wic design much more clear and let us to remove > > > > a lot of duplication between wic and meta/classes code. > > > > > > > > Regarding boot partition content, I think preparing it from bootfs > > > > directory the same way as it's done for root partition is the way to go. > > > > You can find more details about it here: > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10073 > > > > > > I don't conceptually see a problem with going that route. But today WIC > > > images aren't nearly as useful as they could be, with a rather tiny > > > change. > > > > If we agree that wic should avoid modifying content then the obvious way > > to solve this is to provide required content (startup.nsh in this case) > > either by EFI related recipes or core classes. > > Maybe I have to change my mind after thinking harder :) Where's the > logic that creates the boot partition now? > Now it's in several places: in meta/classes, efi recipes and wic. I think wic should be removed from this list. It's not a wic job to prepare boot content. > > > My patch is also a regression-fix, I believe, in that at some point in > > > the past, when Christopher's patch went in, things were laid out such > > > that startup.nsh was often/always generated by another class and placed > > > where WIC would find it and copy it in. At some point that was > > > broken/changed, and no one noticed / was interested enough to fix it. > > > > If this functionality is covered by wic test suite this wouldn't > > happen. > > Once we agree on what the fix looks like, I'll see if I can figure out > how to add in another test. :) -- Regards, Ed