zfsbootmenu, linux-image-siduction-amd64 efivars not present (mitigated)

[exovert]

Utilising, it is understood a non-standard configuration, with siduction booting into zfsbootmenu on zfs root -

Issue - unable to run fwupdmgr from siduction - unable to find efi variables -> efi variables not populating.


Other installs under zfsbootmenu (fedora 41, debian 12) on the device can access efivarfs & fwupdmgr (confirming booting efi mode). A minimal Debian 12, in particular could remain indefinitely to run fwupdmgr though ideally would all run from within siduction.

vars not found:
mount -t efivarfs efivarfs /sys/firmware/efi/efivars

└ % sudo mount -t efivarfs efivarfs /sys/firmware/efi/efivars
mount: /sys/firmware/efi/efivars: fsopen() failed: Operation not supported.
       dmesg(1) may have more information after failed mount system call.

no pertinent info in dmesg.

`lsmod |grep efi`
(no output)

`modprobe efivarfs`
(no output, command returned 0)


Kernel command line: `root=zfs:zroot/ROOT/siducer quiet rhgb efi=runtime` [hw opts omitted for clarity, full info in dmesg]

find /lib/modules |grep efi
└ % find /lib/modules |grep efi
/lib/modules/6.14.7-1-siduction-amd64/kernel/drivers/firmware/efi
/lib/modules/6.14.7-1-siduction-amd64/kernel/drivers/firmware/efi/efibc.ko
/lib/modules/6.14.7-1-siduction-amd64/kernel/drivers/firmware/efi/capsule-loader.ko

(current siduction image at time of check)

noted, that with presuambly the vanilla debian kernels:
└ % apt-file search efivarfs.ko
linux-image-6.12.27-amd64: /usr/lib/modules/6.12.27-amd64/kernel/fs/efivarfs/efivarfs.ko.xz

these do contain a module;

implying siduction builds it into the kernel
-> try 6.12.27

└ % uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.12.27-1 (2025-05-06)
└ % efibootmgr
BootCurrent: 0001


[...]

└ % fwupdmgr get-updates
Devices with no available firmware updates:


(success)

- ideally the siduction linux-image would be fully operable even in this circumstance, although there's further merit with zfs in tracking a little behind while its out of tree module development catches up (the two factors together might settle it).

It does however seem like it should work - it could easily (despite no leads from apt-file) be packages removed in course of either of, and especially a) ripping out grub, or b) manually removing newer kernels when the 6.14 cycle was new for zfs to catch up (and also now reverted, with the linux-image-siduction-amd64 metapackage depending).

Thanks for any thoughts on areas to look into further.

[devil]

Hi,
you did not specify why you want to use ZFS. Are you aware, that we offer full support for snapshots with snapper when installing with Btrfs?

[ro_sid]

For me - not using zfs, though - efivars is just available under /sys/firmware/efi/efivars, even without my explicit mount. Please have a look there. Not present?
[efibootmgr seems to confirm that you booted into (U)EFI mode!]

[exovert]

Thank you, I have 2 different ways of still being able to run fwupdmgr, and I can live without efivarfs on day to day if it came to it (if not, 6.12 is new enough for the device, even if it's not siduction's build of the kernel). I'm now more in a state of being curious as to what may be preventing the siduction linux image(s - using for ~ 2-3 months now) from exposing these - I'm sure there will be reasons (possibly packages not expected for users to be removing) and it seems informative why it'd be different. It'd be nicer to run it.

I didn't have a parallel (standard) siduction install anymore to compare if the efivars would be present, though I'd have thought it unlikely efivars were anywhere other than the default location. Are the efivarfs.ko modules also not present then (apt-file doesn't suggest they should be for these kernels, but this is sensible if it is built into the kernel, even if that runs me out of leads).


I did consider a standard install at the time on crypttab/btrfs, though I already had zfsbootmenu (& OS, data) on the device which has features I like, fits in directly with my backup, & to which I'm more familiar - To see what happened, based on adjusting the bookworm instructions I did a lift & shift of the already configured (without crypttab) siduction from ext storage where I'd been experimenting with it, and into the already encrypted zfs pool to see how far I could get and this turns out was (almost) without new seams. This is the the high watermark for the features/functions I wanted.

[ro_sid]

For your cuirosity my information comes from a system:

(Selfbuilt) Siduction-KDE-Live, kernel "Linux siduction 6.14.6-1-siduction-amd64 #1 SMP PREEMPT_DYNAMIC siduction 6.14-6 (2025-05-09) x86_64 GNU/Linux", UEFI-bootet, nothing with the letters "efi" (regardless of capitalization) in the modules.
Squashfile is copied to RAM and most likely of type ext4 there (overlay fs).
Nevertheless there is a 'directory' efivars/ in /sys/firmware/efi/ containing about 173 entries.