[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen: Create EFI_VENDOR directory



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?

I think Xen's population of EFI_VENDOR is sensible and fine.  Plus
it's *used*.  I don't see why it needs to be removed.  I was just
trying to fix a bug.

Regards,
Jason



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.