GNU logs - #30847, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#30847: Cannot upgrade GuixSD due to check-device-initrd-modules
Resent-From: Adam Van Ymeren <adam@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 18 Mar 2018 16:33:02 +0000
Resent-Message-ID: <handler.30847.B.15213907564438 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 30847 <at> debbugs.gnu.org
From: Adam Van Ymeren <adam@HIDDEN>
Date: Sun, 18 Mar 2018 12:32:18 -0400
Message-ID: <87zi351h0t.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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 sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Adam Van Ymeren <adam@HIDDEN>
Subject: bug#30847: Acknowledgement (Cannot upgrade GuixSD due to
 check-device-initrd-modules)
Message-ID: <handler.30847.B.15213907564438.ack <at> debbugs.gnu.org>
References: <87zi351h0t.fsf@HIDDEN>
X-Gnu-PR-Message: ack 30847
X-Gnu-PR-Package: guix
Reply-To: 30847 <at> debbugs.gnu.org
Date: Sun, 18 Mar 2018 16:33:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 30847 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
30847: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D30847
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#30847: Cannot upgrade GuixSD due to check-device-initrd-modules
Resent-From: Danny Milosavljevic <dannym@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Sun, 18 Mar 2018 22:34:02 +0000
Resent-Message-ID: <handler.30847.B30847.15214124233868 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Adam Van Ymeren <adam@HIDDEN>
Cc: 30847 <at> debbugs.gnu.org
Date: Sun, 18 Mar 2018 23:33:31 +0100
From: Danny Milosavljevic <dannym@HIDDEN>
Message-ID: <20180318233331.59bc54e1@HIDDEN>
In-Reply-To: <87zi351h0t.fsf@HIDDEN>
References: <87zi351h0t.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/7XU_3qSGwxLb7OPvhDJ78W8"; protocol="application/pgp-signature"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--Sig_/7XU_3qSGwxLb7OPvhDJ78W8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Adam,

On Sun, 18 Mar 2018 12:32:18 -0400
Adam Van Ymeren <adam@HIDDEN> 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.=20
> 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 t=
o 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.

--Sig_/7XU_3qSGwxLb7OPvhDJ78W8
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----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-----

--Sig_/7XU_3qSGwxLb7OPvhDJ78W8--

Message sent to bug-guix@HIDDEN:

Subject: bug#30847: Cannot upgrade GuixSD due to check-device-initrd-modules
Resent-From: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Mon, 19 Mar 2018 16:52:03 +0000
Resent-Message-ID: <handler.30847.B30847.152147828122217 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Adam Van Ymeren <adam@HIDDEN>
Cc: 30847 <at> debbugs.gnu.org
From: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
References: <87zi351h0t.fsf@HIDDEN>
Date: Mon, 19 Mar 2018 17:51:16 +0100
In-Reply-To: <87zi351h0t.fsf@HIDDEN> (Adam Van Ymeren's message of "Sun, 18
 Mar 2018 12:32:18 -0400")
Message-ID: <87fu4wuhyz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hello Adam,

Adam Van Ymeren <adam@HIDDEN> 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=3Dy

Out of curiosity, what=E2=80=99s the current and target kernel versions?

Like Danny wrote, =E2=80=98check-device-initrd-modules=E2=80=99 can have fa=
lse positives
as it is, in which case you have to use =E2=80=98--skip-checks=E2=80=99.

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

Thanks for your report!

Ludo=E2=80=99.

Message sent to bug-guix@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#30847: Cannot upgrade GuixSD due to check-device-initrd-modules
Resent-From: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Tue, 27 Mar 2018 13:20:02 +0000
Resent-Message-ID: <handler.30847.B30847.152215679323631 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 30847
X-GNU-PR-Package: guix
X-GNU-PR-Keywords: 
To: Adam Van Ymeren <adam@HIDDEN>
Cc: 30847 <at> debbugs.gnu.org
Received: via spool by 30847-submit <at> debbugs.gnu.org id=B30847.152215679323631
          (code B ref 30847); Tue, 27 Mar 2018 13:20:02 +0000
Received: (at 30847) by debbugs.gnu.org; 27 Mar 2018 13:19:53 +0000
Received: from localhost ([127.0.0.1]:55325 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f0oW0-000695-Qs
	for submit <at> debbugs.gnu.org; Tue, 27 Mar 2018 09:19:53 -0400
Received: from hera.aquilenet.fr ([185.233.100.1]:51092)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ludo@HIDDEN>) id 1f0oVy-00068w-Hm
 for 30847 <at> debbugs.gnu.org; Tue, 27 Mar 2018 09:19:52 -0400
Received: from localhost (localhost [127.0.0.1])
 by hera.aquilenet.fr (Postfix) with ESMTP id 7D65E12627;
 Tue, 27 Mar 2018 15:19:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aquilenet.fr
Received: from hera.aquilenet.fr ([127.0.0.1])
 by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id uBLMNBCuWiY3; Tue, 27 Mar 2018 15:19:48 +0200 (CEST)
Received: from ribbon (vpn-0-27.aquilenet.fr [IPv6:2a0c:e300:4:27::])
 by hera.aquilenet.fr (Postfix) with ESMTPSA id 31B7912621;
 Tue, 27 Mar 2018 15:19:48 +0200 (CEST)
From: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=)
References: <87zi351h0t.fsf@HIDDEN> <87fu4wuhyz.fsf@HIDDEN>
Date: Tue, 27 Mar 2018 15:19:46 +0200
In-Reply-To: <87fu4wuhyz.fsf@HIDDEN> ("Ludovic
 \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\=
 \=\?utf-8\?Q\?s\?\= message of "Mon, 19 Mar 2018 17:51:16 +0100")
Message-ID: <87605hwt8t.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

Ping!  :-)

ludo@HIDDEN (Ludovic Court=C3=A8s) skribis:

> Hello Adam,
>
> Adam Van Ymeren <adam@HIDDEN> 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=3Dy
>
> Out of curiosity, what=E2=80=99s the current and target kernel versions?
>
> Like Danny wrote, =E2=80=98check-device-initrd-modules=E2=80=99 can have =
false positives
> as it is, in which case you have to use =E2=80=98--skip-checks=E2=80=99.
>
> We could arrange to not have false positives, but the UX would be a
> little less good because we=E2=80=99d first need to build the target kern=
el.  So
> I wonder how frequent the situation you experienced is.
>
> Thanks for your report!
>
> Ludo=E2=80=99.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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