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.
Ok I solved it - but I honestly doen’t know if this is by design, or if there is a hidden error masking the correct solution:
I tried to install a VM using the x86_64_v2 distribution (as I have older hardware). This fails unconditionally, unless I perform the installation on physical hardware in a live setup. Kickstart/anaconda fails to mount the cdrom image, as the compare between uname arch and the embedded arch description within the iso differ. The returned arch from uname is ALWAYS x86_64 whereas the embedded arch is x86_64_v2.
If I change the iso to use the newest release (x86_64 - not _v2) then the kickstart process installs without any problems. I am still not sure how the older x86_64_v2 can be used - unless of course it is only to be used on older legacy hardware.
FWIW I have a server with x86_64_v2 Intel cpus running AL9.6 and I had no problem creating a VM with kickstart and AL10 x86_64_v2 on that server. The difference with your kickstart is that I don’t use cdrom but have the following:
url --url=“https://<mirror>/almalinux/10/BaseOS/x86_64_v2/os/”
repo --name=BaseOS --baseurl=“https://<mirror>/almalinux/10/BaseOS/x86_64_v2/os/”
repo --name=AppStream --baseurl=“https://<mirror>/almalinux/10/AppStream/x86_64_v2/os/”
Thank you @Patrick42 , I do get the same behavior on legacy hardware. I am under constraints, as it is in an airgapped environment where my only installation media is the basic cdrom/dvd. And I need to create the vm’s in that airgapped environment. I was just wondering if there is any way I can make sure to either fail (hard) the installation if the architecture isn’t supported by the OS or installation media, instead of this silent endless loop waiting for the correct installation media to magically appear. I can install by hand with a console, but having to do this more than 20 times will be a difficult task to mainstream. Hence the urge to install with kickstart from a media under my control.
yes using url works for me with v2, not tried from a custom ISO.
i’d setup a local mirror - even if its just from the DVD ISO.
i guess you could tweak your custom iso to use the non-v2 name
isoinfo -d -i AlmaLinux-10.0-x86_64_v2-minimal.iso | grep 'Volume id:'
Volume id: AlmaLinux-10-0-x86_64_v2-dvd
isoinfo -d -i AlmaLinux-10.0-x86_64-dvd.iso | grep 'Volume id:'
Volume id: AlmaLinux-10-0-x86_64-dvd
it seems to only be referenced in EFI/BOOT/grub.cfg, isolinux/isolinux.cfg and images/efiboot.img