We had this weird condition in code that prevented composer to create groups
with the same name as a user has. This unfortunately means that you are not
able to create a user with a primary group with a certain GID that has the
same name as the user. There's the gid field in the user customization,
but it requires that the group already exists.
In order to allow that, we need to remove the condition. From now on, it's
possible to create groups with the same name as a user has, which can be used
to create primary groups with a custom gid.
Note that the lorax compatibility behaviour was actually wrong. When lorax was
given a custom gid for a user, it didn't require the gid to exist. When it
didn't, the group was just created. Thus, we still don't have full backward
compatibility, but at least we now have support for this.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Regenerate image manifests which use the files customization and are
affected by the recent change to `osbuild/fsnode.go`, specifically to
always setting the `RemoveDestination` to `true`.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add the new directories and files customization to the customized qcow2
image manifests used for testing.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Move the handling of the list of enabled and disabled systemd services
more to the end of the `os` pipeline, just before the SELinux stage.
This has no functional effect on produced images, but it will make it
nicer once the handling of the custom files and directories will be
added to the pipeline. Specifically it should be added right before the
services stage to allow enabling custom service files, but after all
other configurations that are applied to the image.
Regenerate all manifests.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Our 'customize' test manifests include an option to disable the
bluetooth.service. Originally this option was added for image types
that included bluez in their default package set (Fedora IoT commit) but
it was later copied to the qcow2 image type as a way of testing
customizations.
Until recently, building these caused no issues. On distros with more
recent versions of systemd, disabling a non-existent service causes an
error and these manifests fail to build.
Added the 'bluez' package to all manifests that include the 'disable
bluetooth.service' customization and updated the manifests. These
should all be buildable now.
The big rewrite of rhel9 distro omitted installing s390utils-base into the
buildroot. This caused the org.osbuild.zipl.inst stage because of missing
/usr/sbin/zipl.
This commit introduces s390utils-base back into the buildroot which fixes
building of the s390x images.
I verified it by building the RHEL 9.1 qcow2 image and booting it using
libvirt.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
All RHEL 9.x manifests have been affected except edge-installer,
edge-raw-image, and edge-simplified-installer. These are image types
that carry a pre-built payload so don't have an OS pipeline and don't
include RHSM facts.
Adding python3-pyyaml to the build root for manifests that contain
cloud-init in the OS pipeline.
Adding python3-iniparse to the build root for manifests that contain
rhsm or dnf.config in the OS pipeline.
Regenerate all manifests that used the old chrony stage options with the
'timeservers' field. This is now replaced by the 'servers' field, which
is a slice of objects with a 'hostname' field instead of a slice of
strings.
Regenerated manifests for the QCOW2, OCI, and openstack image types with
the rewritten definitions.
The skopeo stage is not yet added by the live image pipeline.
The following changes in the manifests should affect the final image:
- Removed RPMs in the build root: packages are added to the build-root
on-demand by the payload pipelines. All removed packages were
unnecessary for building the image.
- /usr/bin/tar removed form selinux stage: tar should be added on-demand
if it's needed by any of the payload pipelines.
Added a filesystem customization to the qcow2 test case to test that the
filesystem is converted to an LVM layout.
Set overrides for distros that don't support fs customizations.
Blueprint package set is now depsolved together with the OS package set
in a chain. The result is stored in the package specs sets under the OS
package set name.
In reality, the code was able to handle a `nil` package specs to be
passed to pipelines, however some parts were looking for the kernel
version in the blueprint package specs, which would be a bug.
Regenerated affected image test cases.
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>
Use single NewGroupsStageOptions() from osbuild2 instead of implementing
in each distro.
The new function does not set the Group.Name field anymore. The field
does not exist in the osbuild schema and was silently ignored.
The field in the stage has been marked 'omitempty' and the relevant
manifests have been updated.
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
Whenever we create a new mountpoint due to a user customization,
ensure the layout uses LVM, i.e. convert plain layouts to it, if
needed. This does not apply to rpm-ostree based systems, e.g. the
simplified installer since they will be using LUKS in 9.0.
Add "lvm2" to the build pipeline and thus generate new manifests
and image infos.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
With the new grub2 stage options we have the following changes to the
grub2 stage:
- Set the WriteCmdLine flag to false to not write kernel command line
options to grubenv.
- Don't set the kernel command line options in the stage options.
The kernel command line options are now only specified in the Kernel
command line stage (org.osbuild.kernel-cmdline) so we add all options
there:
- Image type options
- Blueprint options
- Partition-table-specific options
Updated manifests and image info.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Use entity based method `ForEachMountable` and `getDevices` to generate
all mounts and devices in a generic way, which then allows for mounts on
arbitrarily nested devices.
Update manifests and image info:
- New device names generated by `pathdot()` to avoid basename
collisions.
- Some partitions are generated in a different order now which changes
the order they appear in the manifest and their UUIDs.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Instead of hard coding a padding of 100 sectors for all layouts, i.e.
MBR and GTP, adjust the needed space depending on the layout: for MBR
we don't need to reserve any space at all since it does not have a
secondary header. For GTP we reserve 33 sectors, as indicated in the
UEFI specific, which allows for the header itself and up to 128 entries.
To not modify the layout of already released distributions, like RHEL
8.4 and 8.5, a new member called `ExtraPadding` is added to `Partition
Table` and then used in the corresponding layouts to preserve the
existing padding of 100.
This is needed to satisfy RPM dependencies of GCP guest tools, which
will be installed on the `gce` image type.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Setting of the `crashkernel` option to the appropriate value is now done
by the `kexec-tools` package when installed and when any new kernel is
installed.
Regenerate relevant image test cases.
Fix#1819
Fix rhbz#2006692
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The unification of the partition table also introduced uuids and
types in uuid form for partition tables in dos layout, sill used
on PPC64LE and s390x. The org.osbuild.sfdisk stage did work with
that but produced a `/boot` partition with the wrong type, which
grub2 refused to read from and thus prevented boot. Fix this by
removing uuids from the dos partition tables.
Reported-by: Jakub Rusz <jrusz@redhat.com>
The `@core` package group used to include TuneD package by default on
RHEL-8. It has been removed from the group in Fedora as part of [1] and
inherited into RHEL-9. As a result, TuneD is no longer installed by
default on RHEL images.
After a discussion on rhel-devel there seems to be an agreement, that
TuneD should be installed by default on all RHEL virtual images. At
least we should keep the consistency in this regard with RHEL-8.
Regenerate all RHEL-9.0 image test cases.
Related to https://bugzilla.redhat.com/show_bug.cgi?id=2026709
[1] https://pagure.io/fork/adelton/fedora-comps/c/a5d4f1b6c9fcbe20cb0c38eac5048d7d45d1dd17
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Because the RHUI client RPMs for RHEL-9 don't exist yet, these test
cases use the RHUI client RPMs for RHEL-8 to satisfy the required
package set. These RPMs contain the entitlement certificate and repo
definitions for RHEL-8 AWS RHUI repos, but RHUI will not work without
the image being imported with the proper Billing Code to AWS. So these
installed RHUI RPMs are technically useless on the RHEL-9 image, but
this approach is good enough to allow us to at least build and test
these images from configuration point of view.
Regenerate all image test cases because of the updated repositories.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
