GNU bug report logs - #40998
Guix System's initrd doesn't honor rootflags

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#40998: closed (Guix System's initrd doesn't honor rootflags)
Date: Tue, 01 Mar 2022 18:33:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 01 Mar 2022 13:32:09 -0500
with message-id <874k4hle1i.fsf <at> gmail.com>
and subject line Re: bug#40998: [PATCH 1/4] system: Add a version field to the <boot-parameters> record.
has caused the debbugs.gnu.org bug report #40998,
regarding Guix System's initrd doesn't honor rootflags
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
40998: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40998
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: maxim.cournoyer <at> gmail.com
To: bug-guix <bug-guix <at> gnu.org>
Subject: Guix System's initrd doesn't honor rootflags
Date: Fri, 01 May 2020 09:53:11 -0400

Which means users cannot pass a 'rootflags=degraded' command line option
to the kernel line in GRUB to attempt booting a system whose RAID array
is degraded.

rootflags is standard across distributions, and is what users expect.

Such support was added in earlier version of the patches proposed here:
https://issues.guix.gnu.org/37305#0 but is later simplified out.

Maxim

[Message part 3 (message/rfc822, inline)]

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40998-done <at> debbugs.gnu.org
Subject: Re: bug#40998: [PATCH 1/4] system: Add a version field to the
 <boot-parameters> record.
Date: Tue, 01 Mar 2022 13:32:09 -0500

Hi Ludovic,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:

> Hi Ludovic,
>
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi!
>>
>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>>
>>> This version field exposes the (already present) version information of a boot
>>> parameters file.
>>>
>>> * gnu/system.scm (%boot-parameters-version): New variable.
>>> (<boot-parameters>)[version]: New field.
>>> (read-boot-parameters): Use it.
>>> (operating-system-boot-parameters-file): Likewise.
>>> * tests/boot-parameters.scm (test-read-boot-parameters): Use
>>> %boot-parameters-version as the default version value in the template.
>>
>> [...]
>>
>>> +  ;; New versions are not backward-compatible, so only accept past and current
>>> +  ;; versions, not future ones.
>>> +  (define (version? n)
>>> +    (member n (iota (1+ %boot-parameters-version))))
>>> +
>>>    (match (read port)
>>> -    (('boot-parameters ('version 0)
>>> +    (('boot-parameters ('version (? version? version))
>>
>> I still have a preference for an explicit list right here, for clarity,
>> and so that we don’t unwillingly find ourselves treating any past
>> version in the same way in the future.
>
> OK.  I prefer that we can bump %boot-parameters-version at one place and
> have the rest of the code base do the right thing instead of having to
> manually remember to adjust bits left and right.  I've added a comment
> next to %boot-parameters-version to mention it should be incremented by
> 1 when bumping it.
>
>> I think I wasn’t clear about it (sorry!) but I wonder if we could,
>> instead of bumping the version, use something like:
>>
>>   (find (cut string-prefix? "gnu.load=") kernel-arguments)
>>
>> to determine whether we’re dealing with an “old-style” “parameters”
>> file.
>>
>> If that’s not possible, then what this patch is doing SGTM.
>
> That's not possible, because the parameters file doesn't include the
> gnu.load nor gnu.system parameters because of their self-referential
> nature, so we don't have such information to look at.
>
> I'll be looking toward pushing this series today.

I've now pushed it as 6d9d616113cf051d80567b584a5b0a6489ddc065.  Thanks
for the review!

Maxim

Previous Next

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