[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |