Skip to content

Bootc detection easily matches non-bootc systems #13990

@comps

Description

@comps

Share the context

The checks in shared/checks/oval/bootc.xml easily match VMs installed on our infrastructure, due to all the conditions being met, despite not using bootc systems.

Description of problem:

Specifically:

  • oval_test_package_installed(package=kernel_package - regular VM has a kernel
  • oval_test_package_installed(package="rpm-ostree" - any system can have this installed without itself being a bootc or ostree system
  • oval_test_package_installed(package="bootc" - same thing, in fact - some people execute bootc status --format json to check whether the system itself is bootc or not, and for that, they need bootc installed
  • oval_test_package_removed(package="openshift-kubelet" not present on the regular non-bootc system either

I ran into this when pre-installing Contest test dependencies from all tests onto the VM disk image, so that it could be restored/cloned and any Contest test executed on it quickly, without the test installing (again and again) its own RPM dependencies.

But that meant using a kickstart with %packages containing some RPMs that could bring in bootc and/or rpm-ostree:

Click to see the kickstart with full package list
lang en_US.UTF-8
keyboard --vckeymap=us
network --onboot yes --bootproto dhcp
rootpw --iscrypted ...
firstboot --disable
selinux --enforcing
timezone --utc Europe/Prague
bootloader
reboot

zerombr
clearpart --all --initlabel
autopart --type=plain --nohome

# this already includes @core
%packages
# rngd eats all CPU cores for a while after boot, and we have virtio-rng
-rng-tools
# necessary for ATEX
rsync
%end

# pre-install Contest dependencies to speed up test execution
# this was generated via: atex fmf --plan /plans/weekly requires
%packages --ignoremissing
ansible-core
bats
cmake
composer-cli
createrepo
dnf-utils
firewalld
gcc-c++
git-core
libvirt-client
libvirt-daemon
libvirt-daemon-driver-network
libvirt-daemon-driver-qemu
libvirt-daemon-driver-storage-core
openscap-scanner
openscap-utils
osbuild-composer
podman
python-srpm-macros
python3
python3-devel
python3-dnf
python3-jinja2
python3-pip
python3-pyyaml
python3-requests
python3-setuptools
qemu-kvm
rhc-worker-playbook
rpm-build
scap-security-guide
scap-security-guide-rule-playbooks
virt-install
yum-builddep
yum-utils
%end

# kdump regenerates dracut on first boot, eating tons of CPU
%addon com_redhat_kdump --disable
%end
%post
systemctl --quiet disable kdump.service
%end

The end result is that I'm getting several grub2 rule failures, because (I believe) OpenSCAP thinks I'm on a bootc system, when I'm not.

Proposed change:

So please use some more reliable means of detecting bootc if possible, some ideas I've seen people use:

  • bootc status (see all its options) via SCE, not sure if it works offline
  • If /run/ostree-booted exists, the system is ostree, and likely also bootc, but this doesn't work offline

Pinging @jan-cerny and @matusmarhefka as SMEs.

Metadata

Metadata

Assignees

Labels

Image ModeBootable containers and Image Mode RHELRHELRed Hat Enterprise Linux product related.RHEL10Red Hat Enterprise Linux 10 product related.RHEL9Red Hat Enterprise Linux 9 product related.triaged

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions