[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xen: Create EFI_VENDOR directory
On 23.03.2021 13:34, Jason Andryuk wrote:
> On Tue, Mar 23, 2021 at 3:23 AM Jan Beulich <jbeulich@xxxxxxxx> 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.
|
