Anaconda for AlmaLinux 9.2 hangs sometimes with a kickstart NFS install #178
Comments
|
I managed to get Anaconda logs as described in https://fedoraproject.org/wiki/Anaconda/Logging. Logs attached below: what seems to happen is that NetworkManager seems to want to activate enp1s0 and to do so, it deactivates it first! Full logs |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a process for building KVM VMs that uses Ansible to set up (a) a DHCP entry, (b) a tailored PXE config and AlmaLinux image, (c) a Kickstart config file pointing to an NFS share with the AlmaLinux 9.2 image and then boots the server to do the install.
This is completely reliable with Centos Stream 9. With AlmaLinux 9.2, roughly 50% of the time, it hangs during the Anaconda install shortly after the
* when reporting a bugmessage and about 16 seconds after the NFS transfer starts. Two minutes later the NFS server closes the TCP session on port 2049 (6 FIN/ACK attempts with no response). I can send Ctrl-Alt-F4 etc to the VM and it will show me the logs but otherwise it's unresponsive. I'm not aware of a way to get the logs off the virtual /dev/tty4 except by watching them in virt-viewer but what that tells me is that Anaconda is deactivating the enp1s0 interface (which would definitely stop NFS). I have no idea why it's doing this.The other 50% of the time it installs normally. The DHCP, TFTP and NFS servers are all the same 192.168.1.3 and that is a VM in the same subnet, running on the same host connected to the same Linux bridge (br1).
From the
/var/lib/tftpboot/pxelinux.cfg/C0A8017F
/srv/shares/kickstart/agrajag.ks
Final screen from /dev/tty4 as processed (mangled) by tesseract and manually corrected as far as I can:
Original screenshot:
The text was updated successfully, but these errors were encountered: