From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38D1FC433DB for ; Tue, 23 Mar 2021 17:30:36 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CA81E619C0 for ; Tue, 23 Mar 2021 17:30:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CA81E619C0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zededa.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.100763.192189 (Exim 4.92) (envelope-from ) id 1lOkrB-0007uW-MI; Tue, 23 Mar 2021 17:30:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 100763.192189; Tue, 23 Mar 2021 17:30:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lOkrB-0007uP-JK; Tue, 23 Mar 2021 17:30:17 +0000 Received: by outflank-mailman (input) for mailman id 100763; Tue, 23 Mar 2021 17:30:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lOkrA-0007uI-86 for xen-devel@lists.xenproject.org; Tue, 23 Mar 2021 17:30:16 +0000 Received: from mail-qk1-x734.google.com (unknown [2607:f8b0:4864:20::734]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 140da63a-728f-4ea6-bd66-34e4cdb7b609; Tue, 23 Mar 2021 17:30:14 +0000 (UTC) Received: by mail-qk1-x734.google.com with SMTP id y5so13622641qkl.9 for ; Tue, 23 Mar 2021 10:30:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 140da63a-728f-4ea6-bd66-34e4cdb7b609 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ziSM+HJ4nYNyql8iGyA9YRXdNLvUCpWt7pacIO7qJes=; b=f1nZiT9HFSAxRv0NszJEPC1y5idwqCD5UT6S4IzlEDBghEMlJw7aaJ0pLU/zvkSglY uR603/WiHDPjUsTKtHzeGR5r4Vog2hWpUVCizH6NXW1+z+u9vVZjc3K4ZR9HF4i6B/J+ tkEAeEYIgtz09rY3TdDdZELXdHTB5w/+KA8ijaqafxPSv10LIYS/h7DSBes7n/X3Y7Vi rCDAiHyRlyCJvVKxNr0cB4CMqspDGzjS7IbuPcmLVjsPOMhGtxtmEdJJLnZlgDN/gvtL pWUlYQzTMjWg+UiBTP1F+t56bTLPmijb8tzFJUqn7Jp8xW15X6MVQitW767fs7BnZGyR CBLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ziSM+HJ4nYNyql8iGyA9YRXdNLvUCpWt7pacIO7qJes=; b=Km9hM6RYdU3a/4zlyaggUmHnGCC28hCiyXBhjje7rSHEnZ8TZX1FsUzkiThqAoMpZL pTaTVXUzmwnTIZq/L8/BbYebIwt2m2cr0fjIVEoni6AfNteL2tL5ycSX67xlu08hfa0U O0/wb/79ylXDsr5otnrG2qEE8hNgK/9zFSPam2cvRm/34cNQFZSvjHucM8JjAmpkEfgR vZLz7Y5UGA3Z2x5bGcYv3q8SzQYLD5a5BPWrRSARMP3AVOk5XN58edxngHb6Z4vjShwD bxfbj0/dCjFC9zqrO2IH2Z26GfTT7eOdztVeNPOwxckPPBMHhBuOAYroa/dmSZQzHLk/ NwlA== X-Gm-Message-State: AOAM532szZi+czp4RkJfIsTcyHimkdGYcKR84kQe32uApOWAgvV1Jceh /rwdrbdP1/dnjGOf4KX3J8vaAfb88kxxrYWme6YdOQ== X-Google-Smtp-Source: ABdhPJyqMyhMSLuPxWTMJl3ke4iT2aWMiQO6tW9FQsFG/0ZO7OYb60K5kxiKYsKPwo/bjp5Udx5iKVef2G3wg0UeaLs= X-Received: by 2002:a05:620a:4e6:: with SMTP id b6mr6516819qkh.157.1616520613587; Tue, 23 Mar 2021 10:30:13 -0700 (PDT) MIME-Version: 1.0 References: <20210322133301.11308-1-jandryuk@gmail.com> <09b5e7ee-b44b-a8ab-f29d-6617b6af93a0@citrix.com> <9b071192-a443-4bdc-8dac-107bbd4a0481@suse.com> <4b0ac6fa-cbe2-5b3c-fa61-52d743e07390@suse.com> In-Reply-To: <4b0ac6fa-cbe2-5b3c-fa61-52d743e07390@suse.com> From: Roman Shaposhnik Date: Tue, 23 Mar 2021 10:30:02 -0700 Message-ID: Subject: Re: [PATCH] xen: Create EFI_VENDOR directory To: Jan Beulich Cc: Jason Andryuk , Andrew Cooper , George Dunlap , Ian Jackson , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel Content-Type: multipart/alternative; boundary="000000000000f201c805be378878" --000000000000f201c805be378878 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 23, 2021 at 6:36 AM Jan Beulich wrote: > On 23.03.2021 13:34, Jason Andryuk wrote: > > On Tue, Mar 23, 2021 at 3:23 AM Jan Beulich wrote: > >> > >> On 22.03.2021 18:08, Andrew Cooper wrote: > >>> On 22/03/2021 15:15, Jan Beulich wrote: > >>>> On 22.03.2021 15:59, Andrew Cooper wrote: > >>>>> On 22/03/2021 14:52, Jan Beulich wrote: > >>>>>> On 22.03.2021 14:33, Jason Andryuk wrote: > >>>>>>> make install-xen fails when EFI_VENDOR is set (=fedora) with: > >>>>>>> install: cannot create regular file > '/home/user/xen/dist/install/boot/efi/efi/fedora/xen-4.15.0-rc.efi': No > such file or directory > >>>>>>> > >>>>>>> Create the EFI_VENDOR directory so xen.efi can be installed within. > >>>>>>> > >>>>>>> This removes the need for Fedora and Qubes xen.spec files to > manually > >>>>>>> create the directory in advance. > >>>>>> While I'm not strictly against, I'd like to point out that it was > >>>>>> deliberate to not create this directory here. I also didn't expect > >>>>>> anyone's xen.spec to do so. Instead I'd expect the distro to create > >>>>>> it during OS installation. If this was a bad assumption, I'd prefer > >>>>>> if the commit message here could point out why such an expectation > >>>>>> won't hold in general. > >>>>> This reasoning is broken for anything other `make install DESTDIR=/` > on > >>>>> a live system. > >>>>> > >>>>> It is incompatible with how RPM, deb, etc packages work. > >>>> I'm afraid I don't understand, for both of your statements. If distro > >>>> installation put in place the designated directory, there wouldn't be > >>>> any live system lacking it, and there wouldn't be any concern in the > >>>> packaging of any software. > >>>> > >>>> To take a perhaps too extreme example - packages typically expect e.g. > >>>> /usr to exist as well, don't they? > >>> > >>> No. A buildroot starts out fully empty, by design. > >>> > >>> The packaging environment (usually a chroot) invokes `make install > >>> DESTDIR=/path/to/staging/root` so you don't interfere with any of the > >>> tools inside the environment, and the resulting tar/cpio has the > >>> buildroot stripped out of paths. > >>> > >>> The failure being discussed here is the build within the packaging > >>> environment, not the metadata which forms the final package. > Installing > >>> a deb/rpm/etc will make directories as applicable. > >> > >> Ah, I see. But then this _still_ isn't the right thing to do. In fact, > >> the package build and installation shouldn't put xen.efi in the EFI > >> partition _at all_. The build system doing so is for developers only, > >> so they don't need to invoke boot loader configuration every time they > >> rebuild and re-install. Hence the packaging build shouldn't set > >> EFI_VENDOR in the first place. There it instead should be a subsequent > >> boot loader re-configuration which picks up xen.efi from its install > >> location (under $(EFI_DIR)) and places it on the EFI partition. > > > > On Fedora, RPMs drop EFI binaries directly into /boot/efi/EFI/fedora/. > > grub, shim, fwupdate and xen are all packaged that way. It seems > > reasonable to have those important binaries tracked by the package > > manager. > > > > Does SuSE populate EFI_VENDOR from EFI_DIR when some boot loader > > script is called? > > Yes. And back at the time, when I consulted our EFI person, I was left > with the impression that this is the only reasonable approach. The > primary reason, as said, was that the EFI partition as a whole may get > rebuilt perhaps even from scratch at any point. Hence it's not > reasonable to expect package-managed files to live there. (This is > also expressed by us installing xen.efi into two places, which ought > to be a clear indication by itself that one of them is only to ease > things, not for packaging.) > Big +1 to the above -- in running our own distro we've come to appreciate that very point -- EFI partition is basically a cache and the source of truth is always elsewhere. Thanks, Roman. --000000000000f201c805be378878 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 23, 2021 at 6:36 AM Jan Beuli= ch <jbeulich@suse.com> wrote= :
On 23.03.2021 13:34,= Jason Andryuk wrote:
> On Tue, Mar 23, 2021 at 3:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 22.03.2021 18:08, Andrew Cooper wrote:
>>> On 22/03/2021 15:15, Jan Beulich wrote:
>>>> On 22.03.2021 15:59, Andrew Cooper wrote:
>>>>> On 22/03/2021 14:52, Jan Beulich wrote:
>>>>>> On 22.03.2021 14:33, Jason Andryuk wrote:
>>>>>>> make install-xen fails when EFI_VENDOR is set = (=3Dfedora) with:
>>>>>>> install: cannot create regular file '/home= /user/xen/dist/install/boot/efi/efi/fedora/xen-4.15.0-rc.efi': No such = file or directory
>>>>>>>
>>>>>>> Create the EFI_VENDOR directory so xen.efi can= be installed within.
>>>>>>>
>>>>>>> This removes the need for Fedora and Qubes xen= .spec files to manually
>>>>>>> create the directory in advance.
>>>>>> While I'm not strictly against, I'd like t= o point out that it was
>>>>>> deliberate to not create this directory here. I al= so didn't expect
>>>>>> anyone's xen.spec to do so. Instead I'd ex= pect the distro to create
>>>>>> it during OS installation. If this was a bad assum= ption, I'd prefer
>>>>>> if the commit message here could point out why suc= h an expectation
>>>>>> won't hold in general.
>>>>> This reasoning is broken for anything other `make inst= all DESTDIR=3D/` on
>>>>> a live system.
>>>>>
>>>>> It is incompatible with how RPM, deb, etc packages wor= k.
>>>> I'm afraid I don't understand, for both of your st= atements. If distro
>>>> installation put in place the designated directory, there = wouldn't be
>>>> any live system lacking it, and there wouldn't be any = concern in the
>>>> packaging of any software.
>>>>
>>>> To take a perhaps too extreme example - packages typically= expect e.g.
>>>> /usr to exist as well, don't they?
>>>
>>> No.=C2=A0 A buildroot starts out fully empty, by design.
>>>
>>> The packaging environment (usually a chroot) invokes `make ins= tall
>>> DESTDIR=3D/path/to/staging/root` so you don't interfere wi= th any of the
>>> tools inside the environment, and the resulting tar/cpio has t= he
>>> buildroot stripped out of paths.
>>>
>>> The failure being discussed here is the build within the packa= ging
>>> environment, not the metadata which forms the final package.= =C2=A0 Installing
>>> a deb/rpm/etc will make directories as applicable.
>>
>> Ah, I see. But then this _still_ isn't the right thing to do. = In fact,
>> the package build and installation shouldn't put xen.efi in th= e EFI
>> partition _at all_. The build system doing so is for developers on= ly,
>> so they don't need to invoke boot loader configuration every t= ime they
>> rebuild and re-install. Hence the packaging build shouldn't se= t
>> EFI_VENDOR in the first place. There it instead should be a subseq= uent
>> boot loader re-configuration which picks up xen.efi from its insta= ll
>> location (under $(EFI_DIR)) and places it on the EFI partition. >
> On Fedora, RPMs drop EFI binaries directly into /boot/efi/EFI/fedora/.=
> grub, shim, fwupdate and xen are all packaged that way.=C2=A0 It seems=
> reasonable to have those important binaries tracked by the package
> manager.
>
> Does SuSE populate EFI_VENDOR from EFI_DIR when some boot loader
> script is called?

Yes. And back at the time, when I consulted our EFI person, I was left
with the impression that this is the only reasonable approach. The
primary reason, as said, was that the EFI partition as a whole may get
rebuilt perhaps even from scratch at any point. Hence it's not
reasonable to expect package-managed files to live there. (This is
also expressed by us installing xen.efi into two places, which ought
to be a clear indication by itself that one of them is only to ease
things, not for packaging.)

Big=C2=A0+1= to the above -- in running our own distro we've come to appreciate
that very point -- EFI partition is basically a cache and the source= of truth
is always elsewhere.

Thanks,
Roman.
--000000000000f201c805be378878--