Cannot upgrade GuixSD due to check-device-initrd-modules

  • Open
  • quality assurance status badge
Details
3 participants
  • Adam Van Ymeren
  • Danny Milosavljevic
  • Ludovic Courtès
Owner
unassigned
Submitted by
Adam Van Ymeren
Severity
normal

Debbugs page

A
A
Adam Van Ymeren wrote on 18 Mar 2018 09:32
(address . bug-guix@gnu.org)
87zi351h0t.fsf@vany.ca
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.
D
D
Danny Milosavljevic wrote on 18 Mar 2018 15:33
(name . Adam Van Ymeren)(address . adam@vany.ca)(address . 30847@debbugs.gnu.org)
20180318233331.59bc54e1@scratchpost.org
Hi Adam,

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

Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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

Toggle quote (7 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlqu6TsACgkQ5xo1VCww
uqVsoAf+KBvrfuaJ9EMMEz9c5jCaD+4ZQxFo/dT7AbQPewIzVAcZyIs4FCrrA/3h
I1Vc8/XkrQUaqC9MrDsS7ExsnFZ10xJFg+szqcr0gxV9q/BHfP6XcVa1mLVui2e7
qWoh/ZDRWIu9W9wjypmofeKoVho2yLMMwZwEuaVFrlrXtpKTEVUpniHYpfiEHXpA
JeagG/xqTpJnwQjXswQ4ZdTjXOl6QQWsW3908CQMJx4aMD/kJWohA6ERoAdqKsKH
EvYVbt0wu+xkQiyy4aE8y8kJfQOAb/HUsbboBEx4dRf6mKtQ7Gx1tRiXFxlySzcu
hz6Tp4zOZittloVea+MaUm6gDxxLEw==
=PCYY
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 19 Mar 2018 09:51
(name . Adam Van Ymeren)(address . adam@vany.ca)(address . 30847@debbugs.gnu.org)
87fu4wuhyz.fsf@gnu.org
Hello Adam,

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

Toggle quote (7 lines)
> 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’.
L
L
Ludovic Courtès wrote on 27 Mar 2018 06:19
(name . Adam Van Ymeren)(address . adam@vany.ca)(address . 30847@debbugs.gnu.org)
87605hwt8t.fsf@gnu.org
Ping! :-)

ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (23 lines)
> 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’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 30847@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 30847
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch