You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have encountered an issue where the usbhid module is missing from the generated initramfs image when no USB devices are connected during the build process. This issue prevents the unlocking of LUKS volumes using FIDO2. It occurs specifically when creating a host-specific image, which only includes kernel modules used by the current host.
Force loading these modules (as in #236, plus hid_generic) is a potential solution, but it was removed in 31d06a4.
The text was updated successfully, but these errors were encountered:
We could, but, strictly in terms of creating a host specific image, isn’t the system working as intended?
But if we want to look into fixing this, instead of force loading, maybe a better idea is for Booster to detect if the user’s root volume was FIDO2 encrypted then include the module. I believe that metadata should be in the LUKS2 header, especially if systemd was used.
Image builds could occur during package updates when the FIDO2 device may not be accessible, which is not the intended behavior for users. I agree that it would be better for Booster to detect the volumes and determine which modules to include accordingly.
I have encountered an issue where the
usbhid
module is missing from the generated initramfs image when no USB devices are connected during the build process. This issue prevents the unlocking of LUKS volumes using FIDO2. It occurs specifically when creating a host-specific image, which only includes kernel modules used by the current host.Force loading these modules (as in #236, plus
hid_generic
) is a potential solution, but it was removed in 31d06a4.The text was updated successfully, but these errors were encountered: