Fedora Account System
Red Hat Associate
Red Hat Customer
Anaconda ignore keyboard specified in kickstart when installing bootc image Reproducible: Always Steps to Reproduce: This config.toml [customizations.installer.kickstart] contents = """ text zerombr keyboard --vckeymap=fr --xlayouts=fr lang fr_FR.UTF-8 clearpart --all --initlabel autopart --encrypted --passphrase=password rootpw password """ Build anaconda iso : sudo podman run --rm -it --privileged --pull=newer \ --security-opt label=type:unconfined_t \ -v ./output:/output \ -v /var/lib/containers/storage:/var/lib/containers/storage \ -v ./config.toml:/config.toml:ro \ quay.io/centos-bootc/bootc-image-builder:latest \ --type anaconda-iso \ --chown 1000:1000 \ --rootfs=btrfs \ quay.io/fedora-ostree-desktops/silverblue:43 Actual Results: Keyboard is unset on installed system Expected Results: Keyboard is FR on installed system Additional Information: Anaconda 43.44
Created attachment 2128149 [details] install logs
Based on a preliminary investigation, it seems that the culprit may be something else than Anaconda (likely bootc-image-builder). I've built an F43 Silverblue ISO as mentioned in the bug description, and tried out the following scenarios: 1. Installation from F43 bootc-image-builder ISO. 2. Installation from F43 bootc-image-builder with an equivalent kickstart file and container image both places outside of the ISO (HTTP server and container registry). 3. Installation from F43 Silverblue ISO with kickstart/container image as in scenario #2. In scenario #1 and #2, the keyboard wasn't set as expected and also the installation ran in English. In scenario #3, which should be functionally equivalent, Anaconda ran in French and also the keyboard layout in the installed system was set up properly. Here's the kickstart used in #2 and #3: ----------- 8< ----------- ostreecontainer --transport=registry --url=quay.io/fedora-ostree-desktops/silverblue:43 %post --erroronfail set -e bootc switch --mutate-in-place --transport registry quay.io/fedora-ostree-desktops/silverblue:43 # used during automatic image testing as finished marker if [ -c /dev/ttyS0 ]; then # continue on errors here, because we used to omit --erroronfail echo "Install finished" > /dev/ttyS0 || true fi %end text zerombr keyboard --vckeymap=fr --xlayouts=fr lang fr_FR.UTF-8 clearpart --all --initlabel autopart --encrypted --passphrase=password ----------- 8< ----------- rootpw password
I don't understand the scenario 3. The container is inside the iso ? (So ostreecontainer is useless). What is the difference with my scenario?
In scenario 3, the container image is fetched from the registry and the kickstart from HTTP, but the ISO used to boot and install the system is a stock F43 Silverblue boot.iso. In theory, it should be functionally equivalent to using the ISO built by bootc-image-builder, but apparently there's some difference (in favour of the stock ISO). One wouldn't perform an installation this way under normal conditions, the only reason I did so was to find out whether the installation environment/configuration is the same for stock ISO and ISO built by b-i-b. I'm not sure if I understand correctly what you're getting at with ostreecontainer, but I believe you mean the kickstart command? If this is the case, the command is necessary under all conditions when you want to install a bootable container image (unless you use the 'bootc'[1] command, but the overall outcome should be basically equivalent from the user's perspective and apparently it is not used (yet?) by Silverblue and I'm only mentioning it for the sake of completeness, it doesn't seem to be relevant here). [1] https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#bootc
I'm going to open issue with bootc-image-builder upstream repo. I think they'll quickly understand what's going on. Thank you
This is due to the way the `anaconda-iso` type configures which Anaconda modules are enabled. By default the Localization module isn't included and thus the kickstart verb isn't processed. If manually enabled then things work as expected. Explanation upstream: https://github.com/osbuild/bootc-image-builder?tab=readme-ov-file#anaconda-iso-installer-modules If William confirms there that this fixes things for them then this issue can be considered done.
Thanks a lot Simon