On 2023/04/23 01:15, Sergii Dmytruk wrote: > Hello, > > Continuing with bringing fwupd to BSD systems [1]. > > [1]: https://nlnet.nl/project/fwdup-BSD/ > > Now that /dev/efi is available, efivar port with several libraries and > binaries can be added to make use of it. efivar itself is a dependency > of fwupd's uefi_capsule plugin which is used to update UEFI firmware of > the host. > > To address a few comments from [email protected] which are more relevant > here: > > Stuart Henderson wrote: > > I found the git repo with fwupd/libgusb/libjcat/libxmlb and have tweaked > > them a bit according to normal ports standards and set it up to install > > the /etc files for fwupd. tar attached. > > > > Might still be some things missing and I haven't tested beyond building > > but this might help others test things. > > Thanks for doing this. Keep in mind that the port has uefi_capsule > plugin disabled as kernel support for ESRT and EFI variables was missing > at the time porting was first attempted. > > Landry Breuil wrote: > > I suppose from all those things, the libexec/fwupd binary > > daemon will be spawned as root by systemwide dbus/messagebus to access > > /dev/efi ? like other needing-root daemons like upowerd & al, with > > access managed by polkit.. > > That's one way of using it. There is also a daemon-less way (fwupdtool > binary). Given that EFI variables are writeable only in single-user > mode, fwupd daemon won't be able to initiate system's firmware update, > but it can be used to update other devices as well as to check for UEFI > firmware updates. > > efivar port attached. > > Best regards, > Sergii
New tgz attached with tweaks: - we can't use -march=native in package builds - shared lib versions must be under control of the SHARED_LIBS variable - don't install shlib symlinks - use category 'sysutils' not 'devel' ports-wise I'm happy with it, but I tried running 'efivar -l' as root and hit a kernel panic but I am on a kernel from a couple of days ago and there's a hackathon on, so that might not have been directly related to efivar / /dev/efi and might have already been fixed, will retest on a newer kernel sometime later or tomorrow.
efivar.tgz
Description: application/tar-gz
