GNU bug report logs - #70239
(operating-system) structure requires a kernel

Previous Next

To reply to this bug, email your comments to 70239 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: Tomas Volf <~@wolfsden.cz>
To: bug-guix <at> gnu.org
Subject: (operating-system) structure requires a kernel
Date: Sat, 6 Apr 2024 16:51:42 +0200

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

Hello,

I am deploying Guix into a LXC container, therefore I have no need for a kernel
(it is provided by the host).  So I would like to limit both storage and compute
cost by not providing any in the `operating-system' record.

Historically I was using a dummy empty package for that purpose, but that have
stopped working, so after short discussion with civodul on IRC I decided to
bug-report this problem.

2024-04-06 14:45:10	civodul	can’t you make it (kernel #f)?
2024-04-06 14:45:34	civodul	or maybe (kernel (plain-file "fake-kernel" ""))?
...
2024-04-06 14:49:52	civodul	actually i think ‘guix system container’ could/should do that: replace ‘kernel’ with a fake kernel or #f
2024-04-06 14:51:05	civodul	so yes, sounds like a bug to me

I tried the suggested options, here is #f:

    (operating-system
      (host-name "guix")
      ;; Servers usually use UTC regardless of the location.
      (timezone "Etc/UTC")
      (locale "en_US.utf8")
      (firmware '())
      (initrd-modules '())
    ;  (kernel %ct-dummy-kernel)
    (kernel #f)

      (packages (cons* nss-certs
                       %base-packages))

      (essential-services (modify-services
                              (operating-system-default-essential-services
			       this-operating-system)
                            (delete firmware-service-type)
                            (delete (service-kind %linux-bare-metal-service))))

      (bootloader %ct-bootloader)

      (file-systems %ct-file-systems)

      (services (cons* (service openssh-service-type
                                (openssh-configuration
                                 (openssh openssh-sans-x)
                                 (permit-root-login #t)
                                 (password-authentication? #t)))
                       %ct-services)))

Which leads to:

    Backtrace:
    In guix/store.scm:
       661:37 19 (thunk)
       1300:8 18 (call-with-build-handler #<procedure 7f8c92c5f4b0 at g…> …)
      2180:25 17 (run-with-store #<store-connection 256.99 7f8c946de370> …)
    In guix/scripts/system.scm:
        847:2 16 (_ _)
        721:8 15 (_ #<store-connection 256.99 7f8c946de370>)
    In gnu/system.scm:
      1301:19 14 (operating-system-derivation _)
    In gnu/services.scm:
      1220:36 13 (_ _)
    In srfi/srfi-1.scm:
       586:29 12 (map1 (#<<service> type: #<service-type profile 7f8c…> …))
       586:29 11 (map1 (#<<service> type: #<service-type etc 7f8c9691…> …))
       586:29 10 (map1 (#<<service> type: #<service-type activate 7f8…> …))
       586:29  9 (map1 (#<<service> type: #<service-type boot 7f8c969…> …))
       586:17  8 (map1 (#<<service> type: #<service-type linux-builde…> …))
    In gnu/services.scm:
      1031:29  7 (linux-builder-configuration->system-entry _)
    In guix/profiles.scm:
        439:4  6 (packages->manifest _)
    In srfi/srfi-1.scm:
       586:17  5 (map1 (#f))
    In guix/inferior.scm:
        549:2  4 (loop #f "out" #<promise #<procedure 7f8c96627f98 at gu…>)
        529:4  3 (inferior-package-input-field #f _)
       473:18  2 (inferior-package-field #f (compose (lambda (#) (…)) #))
    In ice-9/boot-9.scm:
      1685:16  1 (raise-exception _ #:continuable? _)
      1685:16  0 (raise-exception _ #:continuable? _)

    ice-9/boot-9.scm:1685:16: In procedure raise-exception:
    In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f

The (kernel (plain-file "fake-kernel" "")) leads to a different error:

    building /gnu/store/idy2sylx9zbvphzlqvhnldjvg242hd2a-linux-modules.drv...
    find-files: /gnu/store/jfcbq6djya5pi54yhpvzj66r18h4mp09-dummy-kernel-1/lib/modules: Not a directory
    Backtrace:
               4 (primitive-load "/gnu/store/sckm34nzvmkcynhgn6zs5aq6xfs?")
    In ice-9/eval.scm:
        619:8  3 (_ #f)
       626:19  2 (_ #<directory (guile-user) 7ffff77f7c80>)
        159:9  1 (_ #<directory (guile-user) 7ffff77f7c80>)
    In unknown file:
               0 (car ())

    ERROR: In procedure car:
    In procedure car: Wrong type (expecting pair): ()

For the record, before the pull I was successfully using this "kernel" package:

    (define %ct-dummy-kernel
      (package
        (name "dummy-kernel")
        (version "1")
        (source #f)
        (build-system trivial-build-system)
        (arguments
         (list
          #:builder #~(mkdir #$output)))
        (synopsis "Dummy kernel")
        (description
         "In container environment, the kernel is provided by the host.  However we
    still need to specify a kernel in the operating-system definition, hence this
    package.")
        (home-page #f)
        (license #f)))

Even if I adjust it to create the /lib/modules subdirectory, it just chokes down
the line on something else.

I think it would be best to just support (kernel #f) for container deployments,
since that would simplify it and keep it manageable.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[signature.asc (application/pgp-signature, inline)]

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tomas Volf <~@wolfsden.cz>
Cc: 70239 <at> debbugs.gnu.org
Subject: Re: bug#70239: (operating-system) structure requires a kernel
Date: Mon, 08 Apr 2024 14:28:58 +0200

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

Hi,

Tomas Volf <~@wolfsden.cz> skribis:

>     (operating-system
>       (host-name "guix")
>       ;; Servers usually use UTC regardless of the location.
>       (timezone "Etc/UTC")
>       (locale "en_US.utf8")
>       (firmware '())
>       (initrd-modules '())
>     ;  (kernel %ct-dummy-kernel)
>     (kernel #f)

[...]

>     In gnu/services.scm:
>       1031:29  7 (linux-builder-configuration->system-entry _)
>     In guix/profiles.scm:
>         439:4  6 (packages->manifest _)
>     In srfi/srfi-1.scm:
>        586:17  5 (map1 (#f))
>     In guix/inferior.scm:
>         549:2  4 (loop #f "out" #<promise #<procedure 7f8c96627f98 at gu…>)
>         529:4  3 (inferior-package-input-field #f _)
>        473:18  2 (inferior-package-field #f (compose (lambda (#) (…)) #))
>     In ice-9/boot-9.scm:
>       1685:16  1 (raise-exception _ #:continuable? _)
>       1685:16  0 (raise-exception _ #:continuable? _)
>
>     ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>     In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f

Indeed, ‘linux-builder-configuration->system-entry’ is not prepared for
that, but we can fix it.

> The (kernel (plain-file "fake-kernel" "")) leads to a different error:
>
>     building /gnu/store/idy2sylx9zbvphzlqvhnldjvg242hd2a-linux-modules.drv...
>     find-files: /gnu/store/jfcbq6djya5pi54yhpvzj66r18h4mp09-dummy-kernel-1/lib/modules: Not a directory
>     Backtrace:
>                4 (primitive-load "/gnu/store/sckm34nzvmkcynhgn6zs5aq6xfs?")
>     In ice-9/eval.scm:
>         619:8  3 (_ #f)
>        626:19  2 (_ #<directory (guile-user) 7ffff77f7c80>)
>         159:9  1 (_ #<directory (guile-user) 7ffff77f7c80>)
>     In unknown file:
>                0 (car ())
>
>     ERROR: In procedure car:
>     In procedure car: Wrong type (expecting pair): ()

I believe this one is a regression introduced in
8f8ec56052766aa5105d672b77ad9eaca5c1ab3c.  I believe this is fixed by
this patch:

[Message part 2 (text/x-patch, inline)]

diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm
index 561cfe2fd0..40ff2dc808 100644
--- a/gnu/system/linux-initrd.scm
+++ b/gnu/system/linux-initrd.scm
@@ -134,18 +134,23 @@ (define (flat-linux-module-directory linux modules)
                          (guix build utils)
                          (rnrs io ports)
                          (srfi srfi-1)
-                         (srfi srfi-26))
+                         (srfi srfi-26)
+                         (ice-9 match))
 
             (define module-dir
               (string-append #$linux "/lib/modules"))
 
             (define builtin-modules
-              (call-with-input-file
-                  (first (find-files module-dir "modules.builtin$"))
-                (lambda (port)
-                  (map file-name->module-name
-                       (string-tokenize
-                        (get-string-all port))))))
+              (match (find-files module-dir (lambda (file stat)
+                                              (string=? (basename file)
+                                                        "modules.builtin")))
+                ((file . _)
+                 (call-with-input-file file
+                   (lambda (port)
+                     (map file-name->module-name
+                          (string-tokenize (get-string-all port))))))
+                (_
+                 '())))
 
             (define modules-to-lookup
               (lset-difference string=? '#$modules builtin-modules))

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

Could you confirm?

> I think it would be best to just support (kernel #f) for container deployments,
> since that would simplify it and keep it manageable.

Yes, let’s do that too.

Thanks,
Ludo’.

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

From: Tomas Volf <~@wolfsden.cz>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 70239 <at> debbugs.gnu.org
Subject: Re: bug#70239: (operating-system) structure requires a kernel
Date: Tue, 9 Apr 2024 18:04:03 +0200

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

Hi,

On 2024-04-08 14:28:58 +0200, Ludovic Courtès wrote:
> [..]
>
> Could you confirm?

Yes, the attached patch fixed the issue for me. :)

>
> > I think it would be best to just support (kernel #f) for container deployments,
> > since that would simplify it and keep it manageable.
>
> Yes, let’s do that too.
>
> Thanks,
> Ludo’.

Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[signature.asc (application/pgp-signature, inline)]

Previous Next

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