Re: 03/11: reconfigure: Support loading the system for kexec reboot.

Re: 03/11: reconfigure: Support loading the system for kexec reboot.

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

Hello :)

> Hi,
>
> Tomas Volf <~@wolfsden.cz> skribis:
>
>> thank you for this series, it looks quite useful, however couple of
>> questions about this commit are below. :)
>
> For me privately?  If not, feel free to share my reply with the list.

It just felt unnecessary to spam the whole list with these questions,
but I defer to your judgment here and will reply to the list.

>
>> Is it expected that I can call `reboot -k' without any system being
>> loaded for the kexec (yet)?  The VM I have tried it in seems to just
>> "shutdown" half-way and then hang, with last message being "Rebooting
>> via kexec" or something like that.  I am not sure if that is expected
>> (and the onus is on me to make sure I load the image before `reboot -k')
>> or if I should bug report it.
>
> It’s a bug fixed in Shepherd ‘main’ (bug-fix release will be out
> soon).

Nice.

>
>>> +    (program-file
>>> +     "kexec-load-system.scm"
>>> +     (with-imported-modules '((guix build syscalls))
>>> +       #~(begin
>>> +           (use-modules (guix build syscalls))
>>> +
>>> +           (let ((kernel (open-fdes #$(operating-system-kernel-file os)
>>> +                                    O_RDONLY))
>>> +                 (initrd (open-fdes #$(operating-system-initrd-file os)
>>> +                                    O_RDONLY)))
>>
>> Do I understand it right that this program basically loads just the
>> (initrd) field of the operating-system definitions, and ignores the
>> (extra-initrd) field?  If so, that is a shame.  Would have allowed
>> reboots of LUKS encrypted machines without entering the password at all.
>
> Good point!  kexec_file_load(2) can only be given one initrd, so I
> suppose it cannot support extra initrds.
>
> That’s something we should at least document and probably protect
> against.

Based on the kexec_file_load's man page it looks like it takes a file
descriptor.  Is there a technical reason why we cannot just construct
the unified initrd in memory by overlaying the extra-initrd over the
initrd (which is what GRUB does anyway) and feed the result to the
kernel via a pipe?

I am willing to give a shot writing the code for it (once the kexec
loading works at all on my machines, see #75320), assuming you consider
this approach sound.

Have a nice day,
Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: 03/11: reconfigure: Support loading the system for kexec reboot.

[Ludovic Courtès]

Hello,

Tomas Volf <~@wolfsden.cz> skribis:

>> Good point!  kexec_file_load(2) can only be given one initrd, so I
>> suppose it cannot support extra initrds.
>>
>> That’s something we should at least document and probably protect
>> against.
>
> Based on the kexec_file_load's man page it looks like it takes a file
> descriptor.  Is there a technical reason why we cannot just construct
> the unified initrd in memory by overlaying the extra-initrd over the
> initrd (which is what GRUB does anyway) and feed the result to the
> kernel via a pipe?

Woow.  Everything’s possible, but it sounds non-trivial (possibly more
code than kexec support in its current form!).

In the meantime, we should at least document the limitation and/or skip
the feature entirely when ‘extra-initrd’ is specified.

Ludo’.