Just wanted to say to the Devs, thanks for this Nice OS :)
See the following links for: Medication Guide & Safety Information
This is probably not a specific AlmaLinux problem, but some weirdness with Network Manager maybe?
I have a fresh install of AlmaLinux 10.1 on a PC with two NICs. First NIC is on my corporate network, works fine. Second NIC is a 'heartbeat' NIC directly wired to another AlmaLinux 10.1 PC. These two servers use clustering and have this second NIC to determine who is online and prevent split-brain.
Anyways, we have been doing this type of setup with AlmaLinux 8 previously, this is the first time we're using AlmaLinux 10. In version 8, we didn't have/use NetworkManager, we just edited interface configuration files. We have always used and as the IPs on the 'heartbeat' NICs. The .1 IP is 'node A', and the .2 IP is 'node B'. Works wonderfully on AlmaLinux 8.
However, on AlmaLinux 10, we are using 'nmcli' to set this up. I assign the 'IPv4.Address' to the IPs above, and I also disable IPV6 entirely. Node B uses with no issue. Node A reports an IP duplicate when I try to bring online , and brings the interface 'down'. The MAC address with the duplicate IP is one digit above the MAC address of the local interface (which is odd and makes me think it's some internal Network Manager thing).
I dug in a bit and found I can disable the duplicate IP sensing thing by setting the IPV4.dad-timout to value 0 (zero). This allows me to bring the interface online, but then it just doesn't work (can't exchange packets with on that NIC.
I change the configuration to use for node A, and for node B, and that works just fine.
I'll hit this today and do more testing, but this is weird!
Anybody have a clue what is going on here?
Not sure if anyone has come across anything like this before but I'm trying to set up an AlmaLinux VM on OracleCloud, and I'm running into an issue where all systemd generators fail to run, throwing mkdir: cannot create directory ‘/tmp/systemd-temporary-[random 6 char string]/generator.early/multi-user.target.wants’: Read-only file system
No idea why this is happening since it's a clean install, and the base /tmp directory is writable. I assume this is something to do with systemd's tmpfs management but why on earth is it defaulting to making these temp paths read only? And why is systemd insisting on using these paths instead of /run for generated units?
EDIT: OK so for some oddball reason the generator errors were only applying to systemd-verify, and the failure of the actual generation of units was some separate issue that seems to have gone away when I disabled the cloud-init service. systemd-verify still throws the same errors but the actual units work now at least.