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
Description: PGP signature
