Recent admincd-amd64-20240428T163427Z.iso include grub without device-mapper support. Hence grub-install failed with luks encrypted boot device/filesystem. livecd ~ # ldd /usr/sbin/grub-install linux-vdso.so.1 (0x00007ffcc71f4000) liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f3e4d3f4000) libc.so.6 => /usr/lib64/libc.so.6 (0x00007f3e4d219000) /lib64/ld-linux-x86-64.so.2 (0x00007f3e4d56c000) # grub-install --target=x86_64-efi --boot-directory=/boot --efi-directory=/efi --bootloader-id=grub --recheck Installing for x86_64-efi platform. Volume group "nvme0n1p2_crypt" not found Cannot process volume group nvme0n1p2_crypt Volume group "nvme0n1p2_crypt" not found Cannot process volume group nvme0n1p2_crypt # df /boot /efi Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/nvme0n1p2_crypt 4126400 28 4109988 1% /boot /dev/nvme0n1p1 1046400 16 1046384 1% /efi Reproducible: Always Expected Results: compiled grub with device-mapper support
We can consider adding that USE but you really should just run grub-install from your own chroot where you control USE. Can you tell us why you're needing to run it from admincd?
"AdminCD" can be used as "InstallCD" but consider as "RescueCD" also. To easily (re-)install grub payload on encrypted BOOT filesystem (grub2.12+ with support of luks2/pbkdf2/sha256|sha512) it is beneficial for having working "AdminCD" with device-mapper supported grub-install in Gentoo ecosystem. Current workaround is to use non-gentoo "SystemRescueCD" for having grub-install with device-mapper support.
Or to use current installcd or admincd to chroot to your gentoo rootfs-- this is the most well-supported way.
