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 <[email protected]> skribis:
Ludovic Courtès <[email protected]> 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’.
