luks-device-mapping-with-options breaks bootloader

  • Open
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Tadhg McDonald-Jensen
  • Tomas Volf
Owner
unassigned
Submitted by
Tadhg McDonald-Jensen
Severity
important
T
T
Tadhg McDonald-Jensen wrote on 7 May 20:54 +0200
(address . bug-guix@gnu.org)
CAP5DvDj1Xgkr5Mzy2XEzj6O86Nm=Z=hczhKQpCYKhV8Z7mg=BA@mail.gmail.com
using the `luks-device-mapping-with-options` mapped device type defined in
(gnu system mapped-devices) causes grub or other bootloaders to not
properly attempt to mount the encrypted drive. This is caused by the
commit 39a9404 which identifies luks mapped devices by checking if the type
is equal to `luks-device-mapping`, so by using a different routine that is
a proxy to that one it doesn't forward it to grub in the
store-crypto-devices list.

For anyone who finds this before it is fixed, you can boot your device by
hitting 'c' in grub and typing these commands:
grub> insmod luks
grub> insmod luks2
grub> cryptomount (XXX)
grub> set root=(crypto)
grub> configfile (YYY)/grub/grub.cfg

Where (XXX) is the encrypted partition and (YYY) is the boot partition with
the grub config, these can be found by doing `ls` command.
Attachment: file
L
L
Ludovic Courtès wrote on 25 May 11:40 +0200
control message for bug #70826
(address . control@debbugs.gnu.org)
87le3y2psc.fsf@gnu.org
severity 70826 important
quit
L
L
Ludovic Courtès wrote on 25 May 11:47 +0200
Re: bug#70826: luks-device-mapping-with-options breaks bootloader
(name . Tadhg McDonald-Jensen)(address . tadhgmister@gmail.com)(address . 70826@debbugs.gnu.org)
87ikz22pgo.fsf@gnu.org
Hi,

Tadhg McDonald-Jensen <tadhgmister@gmail.com> skribis:

Toggle quote (8 lines)
> using the `luks-device-mapping-with-options` mapped device type defined in
> (gnu system mapped-devices) causes grub or other bootloaders to not
> properly attempt to mount the encrypted drive. This is caused by the
> commit 39a9404 which identifies luks mapped devices by checking if the type
> is equal to `luks-device-mapping`, so by using a different routine that is
> a proxy to that one it doesn't forward it to grub in the
> store-crypto-devices list.

Ouch, indeed. The immediate fix is:
Toggle diff (21 lines)
diff --git a/gnu/system.scm b/gnu/system.scm
index c76f4d7c502..bb851b1b75f 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -667,10 +667,13 @@ (define (operating-system-boot-mapped-devices os)
(define operating-system-bootloader-crypto-devices
(mlambdaq (os) ;to avoid duplicated output
"Return the sources of the LUKS mapped devices specified by UUID."
+ (define (luks-device? m)
+ (memq (mapped-device-type m)
+ (list luks-device-mapping-with-options
+ luks-device-mapping)))
+
;; XXX: Device ordering is important, we trust the returned one.
- (let* ((luks-devices (filter (lambda (m)
- (eq? luks-device-mapping
- (mapped-device-type m)))
+ (let* ((luks-devices (filter luks-device?
(operating-system-boot-mapped-devices os)))
(uuid-crypto-devices non-uuid-crypto-devices
(partition (compose uuid? mapped-device-source)
Not ideal, but it fixes the problem.

I’ll go ahead with this patch if there are no objections.

Thanks!

Ludo’.
T
T
Tadhg McDonald-Jensen wrote on 25 May 16:30 +0200
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 70826@debbugs.gnu.org)
ecfd1524-9d20-491c-b2be-8b7122c28d71@gmail.com
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.


Toggle diff (79 lines)
diff --git a/gnu/system.scm b/gnu/system.scm
index cb6e719ca6..b564bf3788 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -661,10 +661,12 @@ (define (operating-system-boot-mapped-devices os)
(define operating-system-bootloader-crypto-devices
(mlambdaq (os) ;to avoid duplicated output
"Return the sources of the LUKS mapped devices specified by UUID."
+ (define (luks-device? m)
+ (eq? (mapped-device-kind-close (mapped-device-type m))
+ (mapped-device-kind-close luks-device-mapping)))
+
;; XXX: Device ordering is important, we trust the returned one.
- (let* ((luks-devices (filter (lambda (m)
- (eq? luks-device-mapping
- (mapped-device-type m)))
+ (let* ((luks-devices (filter luks-device?
(operating-system-boot-mapped-devices
os)))
(uuid-crypto-devices non-uuid-crypto-devices
(partition (compose uuid?
mapped-device-source)



(I apologize if my email client is adding line wraps to the diffs, I
will look into it after sending this)

I tried to implement this initially but it didn't work on my previous
attempt so I abandoned trying to submit a patch, but this version does
do the trick even if it seems inelegant.

On 2024-05-25 5:47 a.m., Ludovic Courtès wrote:
> Hi,
>
> Tadhg McDonald-Jensen <tadhgmister@gmail.com> skribis:
>
>> using the `luks-device-mapping-with-options` mapped device type defined in
>> (gnu system mapped-devices) causes grub or other bootloaders to not
>> properly attempt to mount the encrypted drive. This is caused by the
>> commit 39a9404 which identifies luks mapped devices by checking if the type
>> is equal to `luks-device-mapping`, so by using a different routine that is
>> a proxy to that one it doesn't forward it to grub in the
>> store-crypto-devices list.
>
> Ouch, indeed. The immediate fix is:
>
>
> diff --git a/gnu/system.scm b/gnu/system.scm
> index c76f4d7c502..bb851b1b75f 100644
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -667,10 +667,13 @@ (define (operating-system-boot-mapped-devices os)
> (define operating-system-bootloader-crypto-devices
> (mlambdaq (os) ;to avoid duplicated output
> "Return the sources of the LUKS mapped devices specified by UUID."
> + (define (luks-device? m)
> + (memq (mapped-device-type m)
> + (list luks-device-mapping-with-options
> + luks-device-mapping)))
> +
> ;; XXX: Device ordering is important, we trust the returned one.
> - (let* ((luks-devices (filter (lambda (m)
> - (eq? luks-device-mapping
> - (mapped-device-type m)))
> + (let* ((luks-devices (filter luks-device?
> (operating-system-boot-mapped-devices os)))
> (uuid-crypto-devices non-uuid-crypto-devices
> (partition (compose uuid? mapped-device-source)
>
>
>
> Not ideal, but it fixes the problem.
>
> I’ll go ahead with this patch if there are no objections.
>
> Thanks!
>
> Ludo’.
T
T
Tomas Volf wrote on 23 Jul 20:19 +0200
(name . Tadhg McDonald-Jensen)(address . tadhgmister@gmail.com)
Zp_0RcfVu1bbXDoH@ws
On 2024-05-25 10:30:49 -0400, Tadhg McDonald-Jensen wrote:
Toggle quote (7 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmaf9EUACgkQL7/ufbZ/
wan9vBAAnqC/KJO7HlcrJDLYAKJR8aVh9U2DywISrzC9cdqmmzDg6xwkTDFPDnKG
cYf+DF4T4dAn+TdlrF4KDWIoGqMLmMP/0l5fSaxPf4FdnDjY3BBr8As/qz1pxyKw
QUU4AcbedZCzXYT2V/pzy8LN6RpfNO6w9ojbvNFDmy03V83RxcCVDWQ5qLaV4ws1
EZ2irVcHkULJSfIslXGjPVmLIcihXHpIwv+zDCTE5IuM763RR02aJhqMWRONigEc
ysLfM8sVozp494MBpsSHxc3aIh1ZtjfxzQRTgYRBnmAIqbFZVwzkwP04iOsxv7CX
8/mi9yczq7RqsVFRK6QIgfepYfndJeA8ycCJEU7kjwZGgw3GdONa5uE1FeJmd6MV
OPqMb/Ttx7V5KgIo7k/1oGBR8afwaaDgW7ga/Oemdqim0lzKf6hpmrFlrfoAcsBw
MviLlDHA0vCVCybHehE2tGYs7QMMW/PNdWgUURXUrWGdxkMlJua2yJlLHBlvLMx2
G2ROY4mP8geARRD8yLOXskCh5aHSuC5T7yxP0Honno5P3aRDdW4iMTbwtSp1t+lM
BFaOesFcOF8VzyAUBKSsnlhiEdfcbjW/DIWeKRsuPevJ5iZyl/PiIlIxQQHsexHU
nbnwL3bix7M3q1ztt+OfrkbQThPz5cf69XrYi5fSwD9gKS4P35g=
=5ISi
-----END PGP SIGNATURE-----


T
T
Tadhg McDonald-Jensen wrote on 12 Aug 00:33 +0200
(name . Tomas Volf)(address . ~@wolfsden.cz)
44aec6b7-dcba-4598-c984-068333cc696b@gmail.com
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:
Toggle quote (21 lines)
> 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.
Attachment: os.tmp.scm
T
T
Tadhg McDonald-Jensen wrote on 12 Aug 01:19 +0200
(name . Tomas Volf)(address . ~@wolfsden.cz)
CAP5DvDh0pt=SdnW8ptHbKnjKHCY586Mis7chktQ8R3k-BH1o1w@mail.gmail.com
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 <tadhgmister@gmail.com>
wrote:

Toggle quote (32 lines)
> 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.
Attachment: file
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 70826@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 70826
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch