GNU bug report logs - #30847
Cannot upgrade GuixSD due to check-device-initrd-modules

Previous Next

To reply to this bug, email your comments to 30847 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Adam Van Ymeren <adam <at> vany.ca>
To: bug-guix <at> gnu.org
Subject: Cannot upgrade GuixSD due to check-device-initrd-modules
Date: Sun, 18 Mar 2018 12:32:18 -0400

My root device is on NVMe.

In my current kernel config CONFIG_NVME_CORE is set to a module, which is
included in my initrd.

However upstream defconfig has been changed to CONFIG_NVME_CORE=y

When trying to guix reconfigure my system, building the operating system
fails in check-device-initrd-modules with the following message

vany/systems.scm:111:10: error: you may need these modules in the initrd for /dev/nvme0n1p2: nvme shpchp
hint: Try adding them to the `initrd-modules' field of your `operating-system' declaration, along these lines:

      (operating-system
        ;; ...
        (initrd-modules (append (list "nvme" "shpchp")
                                %base-initrd-modules)))


If I add initrd-modules to my operating-system, then building the initrd
fails because nvme module cannot be found (as it is not being build as a
module).

Fundamentally I think the problem is that check-device-initrd-modules is
checking modules for the currently running kernel which is not
necessarily the kernel that I will be installing.

At the very least however it would be nice if I could override this
check with a --i-know-what-im-doing flag of some sort.

It seems odd that check-device-initrd-modules will not prevent your
installation from continuing if it can't find modules.alias, but if it
can find it and you didn't specify the initrd-modules it thinks you need
then it becomes a hard error that you can't override.  Perhaps it should
always be a warning or prompt the user if they want to continue.

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

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Adam Van Ymeren <adam <at> vany.ca>
Cc: 30847 <at> debbugs.gnu.org
Subject: Re: bug#30847: Cannot upgrade GuixSD due to
 check-device-initrd-modules
Date: Sun, 18 Mar 2018 23:33:31 +0100

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

Hi Adam,

On Sun, 18 Mar 2018 12:32:18 -0400
Adam Van Ymeren <adam <at> vany.ca> wrote:

> Fundamentally I think the problem is that check-device-initrd-modules is
> checking modules for the currently running kernel which is not
> necessarily the kernel that I will be installing.

Yeah, otherwise it would have to build everything first.

> At the very least however it would be nice if I could override this
> check with a --i-know-what-im-doing flag of some sort.

It exists: --skip-checks

> It seems odd that check-device-initrd-modules will not prevent your
> installation from continuing if it can't find modules.alias, but if it
> can find it and you didn't specify the initrd-modules it thinks you need
> then it becomes a hard error that you can't override. 
> Perhaps it should
> always be a warning or prompt the user if they want to continue.

Yeah, I'd prefer a warning and sleep 5 since the result is not guaranteed to be
correct.

Also it would be possible to build a Frankenstein's monster version where it
checks the new kernel config and finds out which modules would be builtin
(that would involve a lot of Makefile and Kconfig parsing... ugh).

An additional more complete check (with the new kernel etc) at the end would
make sense.

[Message part 2 (application/pgp-signature, inline)]

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Adam Van Ymeren <adam <at> vany.ca>
Cc: 30847 <at> debbugs.gnu.org
Subject: Re: bug#30847: Cannot upgrade GuixSD due to
 check-device-initrd-modules
Date: Mon, 19 Mar 2018 17:51:16 +0100

Hello Adam,

Adam Van Ymeren <adam <at> vany.ca> skribis:

> My root device is on NVMe.
>
> In my current kernel config CONFIG_NVME_CORE is set to a module, which is
> included in my initrd.
>
> However upstream defconfig has been changed to CONFIG_NVME_CORE=y

Out of curiosity, what’s the current and target kernel versions?

Like Danny wrote, ‘check-device-initrd-modules’ can have false positives
as it is, in which case you have to use ‘--skip-checks’.

We could arrange to not have false positives, but the UX would be a
little less good because we’d first need to build the target kernel.  So
I wonder how frequent the situation you experienced is.

Thanks for your report!

Ludo’.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Adam Van Ymeren <adam <at> vany.ca>
Cc: 30847 <at> debbugs.gnu.org
Subject: Re: bug#30847: Cannot upgrade GuixSD due to
 check-device-initrd-modules
Date: Tue, 27 Mar 2018 15:19:46 +0200

Ping!  :-)

ludo <at> gnu.org (Ludovic Courtès) skribis:

> Hello Adam,
>
> Adam Van Ymeren <adam <at> vany.ca> skribis:
>
>> My root device is on NVMe.
>>
>> In my current kernel config CONFIG_NVME_CORE is set to a module, which is
>> included in my initrd.
>>
>> However upstream defconfig has been changed to CONFIG_NVME_CORE=y
>
> Out of curiosity, what’s the current and target kernel versions?
>
> Like Danny wrote, ‘check-device-initrd-modules’ can have false positives
> as it is, in which case you have to use ‘--skip-checks’.
>
> We could arrange to not have false positives, but the UX would be a
> little less good because we’d first need to build the target kernel.  So
> I wonder how frequent the situation you experienced is.
>
> Thanks for your report!
>
> Ludo’.

Previous Next

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