'initrd-modules' check has false positives

`guix system init` seems to be broken for non GuixSD distirbutions:

When I tried it on openSUSE:

# guix system --no-bootloader init /Devel/git/guix-config/config.scm /mnt/mnt/

;;; note: source file /Devel/extra/gnu/packages/connman.scm

;;; newer than compiled /root/.config/guix/latest/gnu/packages/connman.go

;;; note: source file /Devel/extra/gnu/packages/connman.scm

;;; newer than compiled /usr/lib64/guile/2.2/site-ccache/gnu/packages/connman.go

;;; note: source file /Devel/extra/gnu/packages/connman.scm

;;; newer than compiled /usr/lib64/guile/2.2/site-ccache/gnu/packages/connman.go

guix system: error: open-file: No such file or directory: "/run/booted-system/kernel/lib/modules/4.15.6-1-default/modules.alias"

4.15.6-1-default is version of my running kernel, but not defined as package - it is not expected to be used for guix call.

/run/booted-system/ is specific for GuixSD.

Hi Ludo,

there's a problem with check-device-initrd-modules: on "guix system init"

it doesn't get linux-module-directory and doesn't pass it on to matching-modules.

matching-modules then eventually defaults to (current-alias-file) - which is not

found on a non-GuixSD system.

Would it be possible to get rid of the defaults in gnu/build/linux-modules.scm ?

I don't think those are safe or useful for our requirements. I've had to work

around those before.

check-initrd-modules could use the initrd's new kernel modules to find

out which modules to include (after all).

Then we could also check the dependencies directly in the new Linux kernel

modules and all in all it would be safer.

Hello,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Yeah.

It would be safer indeed, but we’d have to build the kernel and

everything before we can make a diagnostic. That would lead to a weird

user experience, similar to what we currently see with grafts (things

are built/downloader, and later on you get a message about what’s going

to be built.)

The current tradeoff is to make that diagnostic based on the running

kernel, even if it’s an approximation.

If that’s fine with you I’d like to fix this bug with the conservative

patch below.

Thoughts?

Ludo’.

[huge build]

Ah, good point.

Sure, looks good.

While we are approximating we could also in a later version fall back to

(the host system's) "`cat /proc/sys/kernel/modprobe` --showconfig" - it

could be used to find aliases.

But maybe that would make it brittle. Hmm...

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Pushed as 8d5c14edf5a6d01f859b1aa00c836ffdb5ddecf4.

Yeah, I don’t think it’d make a big difference.

BTW, we should add a ‘--skip-checks’ option to ‘guix system’ so that

users can skip those checks. That’d provide an escape hatch in case

‘check-device-initrd-modules’ makes the wrong diagnostic.

Thoughts?

Ludo’.

On Sat, Mar 10, 2018 at 12:19:52AM +0100, Ludovic Courtès wrote:

I'm afraid that now it leads to:

Backtrace:

12 (primitive-load "/usr/bin/guix")

In guix/ui.scm:

1501:12 11 (run-guix-command _ . _)

In ice-9/boot-9.scm:

829:9 10 (catch _ _ #<procedure 7fa007c66420 at guix/ui.scm:552…> …)

829:9 9 (catch _ _ #<procedure 7fa007c66438 at guix/ui.scm:660…> …)

In guix/scripts/system.scm:

1180:8 8 (_)

1052:6 7 (process-action _ _ _)

In guix/store.scm:

1443:24 6 (run-with-store _ _ #:guile-for-build _ #:system _ # _)

In guix/scripts/system.scm:

1065:13 5 (_ _)

764:4 4 (perform-action init #<<operating-system> kernel: #<pa…> …)

In srfi/srfi-1.scm:

640:9 3 (for-each #<procedure 55b8f874b9c0 at guix/scripts/sys…> …)

In gnu/system/linux-initrd.scm:

360:4 2 (check-device-initrd-modules "/dev/nvme0n1p2" ("ahci" …) …)

In ice-9/boot-9.scm:

829:9 1 (catch system-error #<procedure 7fa004522f60 at gnu/sy…> …)

In gnu/system/linux-initrd.scm:

361:6 0 (_)

gnu/system/linux-initrd.scm:361:6: known-module-aliases: unbound variable

This is part of my config:

(initrd (lambda (file-system . rest)

(raw-initrd file-systems

#:linux linux-x1-sw1

#:linux-modules '()

#:helper-packages '(linux-firmware-initrd-x1-sw1)

#:mapped-devices mapped-devices)))

I don't have any modules to be loaded in initrd, kernel is compiled

using my configuration which fits my needs and follows the HW it will run on.

S_W

Hi Ludo,

Yeah, good idea!

On Sun, Mar 11, 2018 at 10:38:18PM +0100, Ludovic Courtès wrote:

I'm afraid this is still not correct.

# guix system init config.scm /mnt/mnt/

...

config.scm:64:9: error: you may need these modules in the initrd for /dev/nvme0n1p2: shpchp

hint: Try adding them to the `initrd-modules' field of your `operating-system' declaration, along these lines:

(operating-system

;; ...

(initrd-modules (append (list "shpchp")

%base-initrd-modules)))

I don't have `shpchp` as a module as I have it compiled into kernel

directly. Can I somehow disable the check?

Thanks.

S_W

I think it's a good idea to add a command-line switch that disables the check.

But then people will just disable the check always and it won't improve until

it's correct. It's still a good idea to give people the choice.

@Ludo: It would also be great to have a command-line switch to check the slow,

correct, way. We'd also have to check modules.builtin of the new system's initrd

- but we'd do it only when the option is passed :)

I suggest to change it to:

^^^ not error

Or maybe to this:

Hello,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Exactly what I feared. ;-)

I thought about making it a warning rather than an error back then, but

thought that it wouldn’t work well: the warning would immediately go

off-screen as build logs start scrolling by.

Thus I took the optimistic view that false positives like the one Tomáš

experienced should be rare because usually init/reconfigure are used on

GuixSD, with a kernel config very close to the target config.

Nevertheless, the risk of false-positives obviously exists, hence the

need for an escape hatch.

What about the attached patch?

Thanks,

Ludo’.

retitle 30760 'initrd-modules' check has false positives

severity 30760 important

On Mon, Mar 12, 2018 at 01:24:37PM +0100, Danny Milosavljevic wrote:

Just small note - In my case I always run `system build` before

`system init` so I don't mind having any deeper analysis based on code

and configuration as long as it is correct. Maybe more people is using

same approach.

Best regards,

S_W

Hi!

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

Pushed as 61b1dbbdcd87f6b37d6b87715a9a4da4e63485ab.

Thanks,

Ludo’.