Kickstart configuration of static ipv4 address

Support
1

I’m performing an automatic installation of Alma9.2 with a custom kickstart file. I want to assign a static IP address, so I add a line:

network  --bootproto=static --device=enp3s0 --gateway=192.168.137.1 --ip=192.168.137.2 --netmask=255.255.255.0 --ipv6=off --no-activate

I would expect that a configuration file should be added in /etc/NetworkManager/system-connections/ - but it doesn’t create anything for this device.

We used to use CentOS7.x, and there this would create the corresponding ifcfg--files in /etc/sysconfig/network-scripts/ - but I understand that this has been deprecated in favour of /etc/NetworkManager/system-connections/.

Any ideas what I’m doing wrong?

(From what I’ve understood, the --no-activate only means that it’s not active during the installation, but it should be created for future boots. That’s how it worked with CentOS7.x.)

2

What about

–activate

3

Probably not liking --ipv6=off, it should be --noipv6 :

--no-activate means the network won’t be available during install, but will be afterwards.

Kickstart has changed massively between 7 and 9, so have a poke around my repo.

1 Like
4

Thanks for the reply!

I’m testing that now. It takes a while to generate the image, and boot on it…
(And at first I got it wrong, and set --no-ipv6 - which it didn’t like at all…)

On an almost related topic - (it’s on the next line…) Will network --hostname=almatest set the hostname in /etc/hostname? If so, it’s a whole lot neater than the recommended solution of:

%post --nochroot --log=/root/nochroot-post-install-logs.txt
 # Set Hostname
 hostnamectl set-hostname almatest
 hostnamectl set-hostname --pretty AlmaTest
 cp /etc/hostname /mnt/sysimage/etc/hostname
 cp /etc/machine-info /mnt/sysimage/etc/machine-info
 %end

(And why doesn’t that one work in a %post --chroot section? )

5

It finally passed through the automagic generation…

But - no — even with --noipv6 it still doesn’t generate the connection in /etc/NetworkManager/system-connections/.

(I tested both --noipv6 and --ipv6=off - and both pass ksvalidator with flying colors.)

6

ksvalidator isn’t great, we’ve discussed it before on here. it won’t find outright errors that will break anaconda for example.

network --hostname=almatest will set it in /etc/hostname and /etc/NetworkManager/system-connections/enp1s0.nmconnection should be created.

some stuff doesn’t work in %post --chroot due to dbus not being available, hostnamectl is probably one of them.

7

Hmmm. The /root/anaconda-ks.cfg file contains the lines:

grep network anaconda-ks.cfg 
network  --bootproto=static --device=enp3s0 --gateway=192.168.137.1 --ip=192.168.137.2 --nameserver=192.168.137.1 --netmask=255.255.255.0 --noipv6 --no-activate
network  --bootproto=static --device=enp1s0f0--ip=10.40.8.10 --gateway=10.0.0.1 --nameserver=10.0.1.1 --netmask=255.0.0.0 --noipv6 --no-activate

But the only file in /etc/NetworkManager/system-connections/ is ens3.nmconnection- which I don’t quite understand how it’s generated. And it contains:

cat /etc/NetworkManager/system-connections/ens3.nmconnection 
[connection]
id=ens3
uuid=5e497598-abe2-4ecc-a5f2-c31f3d016454
type=ethernet
autoconnect=false
interface-name=ens3

[ethernet]

[ipv4]
method=auto

[ipv6]
addr-gen-mode=eui64
method=auto

[proxy]

(It’s true that we’re doing some weird things. I boot this in a qemu vm, generating a filesystem that will later be used in an semi-embedded appliance. I don’t exclude that this has an impact. But for CentOS7.x it worked like a charm.)

8

network interface mismatch i’d say, your kickstart is probably using nic names that don’t exist - the ens3 is the real nic name not enp3s0, and its only found one card i guess (and used dhcp?)

although for a qemu vm that looks odd, they’re usually enp1s0 for virtio-nic, oh i guess you’re using e1000

you can put the --hostname on the same network line btw, not sure why i split it over two lines.

oh you’ve missed a space here, that’s why its not configured the 2nd nic i guess:

--device=enp1s0f0--ip=10.40.8.10

again, things that work on centos7 will be very different on alma9, kickstart and networking have moved on a lot in a two major version jump

9

Yes, that sounds reasonable. As the kickstart installation is done in a VM with different interfaces compared to the real quasi-embedded target system, there will be mismatches between emulated and real hardware.

Well spotted! Thanks!

Yup. I think we’ll have to re-think some of the logistics choices that were made in the past.
Right now I’m contemplating generating the system-connections files separately, and simply copy them into the image.

Thanks for the help!

10

Having read through the thread I’m not entirely clear on whether the initial issue is solved or not. But here’s a example from a kickstart file for AlmaLinux 9 that definitely works for doing static ipv4 address anyway:

network --activate --device=eth0 --onboot yes --bootproto=static --noipv6 --ip=10.70.13.124 --netmask=255.255.255.0 --gateway=10.70.13.254 --nameserver=8.8.8.8,8.8.4.4 --hostname=foo.bar.baz.ac.uk
11

No - the initial issue is not resolved - but I think that I will have to re-think the strategy a bit. We were using kickstart inside a VM that’s subtly different from the actual target system. For example - we don’t have the same interfaces as we do for the real target system, which presumably explains why the /etc/NetworkManager/system-connections/ files weren’t created.

I think that I’ll simply create the files directly instead. The syntax looks pretty straight-forward.