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.