GNU bug report logs - #70826
luks-device-mapping-with-options breaks bootloader

Previous Next

Full log

Message #37 received at 70826 <at> debbugs.gnu.org (full text, mbox):

From: Tadhg McDonald-Jensen <tadhgmister <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, Tomas Volf <~@wolfsden.cz>
Cc: 45mg <45mg.writes <at> gmail.com>, 70826 <at> debbugs.gnu.org
Subject: Re: [PATCH] system: Allow distinguishing <mapped-device-type>s.
Date: Mon, 5 May 2025 10:47:15 -0400

I figured out what is going on,

When the boot partition (the one with grub.cfg) is encrypted the command 
to decrypt it gets baked into the grub executable by `grub-install`. 
When the boot partition is not encrypted (such as when the unencrypted 
partitition is mounted to /boot) then grub determines it doesn't need a 
decryption command to load the grub.cfg and relies on the decrypt 
command being in the config to load the rest of the system.

Thus the default install process that has /boot part of the encrypted 
drive and mounts the efi partition to /boot/efi will be able to use 
`luks-device-mapping-with-options` without issue where as my setup with 
the grub.cfg being in the unencrypted drive runs into the issue I 
initially described.

I can write up a system test to reproduce my setup that causes this to 
be an issue if that'd be helpful.

Tadhg

On 2025-04-11 4:27 a.m., Ludovic Courtès wrote:
> Hello,
>
> Tomas Volf <~@wolfsden.cz> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
> [...]
>
>>> +++ b/gnu/system/mapped-devices.scm
>>> @@ -83,6 +83,8 @@ (define-record-type* <mapped-device> %mapped-device
>>>     (source    mapped-device-source)                ;string | list of strings
>>>     (targets   mapped-device-targets)               ;list of strings
>>>     (type      mapped-device-type)                  ;<mapped-device-kind>
>>> +  (arguments mapped-device-arguments              ;list passed to open/close/check
>>> +             (default '()))
>> I do not think it is a good idea to expect the same identical list for
>> all of the operations, so we would need arguments-open, arguments-close
>> and arguments-check fields.  Other that that, this would work, sure.
> Yeah I wondered about that but I thought that in the worst case the
> operations could just ignore those arguments; from the user’s viewpoint,
> that would keep the interface simple.
>
>> Only thing I wonder about whether we should be apply-ing the list, or
>> just passing it as a final arguments.  That would be a change in the
>> calling convention, but all procedures could just be adjusted to take
>> the extra argument.
> It’s a backward-compatible change in the calling convention (nothing
> changes for existing open/close/check methods that accept no keyword
> arguments).
>
>> One question would be how to handle if user passes the extra arguments
>> to a procedure that is not prepared to handle them.  In your approach
>> (apply) it would be a error due to wrong number of arguments, I am not
>> sure whether that is ideal.  Maybe a warning would be better?  Not sure.
>> Opinions?
> Yes, you’d get a wrong-type-arg error, similar to what you have if you
> pass #:random-number 42 in the ‘arguments’ field of a package.
>
> It’s not ideal in terms of error reporting, but maybe good enough.
>
> Another option would be for instance to always pass a key/value pair;
> open/close/check methods would have to look up in that list for relevant
> keys and could provide better error reporting, but the downside is extra
> boilerplate in those methods.
>
> Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.