Error Setting Up Software Source

Support
1

I am trying to install AlmaLinux 8.4 from a local PXE server, but I am running into “Error setting up software source” right at the start of the installation every single time. There’s no other apparent issues.

The installation files were originally extracted from an AlmaLinux-8.4-x86_64-dvd.iso, but I’ve also tried installing with a copy of everything downloaded from Index of /almalinux/8.4/. The setup files are located on the local server at http://10.0.0.1/almalinux/8.4/* (tried configuring both from within a kickstart and directly on the setup screen). The files are being served over nginx; after Anaconda pauses on the error and I switch to a virtual terminal, I can verify the required files can be curled and pulled with wget from the system that I am trying to kick. Same thing happens trying to go through text-only setup, but not sure if that would make a difference anyways.

The odd part is this configuration is mirrored across two separate, but nearly-identical environments. One always succeeds and the other always fails. The failing network is more isolated from the outside world than the first, but all required files are hosted within their respective networks. I’ve verified most of the easy stuff like typing in the proper network locations, by comparing systems side by side as they are being kicked on these separate networks. This seems to me to point to either a mismatch of installation files or some configuration on the failing network that is preventing Anaconda from properly recognizing or pulling information from the software source. I’ve verified all of the installation files are identical. I am still working on verifying the vmlinuz and initrd.img files are the same, and I am digging through the Anaconda github (GitHub - rhinstaller/anaconda: System installer for Fedora, RHEL and other distributions) to try and track down what process it uses to verify an installation repo.

Any suggestions? Or has anyone run into similar situations before?

1 Like
2

Discovered that the installation proceeds if I don’t use a kickstart at all. The installation source is picked up right away, and of course have to manually set the rest of the installation options, but it’s successful without including any inst.ks= on the kick line.

Going to have to dig through the .ks file and see what’s causing the issue from there. There shouldn’t be anything that tries to change Anaconda itself. I understand an error even if the repo wasn’t configured properly to begin with, but I don’t understand why it would still fail after typing in the repo manually from Anaconda. I also don’t understand why the .ks file would work from one location but not another in terms of causing a repo to fail to be recognized. I’ll keep digging.

EDIT: I know kicking from a different location may change some thing, but I have considered those (still double-checking everything, though) These networks are very similarly setup. E.g. both are 10.0.0.1/16 networks, DNS entries resolve to like-named servers with kickstart data, etc.

3

Installer writes the effective kickstart options into /root/. I presume you check there the syntax of installation source?

4

Further troubleshooting of the .ks file points to an issue setting up the repos (surprise, surprise). The .ks file accepts a %kickstart_server variable from the kick line. Each site can pass in their own kickstart server, so the same kickstart can be used by multiple sites (as long as the person kicking a system knows their proper server).

Passing the url kickstart command and only that command with the proper server works! But including the repo kickstart command or trying to pass the repo command by itself causes the whole thing to fail.

Here’s briefly what it looks like:

Kick line:
../vmlinuz ../initrd.img inst.repo= inst.ks=/path/to/.ks kickstart_server=server01 hostname=computer01

Kickstart

text
lang en_US
keyboard us
zerombr
clearpart --all --initlabel
bootloader --location=mbr --append="biosdevname=0 pcie_aspm=off ipv6.disable=1"
selinux --disabled
firewall --disabled
reboot

%include /tmp/repos

Further down kickstart:

cat > /tmp/repos << EOF
url --url http://%kickstart_server/almalinux/8.4/BaseOS/x86_64/os
repo --name=Other-Repo --baseurl=http://%kickstart_server/other-repo
EOF
5

Yes, I have, and nothing seems to stick out at me.

6

Found and fixed the problem.

The issue was with that secondary repo location after being copied from the primary source. The rsync command for copying that Other-Repo over was missing a trailing / so it created a duplicate directory. The .ks file couldn’t find the repo so it halted the installation.

http://kickstart_server/repos/Other-Repo/<repodata>
vs
http://kickstart_server/repos/Other-Repo/Other-Repo/<repodata>

I’m not sure if there’s a specific reason for this behavior or if it’s a bug. I feel like an issue locating a secondary repo shouldn’t cause issues verifying or utilizing the primary installation source, especially after manually entering/verifying after Anaconda encounters the issue and pauses.