Atomic desktop ostrees do not include anaconda-tools group
AFAICT, the comps-sync script in workstation-ostree-config does not pull in the anaconda-tools group.
This group's purpose is to define things that might need to be deployed on the installed system (not in the installer environment - those are defined differently), depending on how you configure things in the installer. So, for instance, it includes iscsi-initiator-utils in case you install to an iSCSI device, device-mapper-multipath in case you install to multipath storage, mactel-boot and hfsplus-tools in case you install on an Intel Mac, and realmd in case you enrol into a realm as part of installation.
With Ye Olde Way Of Doing Things - a DVD install image, deploying a system based on RPM packages - the point of the group is to make sure those packages are available to the installer to be deployed into the installed system. On DVD installer images, this means they get included in the package repo on the DVD itself.
For live images, due to the limitations of the format, we simply include all the packages from the group on the live images, just in case they actually turn out to be necessary in the installed system (except a few that are specifically excluded in the live kickstarts). That's the best we can do.
Logically speaking, ostrees should probably follow the live image precedent - since we know any of these packages might be necessary, depending what you choose in the installer, and the installer cannot adjust the ostree contents on the fly, we should include all of them in the ostrees (and just exclude ones we're very sure aren't appropriate in context).
In practice, these are the packages listed in that group which are not included in the current x86_64 Silverblue ostree (several actually get pulled in via other dep chains), per https://kojipkgs.fedoraproject.org/compose/branched/Fedora-39-20230925.n.1/logs/x86_64/Silverblue/ostree-8/create-ostree-repo.log :
- device-mapper-multipath
- dracut-network
- fcoe-utils
- gfs2-utils
- grub2-efi-ia32-cdboot
- grub2-efi-x64-cdboot
- grub2-tools-efi
- grub2-tools-extra
- iscsi-initiator-utils
- kdump-anaconda-addon
- mactel-boot
- nvme-cli
- sdubby
- teamd
I'm not sure all of those are really necessary. Here's a quick audit:
- anaconda (via blivet) installs device-mapper-multipath on installs to multipath storage, as you'd expect
- anaconda (via blivet) installs dracut-network in various 'remote storage' cases (NFS, iSCSI, FCoE)
- anaconda (via blivet) installs fcoe-utils when installing to FCoE (that's fiber channel over ethernet, it's an enterprise remote storage tech)
- anaconda (via blivet) installs gfs2-utils if any gfs2 filesystems are included in the install (it contains the fsck tool, so presumably without this, we cannot verify filesystem integrity on boot)
- anaconda does not, AFAICT, ever install grub2-efi-ia32-cdboot or grub2-efi-x64-cdboot, so they probably don't need to be in the list
- anaconda installs grub2-tools-extra (and grubby) on all EFI grub installs since https://github.com/rhinstaller/anaconda/commit/1891b0f306cc252e32335ac185a609df1828edb7 , which is part of https://github.com/rhinstaller/anaconda/pull/4368 . I am not sure what "removed from comps" means there, I cannot find anything in comps git history which seems to match, so I'm not sure how necessary this is
- anaconda installs grub2-tools-efi and mactel-boot on Intel Mac installs - grub2-tools-efi contains a command called
grub2-macbless
which I suspect is needed to make these installs bootable - anaconda installs iscsi-initiator-utils if you install to iSCSI
- the inclusion of kdump-anaconda-addon traces back to https://pagure.io/fedora-kickstarts/pull-request/31 , where Dennis Gilmore recommended it be added there; I don't think that was right, though it had the desired effect. The package needs to be in the installer environment, so adding it to anaconda-tools was kinda wrong. Anyhow, in practice, it is on ostree installer images because it's also pulled in by lorax runtime-install.tmpl , but the feature probably doesn't work on them, because it requires kexec-tools to be in the installed system, and it's not (at least not in Silverblue)
- anaconda (via dracut) installs nvme-cli when installing to an NVMe storage device, it provides utility tools for NVMe devices
- anaconda installs sdubby when you boot with
inst.sdboot
to enable the experimental systemd-boot support. we should probably omit it from ostrees, much as we omit grubby - anaconda installs teamd if you configure a teamed network device during install, I believe it's necessary for the device to work on boot
so to summarize - the practical results of this are probably that installing systems built from these manifests to remote storage (iSCSI, FCoE, NFS), multipath storage, or with teamed network devices will not work. I'm not sure about Intel Macs - I know bootloader handling works differently on ostree installs, I don't know whether that means we don't need mactel-boot or grub2-tools-efi in the ostrees. Installing to gfs2 filesystems and/or NVMe devices will work, but useful/expected tools will not be present on the installed system.
Probably the right thing to do here is add anaconda-tools to the groups that are synced in comps-sync, maybe with some targeted exclusions, like bootloader stuff that does not need to be in the ostrees.