Add system_b boot partition to aboot images

Currently facing the issue below when building abootqemu images. There seems to be an issue with the hard link implemented via the aboot-update package. Resulting in the output below and failure to build.

org.osbuild.copy: 10b597eaa343bc1b0fdc895b03a3d26c49d6a2feedf315a574b1737a89d3edd7 {
  "paths": [
    {
      "from": "input://tree/",
      "to": "mount://root/"
    }
  ]
}
device/boot (org.osbuild.loopback): loop0 acquired (locked: False)
device/boot_a (org.osbuild.loopback): loop1 acquired (locked: False)
device/boot_b (org.osbuild.loopback): loop2 acquired (locked: False)
device/root (org.osbuild.loopback): loop3 acquired (locked: False)
mount/root (org.osbuild.ext4): mounting /dev/loop3 -> /root/sample-images/osbuild-manifests/_build/osbuild_store/tmp/buildroot-tmp-2w4i0zds/mounts/
mount/boot (org.osbuild.ext4): mounting /dev/loop0 -> /root/sample-images/osbuild-manifests/_build/osbuild_store/tmp/buildroot-tmp-2w4i0zds/mounts/boot
Failed to open file "/sys/fs/selinux/checkreqprot": Read-only file system
copying '/run/osbuild/inputs/tree/.' -> '/run/osbuild/mounts/.'
cp: cannot create hard link '/run/osbuild/mounts/././aboot.img' to '/run/osbuild/mounts/././boot/ostree/centos-16f9ce5bf7e2aa3a023255303c7952029faca8c2052d2abf486514d04cfc86d2/aboot-5.14.0-424.377.el9iv.aarch64.img': Invalid cross-device link
Traceback (most recent call last):
  File "/run/osbuild/bin/org.osbuild.copy", line 170, in <module>
    r = main(_args, _args["options"])
  File "/run/osbuild/bin/org.osbuild.copy", line 163, in main
    subprocess.run(cmd + [src, dst], check=True)
  File "/usr/lib64/python3.9/subprocess.py", line 528, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['cp', '-a', '--reflink=auto', '/run/osbuild/inputs/tree/.', '/run/osbuild/mounts/.']' returned non-zero exit status 1.
mount/boot (org.osbuild.ext4): umount: /root/sample-images/osbuild-manifests/_build/osbuild_store/tmp/buildroot-tmp-2w4i0zds/mounts/boot unmounted
mount/root (org.osbuild.ext4): umount: /root/sample-images/osbuild-manifests/_build/osbuild_store/tmp/buildroot-tmp-2w4i0zds/mounts/ unmounted

FYI, @ecurtin

added 52 commits

1aed7aca...f3e7cd46 - 51 commits from branch CentOS/automotive:main
00c378e3 - Add system_b boot partition to aboot images

Compare with previous version

Pending the merge of CentOS/automotive/rpms/aboot-update!20 (merged)

added 1 commit

107c1eb5 - Add system_b boot partition to aboot images

Compare with previous version

added 7 commits

107c1eb5...7dac5b21 - 6 commits from branch CentOS/automotive:main
062485d6 - Add system_b boot partition to aboot images

Compare with previous version

@ecurtin I wonder could I get a review of this MR when you've got time please, which is also linked to this CentOS/automotive/rpms/aboot-update!20 (merged).

The output below is from a build of cs9-abootqemu-minimal-ostree.aarch64.qcow2

/dev/loop0: TYPE="erofs"t-02 ~]# blkid
/dev/vda1: LABEL="system_b" UUID="156f0420-627b-4151-ae6f-fda298097515" TYPE="ext4" PARTLABEL="system_b" PARTUUID="61b2905b-df3e-4fb3-80fa-49d1e773aa32"
/dev/vda6: UUID="76a22bf4-f153-4541-b6c7-0332c0dfaeac" TYPE="ext4" PARTLABEL="system_a" PARTUUID="6264d520-3fb9-423f-8ab8-7a0a8e3d3562"
/dev/vda4: PARTLABEL="vbmeta_a" PARTUUID="da91d469-09b3-ce43-795e-3b86f3735143"
/dev/vda2: PARTLABEL="boot_a" PARTUUID="1dd3a986-997c-0c48-1d1b-b0d0399f3153"
/dev/vda5: PARTLABEL="vbmeta_b" PARTUUID="305087ff-bf9a-910d-f3c4-606a8de7788a"
/dev/vda3: PARTLABEL="boot_b" PARTUUID="45105095-3847-4657-51f2-2a0144550453"
[root@ibm-p8-kvm-03-guest-02 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0    7:0    0  2.6M  1 loop 
vda    254:0    0    8G  0 disk 
├─vda1 254:1    0  300M  0 part /boot
├─vda2 254:2    0   64M  0 part 
├─vda3 254:3    0   64M  0 part 
├─vda4 254:4    0   64K  0 part 
├─vda5 254:5    0   64K  0 part 
└─vda6 254:6    0  7.6G  0 part /var
                                /sysroot/ostree/deploy/centos/var
                                /sysroot

marked this merge request as ready

Green builds!

This is good, next step is to put everything behind an is_initoverlayfs toggle which is set to false. We don't want to push this into everyone's builds until the whole initoverlayfs solution is complete.