Report forwarded
to bug-guix@gnu.org: bug#30847; Package guix.
(Sun, 18 Mar 2018 16:33:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Adam Van Ymeren <adam@vany.ca>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Sun, 18 Mar 2018 16:33:02 GMT) (full text, mbox, link).
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.
Information forwarded
to bug-guix@gnu.org: bug#30847; Package guix.
(Sun, 18 Mar 2018 22:34:02 GMT) (full text, mbox, link).
Hi Adam,
On Sun, 18 Mar 2018 12:32:18 -0400
Adam Van Ymeren <adam@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.
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@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’.
Information forwarded
to bug-guix@gnu.org: bug#30847; Package guix.
(Tue, 27 Mar 2018 13:20:02 GMT) (full text, mbox, link).
Subject: Re: bug#30847: Cannot upgrade GuixSD due to
check-device-initrd-modules
Date: Tue, 27 Mar 2018 15:19:46 +0200
Ping! :-)
ludo@gnu.org (Ludovic Courtès) skribis:
> Hello Adam,
>
> Adam Van Ymeren <adam@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’.
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.