Make Debian the official base?

[JohnMertz]

Images from this branch are now successfully building. We need a few things before we can be confident in this path over CentOS:

[x] - Successfully build images
[x] - Successfully test images
[x] - Successfully build disks
[x] - Successfully convert disks to all VM formats
[ ] - Boot the VM image in KVM.
[ ] - Successfully build iso
[ ] - Boot the iso image in KVM and install.
[ ] - Successfully test an upgrade.

A bare-metal deployment may be more difficult, but this hadn't even been tested with CentOS yet, so we can handle that down the road.

[JohnMertz]

As of the latest commit, the CI builds now work.

Currently just build-disk dies with the error:

error: Installing to filesystem: Creating ostree deployment: Preparing import: Fetching manifest: failed to invoke method OpenImage: invalid policy in "/etc/containers/policy.json": invalid character 'c' looking for beginning of value
Traceback (most recent call last):
File "/run/osbuild/bin/org.osbuild.bootc.install-to-filesystem", line 73, in <module>
    r = main(args["options"], args["inputs"], args["paths"])
  File "/run/osbuild/bin/org.osbuild.bootc.install-to-filesystem", line 68, in main
    subprocess.run(pargs, env=env, check=True)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/subprocess.py", line 577, in run
    raise CalledProcessError(retcode, process.args,
                             output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['bootc', 'install', 'to-filesystem', '--source-imgref', 'containers-storage:[overlay@/run/osbuild/containers/storage+/run/containers/storage]257db3e53af57dcc4339aaf7a3dbb6ee428bc2b437181812ce44325dd1979b4d', '--skip-fetch-check', '--generic-image', '--karg', 'rw', '--karg', 'console=tty0', '--karg', 'console=ttyS0', '--target-imgref', 'localhost/spamtagger-bootc:spamtagger-plus-13', '/run/osbuild/mounts']' returned non-zero exit status 1.

It looks like it is a JSON parse error. It's not entirely clear if this is caused by the policy.json created in container/build_files/finalize. That file appears to be valid and even if it is removed (or never created) the error seems to still be identical. This output comes from bootc-image-builder, so I'll probably have to look there for more info.

[JohnMertz]

As noted in last commit, disk images are now buildable using a new method. However, the images fail to boot in KVM, so I'm not sure if bootc-image-builder isn't worth another look.

I do get very close to booting if I click to customize the installation, force it to use UEFI, then enter the EFI firmware settings and disable secureboot. At that point it starts to initialize with systemd-boot, but fails at initrd-switch-root.service.

Continuing with this method means that I'll definitely need to fix secureboot. Also, BIOS boot works for Cayo, so ideally I'll get this to work as well.

Also a few notes on the disk image before I finish for the day:

• Mounting the disk in guestfish shows that 3 filesystems do exist:

><fs> list-filesystems
/dev/sda1: unknown
/dev/sda2: vfat
/dev/sda3: ext4

/dev/sda1 is a BIOS boot partition. /dev/sda2 is the EFI partition. /dev/sda3 contains the rootfs, with only boot, composefs, and state directories. Presumably the EFI partition, if mounted correctly should be able to mount the roofs. The EFI partition contains:

><fs> cat /boot/loader/entries/bootc-composefs-1.conf
title Debian GNU/Linux 13 (trixie)
version 13
linux /EFI/Linux/e646214cd8a4186c7cfa2a348625fb71ff3e10a8dea76b321ad33793c960a4e4138c8283db06b5957fa8f7118766d66f4a932d52113cea2bb9760996aaae3df6/vmlinuz
initrd /EFI/Linux/e646214cd8a4186c7cfa2a348625fb71ff3e10a8dea76b321ad33793c960a4e4138c8283db06b5957fa8f7118766d66f4a932d52113cea2bb9760996aaae3df6/initrd
options root=UUID=4f68bce3-e8cd-4db1-96e7-fbcaf984b709 rw composefs=e646214cd8a4186c7cfa2a348625fb71ff3e10a8dea76b321ad33793c960a4e4138c8283db06b5957fa8f7118766d66f4a932d52113cea2bb9760996aaae3df6
sort-key 1

Those initrd and vmlinuz files exist at that path. The UUID matches get-e2uuid /dev/sda3. And the composefs image exists in /composefs/images/.

So, everything seems fine there. The problem appears to be within the BootC configuration.

Another note is that my workstation seems to be out-of-date with the latest BootC. Attempting to build bootcrew/debian-bootc to compare to that project fails because I don't have composefs-backend as an installation option. I may need to spend the weekend actually getting my dogwood project fully up-to-speed so that I'm on the latest Fedora 43.