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 97DFD6006E for ; Fri, 29 Sep 2017 11:29:42 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP; 29 Sep 2017 04:29:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,452,1500966000"; d="scan'208";a="1176993377" Received: from linux.intel.com ([10.54.29.200]) by orsmga001.jf.intel.com with ESMTP; 29 Sep 2017 04:29:43 -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 502405802BB; Fri, 29 Sep 2017 04:29:42 -0700 (PDT) Date: Fri, 29 Sep 2017 14:27:57 +0300 From: Ed Bartosh To: Tom Rini Message-ID: <20170929112757.xrhavs2uctb6iog7@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> MIME-Version: 1.0 In-Reply-To: <20170928174429.GO3112@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 11:29:42 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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.) > > > 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. > 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. -- Regards, Ed