Edge and IoT manifests are modified from the new option handling. The
"parent" commit ID isn't specified in the options anymore, but it is
(fake) resolved by the manifest generator.
Of particular note is the iot-raw-image manifest that now properly uses
the commit ID in the copy stage for the firmware.
The resolved ostree commits are now stored in the content part of the
manifest metadata alongside package specs and containers.
It turned out that when we stopped setting the kernel options in grubenv
file, we also stopped setting them in /etc/default/grub under
`GRUB_CMDLINE_LINUX`. This file is used by grub2-mkconfig when
generating grub configuration.
10_linux script executed by grub2-mkconfig recently started to overwrite
the /etc/kernel/cmdline, if its timestamp is older than the timestamp of
/etc/default/grub [1]. As a result, all kernel options were wiped out from
/etc/kernel/cmdline.
Make sure that we always set the `KernelOptions` in the grub2 stage
options, even if the `WriteCmdLine` is set to `false`.
In addition, unify the way we concatenate kernel options set in the
grub2 stage options. Some pipeline implementations were previously using
space, other were using comma. Space is now used everywhere.
Regenerate all affected image manifests.
[1] https://src.fedoraproject.org/rpms/grub2/c/fc76aed5333f56dd05400521a35b944a5df52ebc
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The previous value for parent was not a valid commit ID. In a regular
compose request, the parent ref is resolved before being added as a
source in the manifest. However, when building test manifests, since
the values aren't real, we don't resolve the ostree refs, meaning that
the test manifests weren't valid — they failed validity checks if run in
osbuild.
Replaced the fake parent ref with a fake parent commit ID
"ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff".
The manifests still aren't buildable, since they don't point to a valid
ostree repository or commit, but now they're at least valid (in the
technical sense).
We used to always set the sysroot.readonly setting to true, but this
never worked because of a bug in osbuild [1].
The bug is now fixed and the RHEL and CentOS edge-raw images are crated
with sysroot.readonly = true, and the images aren't booting.
Fixing the option to false. This changes the manifests, but not the
generated images because of the change in osbuild.
If sysroot is meant to be readonly, we will change it in a future
update.
[1] https://github.com/osbuild/osbuild/pull/1129
We should honour `pkg.CheckGPG` when creating the file inputs for the
rpm stage. This was lost in the transition from v1 to v2 manifests.
Regenerate image test manifests.
Co-authored-by: Tomas Hozza <thozza@redhat.com>
Signed-off-by: Tomas Hozza <thozza@redhat.com>
This is only required in RHEL9.0, but best practice is to always pin these things
down. Also increases uniformity between distros.
Simplify a bit the volid generator by making it require `rand.Rand` rather than
`io.Reader`, and hence eliminating the need for error handling.
Since udev will probe block devices it is advisable to hold a lock
on the device when modifying its partition table or the superblock
of the filesystem (see [1]). osbuild loopback devices do support
this via the `lock` option. Set this option for all operation that
involve changing block device "metadata" that could potentionally
race with udev, such as sfdisk, mkfs, creating a luks2 container
and creating LVM2 volume groups and logical volumes.
NB: osbuild also has its own device inhibition logic to prevent
udev/lvm2 from auto activating devices and in general to limit the
interaction between the host and devices used by osbuild. See [2]
for more information.
NB: this also locks the loopback device in situation where we the
it is strickly not the right thing to do, e.g. when creating a fs
on a logical voume that is located on a loopback device, since in
this case the device we would need to lock is the logical volume.
Sadly, LVM/DM devices are exempt from block device locking. But,
due to a bug in osbuild < 50, the udev inhibitor does *not* work
for loopback devices and therefore we have to use the actual lock
to preven LVM device auto-activation via `69-dm-lvm-metad.rules`.
The change was implemented by adding a new boolean to `getDevices`
indicating if the loopback device should be locked or not. Once
we depend on osbuild 50 we can change the logic in `getDevices`
to only lock the loopback device if the number of devices is one,
i.e. we are working directly on the loopback device.
[1] https://systemd.io/BLOCK_DEVICE_LOCKING/
[2] /usr/lib/udev/rules.d/10-osbuild-inhibitor.rules
We want to support LVM on all image types (optionally) so let's make
lvm2 available in all build roots.
Manifests and image info updated for RHEL 8.6 and CentOS Stream 8.
Signed-off-by: Achilleas Koutsou <achilleas@koutsou.net>
