Fix the templates for current GNU Guix

[aither64]

Thanks :)

[aither64]

The build currently fails with

++ guix system init --no-bootloader /build/basedir.421f5743/images/guix/system.scm /build/installdir.421f5743
[...builds lots of stuff...]
initializing operating system under '/build/installdir.421f5743'...
;;; Failed to autoload call-with-database in (guix store database):
;;; Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (sqlite-register (guix store database)) #f)'.
Backtrace:
          16 (primitive-load "/root/.config/guix/current/bin/guix")
In guix/ui.scm:
   2326:7 15 (run-guix . _)
  2289:10 14 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
    859:3 12 (_)
    839:4 11 (call-with-status-report _ _)
In guix/scripts/system.scm:
   1305:4 10 (_)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   661:37  8 (thunk)
   1300:8  7 (call-with-build-handler _ _)
   1300:8  6 (call-with-build-handler _ _)
   1300:8  5 (call-with-build-handler #<procedure 7f4375897db0 at g?> ?)
  2180:25  4 (run-with-store #<store-connection 256.99 7f4360311190> ?)
In guix/scripts/system.scm:
    246:6  3 (_ _)
    190:5  2 (_ _)
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:
error: call-with-database: unbound variable

This doesn't tell me anything. From the time I worked on the template, I remember that errors were cryptic when there was a problem in vpsadminos.scm. I used to get proper errors when everything was in system.scm, I split it into two files only later when I had it working. So unless you can see what could be wrong from this log, perhaps we could try to merge it all to system.scm.

[graywolf]

Yes, the error messages suck hard :/. I have to say I am not very wise from this one.

How often is this build process executed? Or rather, are we sure this was caused by my changed? I tried it on the VPS and the system configured just fine, so I am trying to figure out if there is something different in the build process or if I fucked up somehow.

Technically you can just try it once more, there were some issues with Guix master today, so maybe you just had bad timing. However it is pretty unlikely.

I know I asked already (sorry!), do we have a guide how to setup this in a VM so that I can try? I guess I can just boot up https://iso.vpsadminos.org/ in qemu, mount the dir into it and follow https://vpsadminos.org/container-images/creating/, is that correct assumption? Is the "--build-dataset tank/image-builds" working in the qemu out of the box or is some extra configuration required?

EDIT: I ask the last paragraph so that I can waste my time on this instead of yours :)

[aither64]

This error is new, previous build failed with

building profile with 1 package...
building /gnu/store/fr2ynazs9w4hdlv3rsvn8adsmmywpyqd-90-kvm.rules.drv...
applying 7 grafts for eudev-3.2.14 ...
applying 7 grafts for eudev-3.2.14 ...
applying 27 grafts for guix-1.4.0-18.4c94b9e ...
applying 6 grafts for libfido2-1.12.0 ...
building /gnu/store/pnnxjbhz83iwjjvjq3mh3ppb7vy3skqw-linux-modules.drv...
builder for `/gnu/store/pnnxjbhz83iwjjvjq3mh3ppb7vy3skqw-linux-modules.drv' failed with exit code 1
build of /gnu/store/pnnxjbhz83iwjjvjq3mh3ppb7vy3skqw-linux-modules.drv failed
View build log at '/var/log/guix/drvs/pn/nxjbhz83iwjjvjq3mh3ppb7vy3skqw-linux-modules.drv.gz'.
cannot build derivation `/gnu/store/njc6j2jhm1vh5ily2kprfrmjz9m76rwp-init.drv': 1 dependencies couldn't be built
applying 5 grafts for lvm2-2.03.22 ...
cannot build derivation `/gnu/store/0cgw52zbn2mvq7bnwwi2phyz8ghgi4p3-raw-initrd.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/1hl5bm72kbv0mhwi85h618br6bllfyvf-grub.cfg.drv': 1 dependencies couldn't be built
guix system: error: build of `/gnu/store/1hl5bm72kbv0mhwi85h618br6bllfyvf-grub.cfg.drv' failed

which is probably what you wanted to fix. Templates are built every Saturday, it started to fail this way in March.

When you boot vpsAdminOS ISO, you first need to setup ZFS pool. It can be stored in a file or you can add block device using qemu to make it persistent. So e.g. zpool create tank sda if it is a block device, I recommend at least 10 GB, it depends on how much space Guix needs. Then install the ZFS pool into osctld: osctl pool install tank.

Before you can use osctl-image, create a build dataset with zfs create tank/image-builds. Then osctl-image build --build-dataset tank/image-builds guix will try to build Guix template. By default, it will use image-scripts from the same revision of vpsAdminOS as the ISO. You will want to use your own modified scripts, so git clone or otherwise provide vpsAdminOS repository, cd into image-scripts/ and run the same osctl-image command. osctl-image test --build-dataset tank/image-builds guix will run tests (and build the template if it is not built already).

I should say that the ISO is probably not used by anyone, so let me know if there's something wrong with it. I'm currently deploying a new version, should be done within two hours.

[aither64]

I'm also trying to rebuild the template, will report how it turns out.

[aither64]

Failed as in https://github.com/vpsfreecz/vpsadminos/pull/66#issuecomment-2041177372

[graywolf]

https://issues.guix.gnu.org/70245 it looks like this got broken by upstream. I now even understand what the error message says :D

I will create a new PR pinning Guix to known-good version (and a new one removing the pin after upstream fixes it). Probably tomorrow.

[aither64]

It's already fixed in guix master and the template was built successfully!