AlmaLinux 10 kickstart problem

I have a problem installing AlmaLinux 10 using kickstart on KVM with virt-install.
I have been able to reduce the problem to this minimum installation setup:

I have a kickstart file like this:

%packages
@^minimal-environment
@guest-agents
@headless-management
@network-server
@security-tools
@system-tools
kexec-tools
%end
# Keyboard layouts
keyboard --vckeymap='dk' --xlayouts='dk'
# System language
lang en_DK.UTF-8
# Network information
network  --bootproto=dhcp --device=link --activate
network  --hostname=test
# Use CDROM installation media
cdrom
# Run the Setup Agent on first boot
firstboot --disable
ignoredisk --only-use=sda
# Partition clearing information
clearpart --all --initlabel
autopart --type=lvm --nohome
# System bootloader configuration
bootloader --append="crashkernel=auto" --location=mbr --boot-drive=sda
# System timezone
timezone Europe/Copenhagen
#Root password
rootpw --lock
group --gid=2000 --name=admin
user --groups=wheel,admin --uid=2000 --name=test --password=$6$qGCuOaecMHOtoou3$WG4Q7dmduUMKmwQaaUJOjJgTamkAQAvR7cd9Sob4BfOKC.r6gBBoY8XovmzImX.3qW9nWuutmazlEF7Nqwsfm.
shutdown --eject
%addon com_redhat_kdump --enable --reserve-mb='auto'
%end

and this is the command line used to install it with virt-install:

    virt-install --name test \
        --vcpus 2 \
        --osinfo detect=on,require=off \
        --memory memory=3072 \
        --cpu host-passthrough \
        --location <path-to-iso-file>,kernel=<path-inside-iso-to-vmlinuz>,initrd=<path-inside-iso-to-initrd> \
        --boot uefi,hd,cdrom,bootmenu.enable=on,bios.useserial=yes,firmware.feature0.name=secure-boot,firmware.feature0.enabled=no \
        --video virtio \
        --channel spicevmc,target.type=virtio \
        --console pty,target.type=virtio \
        --serial pty \
        --disk size=12,bus=scsi,sparse=yes,format=qcow2,pool=default \
        --disk <path-to-iso-file>,device=cdrom,bus=scsi,readonly=on \
        --controller=type=scsi,model=virtio-scsi,driver.iommu=off \
        --network network=${net_name},model=virtio \
        --initrd-inject=/tmp/ks.cfg \
        --extra-args "inst.debug inst.wait_for_disks=3 inst.ksstrict inst.repo=hd:LABEL=<label-of-iso-file> inst.stage2=hd:LABEL=<label-of-iso-file> inst.ks=file:/ks.cfg console=tty console=ttyS0,115200n8" \
        --autoconsole text \
        --noreboot

This oneliner works perfectly for Alma 9 but for Alma 10 it leads to an infinite loop before finalizing the storage configuration.
I would ask help to debug the changed behavior. I have no clue on how to debug the basic part of the anaconda installation process.

have you tried adding zerombr, i seem to recall it would sit there waiting for input if you used clearpart --all without it.

i’d try getting rid of some of those packages too - in case the groups have changed.

i found my 9 kickstarts worked without change for 10.

Thank you for the suggestion, though sadly adding zerombr into the kickstart does not change the behavior. The installer reaches the point of configuring the disk layout (the autopart statement), but never seems to finalize this action. It continues writing out “…” but never finishes creating partitions or filesystems. It leaves the vm image in pristine order.

What if you leave out the storage config from ks and supply them interactively. Will that get through? If it does, then how will the ks written by that install differ?

This works for me:

maybe too many extra args or you’re over-complicating the disk/kernel setup?

Is there an option to load the kickstart but use the text installation method if not all needed values are supplied? I haven’t been able to start up Alma 10 with a kickstart and still get prompted for filling in the blanks. I have been able to install alma using a serial console interactively, where is does create partitions on the supplied virtual scsi disk, and the settings do look quite similar (another problem: the installer apparently is unable to find the supplied repos on the virtual cdrom, when doing it interactively and the cdrom being a scsi device).
When supplying a kickstart:

# Generated by Anaconda 40.22.3.26
# Generated by pykickstart v3.52.8
#version=RHEL10
# Use text mode install
text

%addon com_redhat_kdump --enable --reserve-mb='auto'

%end

# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
# System language
lang en_DK.UTF-8

%packages
@^minimal-environment
@headless-management
@network-server
@security-tools
@system-tools

%end

# Run the Setup Agent on first boot
firstboot --enable
# Do not configure the X Window System
skipx

# Generated using Blivet version 3.10.0
ignoredisk --only-use=sda
# System bootloader configuration
bootloader --append="crashkernel=2G-64G:256M,64G-:512M" --location=mbr --boot-drive=sda
autopart
# Partition clearing information
clearpart --linux --initlabel --drives=sda

# System timezone
timezone Europe/Copenhagen --utc

#Root password
rootpw --lock
user --groups=wheel --name=devine --password=$y$j9T$gogJ5tKfVsVqWsbs/qNHQQ8i$U9.65W59H0NKzfxXIIc9fks1FdLGIZ/KSy/yt0Bc4k5 --iscrypted --gecos="devine"

So no big difference from my custom ks file.

True I am pushing the envelope a bit, however I am in an air-gapped environment, there is no way I can get packages over public network. My big problem is, I have to make the server install with the repo supplied on the ISO alone, nothing else.

sounds like a problem with your custom cdrom or libvirt script more than kickstart then

sounds like a problem with your custom cdrom or libvirt script more than kickstart then

Definitely and most likely true, but for all completeness I would like to figure out where I/libvirt goes to town and makes the mistake. It seems that Anaconda sits in an infinite loop waiting for some event to happen that never occurs. Is there any way to debug this?

Setting inst.ksstrict is your enemy - that sets all warnings to errors and just bails out. You can switch to a console or various logs by hitting alt-f2 (etc) if you undo that.

if its sitting their its probably not finding a storage device or something.

in case it is your custom iso, maybe try just installing @^minimal-environment from the regular dvd/minimal iso instead of all those other package groups, won’t need internet access for that.

why use a custom iso when you’re injecting the kickstart into the initrd anyway - in fact that could be your problem, you’ve got two kickstart sources.

it could be that its not finding the packages, i’ve done this a few times when i’m serving up the kickstart over http and need to tell it on which disk to find the packages:

harddrive --partition=LABEL=AlmaLinux-9-2-aarch64-dvd --dir=/
harddrive --partition=LABEL=AlmaLinux-9-5-aarch64-dvd --dir=/
harddrive --partition=LABEL=AlmaLinux-10-0-beta1-aarch64-dvd --dir=/

i’m not sure if i’ve ever done a custom boot cd that’s also got the packages on, i’d use an internal mirror for that otherwise the iso ends up massive.