In case it is relevant my disk is using GPT partition table with this layout: $ lsblk --output="NAME,MAJ:MIN,TYPE,MOUNTPOINTS,UUID" NAME MAJ:MIN TYPE MOUNTPOINTS UUID nvme0n1 259:0 disk ├─nvme0n1p1 259:1 part /boot 5190-E840 └─nvme0n1p2 259:2 part c0010d06-0bd1-4ae2-93e6-f2f89a3a670b └─cryptroot 253:0 crypt /gnu/store / Only the main partition is encrypted with LUKS and grub is located on its own partition not in the in between space in an MBR drive. It is grub that is being responsible for decrypting the partition not my UEFI decrypting the whole drive. Tadhg On Sun, Aug 11, 2024 at 6:33 PM Tadhg McDonald-Jensen wrote: > I have attached a config I just did `sudo guix system reconfigure` > and confirmed it was missing the `insmod luks` in /boot/grub/grub.cfg > > Sorry for the delay, > Tadhg McD-J > > On 2024-07-23 2:19 p.m., Tomas Volf wrote: > > On 2024-05-25 10:30:49 -0400, Tadhg McDonald-Jensen wrote: > >> That unfortunately doesn't fix the problem, > >> `luks-device-mapping-with-options` is a routine that returns the > >> `mapped-device-kind` so it won't check by equality. > >> > >> A possible solution is to check whether the `mapped-device-kind-close` > >> routines are the same as these are shared. > > > > What I find interesting is that I too am using > luks-device-mapping-with-options > > and my system boots just fine. So I wonder what the difference is. > Could you > > share your system configuration please? Or at least the relevant parts > (I > > assume at least bootloader, file-systems and mapped-devices fields)? > > > > I would like to properly understand the problem here and why it works > for me. > > > > Thanks, > > Tomas Volf > > > > -- > > There are only two hard things in Computer Science: > > cache invalidation, naming things and off-by-one errors.