 |
Hello. Please try the following images: http://dl.rockylinux.org/stg/rocky/9/images/x86_64/Rocky-9-GenericCloud-9.0-20220830.0.x86_64.qcow2 http://dl.rockylinux.org/stg/rocky/9/images/x86_64/Rocky-9-GenericCloud.latest.x86_64.qcow2 |
 |
Looks fine aside from a small locale / glibc langpack issue. According to localectl: System Locale: LANG=en_US.UTF-8 Installed glibc langpacks: glibc-minimal-langpack-2.34-28.el9_0.x86_64 Which results in warning when running sudo dnf update and likely other commands: "Failed to set locale, defaulting to C.UTF-8" Can be fixed by installing "glibc-langpack-en" or using "LANG=C.UTF-8" by default. Otherwise, the image boots in BIOS mode on openstack, cloud-init/growpart work, seems totally functional. |
|
|
trivial issue. Since this image is for use in virtual environments, it would be nice to have the virt-what package installed by default since some software uses it to detect that this is a virtual environment. |
|
|
In addition to the missing glibc-langpack-en mentioned earlier, I just noticed another odd behavior with the new image Rocky-9-GenericCloud-9.0-20220830.0.x86_64.qcow2: With the old image, output of cloud-init was logged to the console (/dev/ttyS0) as well as to /var/log/cloud-init-output.log With the new image, logging of cloud-init on the console is gone. This affects automated provsioning of custom snapshots here, where we monitor a VMs console for specific patterns in order to detect errors in an early stage and then prevent out automated provisioning process from createing a possibly broken snapshot. I just tested current Alma9 in regards to that and it still produces cloud-init output on the console. Since both provide the same cloud-init package version, I assume this is not an issue of cloud-init itself but some side effect of a generic configuration change. Will test the same with rhel-baseos-9.0-x86_64-kvm.qcow2 from RedHat later. PS: I would look into your image-creation process myself, but I can't find any public (git?) repo. The only one that I found is https://github.com/rocky-linux/sig-cloud-instance-images but that one appears to be for docker. So: Where the heck are the scripts that you use for generating the official images? |
 |
Working on new images this week which will address these concerns. I'll have to look into the cloud-init one a bit more, but that shouldn't be too hard. I suspect something going on with the console parameter. @Fritz regarding the scripts for image generation. we're moving things into our toolkit in a subproject. Specifically ,the image building script is here: https://git.resf.org/sig_core/toolkit/src/branch/devel/iso/empanadas/empanadas/scripts/build_image.py I need to work on some docs for usage, but largely that's how the images get generated in our semi-hand-fed pipeline. |
|
|
Hello. All kickstarts are here: https://git.resf.org/sig_core/kickstarts or the mirror here: https://github.com/rocky-linux/kickstarts The langpack* packages have always been excluded in our images since we started making them. This was a carry over from how CentOS does it (including in stream 9). We usually remove and add packages that we may feel that do or don't fit as well. For context with the locale piece: As far as I'm aware, the locale piece is actually a bug of cloud init that should be fixed in 22.2 (or a patched 22.1 that's currently in CentOS Stream 9). I did a hotfix for the next image we build to force the locale to be C.UTF-8 in the meantime. See this commit: https://git.resf.org/sig_core/kickstarts/commit/ebf7a38c6b3f81512daaf0f4938148c1a576750b As for the console portion, it's a strange case. We have tried to adjust the parameters in the kickstart bootloader line and we have also tried to use sed and grubby within %post to try to resolve the problem. What ends up happening with the changes we try is we no longer get any console on ttyS0, not even a login prompt. We have also tried to inherit a fedora-like configuration specifying `console=tty1 console=ttyS0,115200n8` at the end of the bootloader configuration, but still no dice. Even more interesting, you can run a few grubby commands after logging in to "fix" the issue, but it defeats the purpose of not being able to see the cloud init messages on first boot. As an aside, if you would like to try out how we build our images, you could try this (it may require you to make some directories or install packages on your host system; we also use Fedora in this example): git clone https://git.resf.org/sig_core/toolkit.git -b devel cd toolkit/iso/empanadas podman build --build-arg BRANCH=r9 -t empanadas:r9 -f Containerfile.imagefactory podman run -it --rm -e LIBVIRT_DEFAULT_URI -v /var/run/libvirt/:/var/run/libvirt/ -v /var/lib/imagefactory/:/var/lib/imagefactory/:rw --network host --security-opt label=disable --privileged --device fuse empanadas:r9 build-image --version 9 --type GenericCloud --debug This will leave an image in /var/lib/imagefactory/storage with a .body name. It'll be in raw format. You can then use this against virt-install or otherwise. I'll keep trying to look into where the issue is in the meanwhile. We are open to any suggestions or help as well to try to resolve the console issue. |
|
|
After a bit of work we believe we have the issues resolved. We'll have images built through the week/weekend and pushed to our mirrors and we'll notify when this happens. Resolved in the following commits: Remove kernel parameters from icicle configuration: https://git.resf.org/sig_core/toolkit/commit/eeae7ff5ab73f27229bbc578aeeb3750619101b9 Fixes grub2-pc package naming and removes sed in %post: https://git.resf.org/sig_core/kickstarts/commit/0a16a1b5cf1b3fbfe6bc8b95fcf19b645fef0389 Works around cloud-init bug that should be backported in 9.1's cloud-init or fixed in 22.2: https://git.resf.org/sig_core/kickstarts/commit/ebf7a38c6b3f81512daaf0f4938148c1a576750b Adds virt-what to package list: https://git.resf.org/sig_core/kickstarts/commit/008bf056b923231c0f9100fabef54d2d407c4304 |
- Anonymous
