Almalinux 9.2 + PXE + Kickstart

Support
1

Does anybody have any instructions/how-to/working example of installing Almalinux 9.2 VIA PXE / kickstart?

We’ve always retained local mirrors of OS’s for installation purposes, and have a generalized PXE server/VLAN used specifically for OS installations, with various kickstart files to make life easier.

After receiving a request from a user to provide access to Almalinux 9.2 VIA our PXE setup, I took our working 8.4 PXE setup, followed the steps I normally would expect between OS revisions, but could not produce a working installer.

I used rsync to mirror the v9.2 x86_64 AppStream, and BaseOS directories to the local PXE host (10.10.10.10), and have this as the syntax for our iPXE system (derivative of the 8.4 installer, just different files/paths/etc.):

:almalinux92-64
echo Booting AlmaLinux v9.2 (64 bit)
kernel -n img almalinux92-64/BaseOS/x86_64/kickstart/images/pxeboot/vmlinuz ks=h[xx]p://10.10.10.10/kickstart/almalinux92-64
initrd almalinux92-64/BaseOS/x86_64/kickstart/images/pxeboot/initrd.img
boot img || goto failed
goto almalinuxstart

The KS file is pretty simple:

keyboard --vckeymap=us --xlayouts=‘us’
lang en_US.UTF-8
text
url --url=“h[xx]p://10.10.10.10/almalinux/almalinux92-64/”
repo --name=“AppStream” --baseurl=“h[xx]p://10.10.10.10/almalinux/almalinux92-64/AppStream/x86_64/os/”
timezone America/New_York --isUtc

Clearly some stuff has changed, but I can’t seem to find any documentation on the subject. Advice?

[Censoring links due to new user]

2

i’ve done plenty of kickstarts but i’ve only done pxe with debian preseed, the best place i find for that sort of reference is here:

for some reason these sections have been removed from newer versions of the docs. note that various kickstart options have changed between 8.4 and 9.2, and UEFI complicates matters, so it may be easier to get your kickstart working first (maybe even from cdrom iso not mirror url?) then fiddle with pxe.

my kickstarts generally start with something like:

url --url https://repo.almalinux.org/almalinux/9/BaseOS/x86_64/kickstart/
text
skipx
firstboot --disable
eula --agreed
reboot
keyboard --vckeymap=gb --xlayouts='gb'
lang en_GB.UTF-8
timezone Europe/London --utc
timesource --ntp-server uk.pool.ntp.org
network --bootproto=dhcp --device=eth0 --noipv6 --activate
3

Yeah, as you might notice the KS isn’t actually doing anything really, but I’ll see if I can’t set aside a server to just brute-force the PXE portion.

If memory serves me correctly, our kickstart was forced from optional to necessary on the PXE server around when originally moving from CentOS 7 > CentOS 8, because you had to specify the AppStream repo or the installer would bail (whereas previous versions only needed the network boot vmlinuz and initrd, and they’d prompt for the rest during text mode).

Half the issue here is the fact every reboot takes ~3-4 minutes from start to finish, so the process of trial and error is agonizingly slow (Supermicro POST times are not winners here).

If I can get PXE working for Almalinux 9.2 (like it does for 8.4 and everything before it), then the kickstart won’t be at all hard to figure out.

4

the info here looks pretty familiar, i recall you need the default, pxelinux.0, initrd.img and vmlinuz files.

i think requiring appstream was an el8 issue, i know i’ve done alma9 installs from just baseos.

and if you think 3-4mins reboot is bad, never use any AWS baremetal servers, they take 10x that.

5

Ok, so digging through @sej7278 's link a little, and digging through CentOS Stream 9 : PXE Boot : Network Installation : Server World , I give the various permutations of the basic PXE/netinst boot a whirl, removing the kickstart entirely.

I can’t get the syntax on the above URL working, closest dumbed down options that got me the furthest were:

:almalinux92-64
kernel -n img almalinux92-64/BaseOS/x86_64/os/isolinux/vmlinuz
initrd almalinux92-64/BaseOS/x86_64/os/isolinux/initrd.img
boot img || goto failed

Notably trying to cram inst.repo into either the kernel or initrd lines results in a kernel panic < 1 second in. Trying to use the “append” syntax mentioned in the article immediately bails to the failed directive after loading vmlinuz (before loading initrd), and omitting the “-n” before “img” also results in an instant bail.

With the “as far as I got” settings, the installer gets stuck on “cancel waiting for multipath siblings of sd”, and eventually bails to a dracut timeout after 2 minutes (see attached image)

alma9 wiating for multipath siblings
alma9 wiating for multipath siblings1156×880 46.7 KB

I notice that the 8.4 PXE install does scroll by the same “cancel waiting for multipath siblings of sd” message, but it’s not terminal (IE: it pauses for < 3 seconds, then continues after displaying that, once for each HDD).

Suggestions? I can’t find anything about what this “cancel waiting for multipath siblings” is? These are regular SATA connected drives, nothing exotic.

6

Hrm, progress is being made, just had a break-through trying various combinations. I think I’ve got this and will post results once I’ve finessed out the solution. Looks like a bunch of options have changed, but without clear docs as to how/where/why.

1 Like
7

i’d appreciate a documented solution when you manage it, although last time i messed with PXE i burnt out my ISP’s router (think i permanently filled its DHCP pool!) so probably shouldn’t try again :grinning:

the multipath message is a red-herring, you quite often see that when things go wrong, i think its just where the regular logging finishes and anaconda begins.

anaconda/kickstart is legendarily poor at error handling/logging.

8

Ok, so after re-mirroring the 9.2 repo (I had tried to take a “light” copy, and … well I guess missed some stuff that was vital), I’m now 300G shorter on our PXE server, but the boot works.

Our PXE server pushes the initial bits over ipxe/TFTP, and then uses http once it hits the next stage. The ipxe config that works:

:almalinux92-64
echo Booting AlmaLinux v9.2 (64 bit)
kernel -n img almalinux92-64/BaseOS/x86_64/os/isolinux/vmlinuz append inst.text inst.ks=h[xx]p://10.10.10.10/kickstart/almalinux92-64 inst.repo=h[xx]p://10.10.10.10/almalinux/almalinux92-64/BaseOS/x86_64/os inst.addrepo=AppStream,h[xx]p://10.10.10.10/almalinux/almalinux92-64/AppStream/x86_64/os/
initrd almalinux92-64/BaseOS/x86_64/os/isolinux/initrd.img
boot img || goto failed
goto almalinuxstart

Then the most basic kickstart, just covering a few basics:

keyboard --vckeymap=us --xlayouts=‘us’
lang en_US.UTF-8

%packages
@^minimal-environment
%end

skipx
timezone America/New_York --utc

The most notable (from previous versions of alma/centos) is that the PXE syntax now only accepts repo’s with the word “inst.” in front of 'em, and that the “append” syntax only works if it’s on the same line as the kernel statement (unlike the examples), note the kernel line is one big run-on sentence (getting line-wrapped by the post).

“inst.text” spits out a message implying that it got missed ("if you have trouble with graphical install, use inst.text next time), but it spits out that message, after … well booting into text mode, so thanks for that Alma…

Anyway, hopefully this is useful, and google archives this, as I’ve run a few permutations of the kickstart through this (doing normal, but progressively more complex/lengthier configs), with 100% success rate.

Note this kickstart file will not complete the install (it just pre-fills some of the menu options), if you want fully automated, you’ll want to get more detailed (IE: partitioning, SW RAID, adding users/root pw/etc.).

1 Like
9

not alma-specific, but yeah its pretty odd isn’t it, makes me laugh every time. what’s weird is there’s even a comment in the source saying to not do exactly what it is doing!

i use reposync instead of rsync as then you can just mirror the latest patches, not every version ever and only for the arch you use, so my stats are:

6.7G	alma92-appstream
1.2G	alma92-baseos
6.7G	alma92-crb
3.5G	alma92-devel
564K	alma92-extras

i just create a disabled /etc/yum.repos.d/alma92.repo (actually the server doing the mirroring is running rhel 8.8) like so:

[alma92-baseos]
name=AlmaLinux 9.2 - BaseOS
baseurl=https://repo.almalinux.org/almalinux/9.2/BaseOS/x86_64/os/
enabled=0
gpgcheck=1
gpgkey=https://repo.almalinux.org/almalinux/9.2/BaseOS/x86_64/os/RPM-GPG-KEY-AlmaLinux-9
enabled_metadata=0

then to mirror it run this every once in a while:

reposync --delete -n -p /mnt/mirrors/ --download-metadata \
    --downloadcomps --repo=alma92-baseos

it does mean you need an rpm-based distro to do the mirroring though.

10

Not a bad idea, I didn’t even consider that.

I remember the original mirroring of Debian and Ubuntu used their repo program, that only ran on their platform. Made so little sense to me, as though people were deploying PXE servers that would only ever serve a single platform seemed ridiculously narrow.

For now, it’s done, it’s got everything it could ever want for 9.2 and more… Honestly it might just be less work throwing drive space at it down the road, so I don’t run into odd catch-22’s (IE: people trying to install on other architectures and failing down the road, etc.).

1 Like
11

Mine :wink:
PS: My original ks include partition stuff, ipv6 disable and other things that i think is not relevant here:

#al9.ks
text
skipx
reboot --eject
eula --agreed
selinux --disabled
firewall --disabled
firstboot --disabled
lang en_US.UTF-8
keyboard br-abnt2
timezone America/Sao_Paulo --isUtc --ntpservers=ntp.example.com
services --enable=“chronyd”
url --url=http://almalinux.example.com/9/BaseOS/x86_64/os
repo --name=“AppStream” --baseurl=http://almalinux.example.com/9/AppStream/x86_64/os

In RHEL9, you should invoke the kickstart by using “inst.ks=” instead of “ks=”

12

PXE has multiple participants:

  • DHCP that offers “next server” for the booting machine. Legacy and UEFI mode clients can get different config from it. I’ve lately used dnsmasq as the DHCP server
  • The next server is the TFTP server that has bootloader (syslinux for legacy, grub for UEFI), config for it, kernel, and initramfs. I’ve lately used dnsmasq as the TFTP server (for convenience)
  • The config may include inst.ks=URL and the kickstart is naturally loaded from whatever the URL points to
  • Either the (installer) initramfs, the interactive user, or the kickstart file supplies the URLs for repos

I have not succeeded in giving NFSv4 URL for the installer; HTTP and FTP do work.

PXE can use tagged VLAN. It did fail to pass the tag to GRUB, so while PXE gets correct config and can load GRUB, the GRUB lacks network connection to load the kernel from same TFTP server. I have not tried recently though.

13

since this line is deprecated (but still works):
“timezone America/Sao_Paulo --isUtc --ntpservers=ntp.example.com”
You can replace with this:
timezone America/Sao_Paulo --utc
timesource --ntp-servers ntp.example.com