I am new to AlmaLinux, but not RHEL-variants in general. I have worked with CentOS 8, but I am trying out AlmaLinux to see if it will be good for my organization to use.
Unfortunately, I have found an issue during the installation process of Software Selections. Once I have made Software Selections such as RPM Development Tools, after trying the Base Environments of:
Server with GUI, or
Workstation, or
Virtualization Host
I return back to the primary screen - Installation Summary, and find the problem of “Error checking software selection.”
I do not remember ever seeing this problem with CentOS 8 installations, not to say it did not exist I just do not remember it.
Has anyone else seen this? Is this merely an aesthetic (misleading) error or is it real?
Warron, I know you’ve been around CentOS for ages, so I’ll just mention that I had a few issues getting the repository recognised at first. I was doing a network installation and so it couldn’t continue at all until I’d sorted it out. If you’re installing from the standard image such problems might arise when it checked the selections. Just a thought.
I’ve just had a look at the entry in yum.repos.d and it is:
baseurl=https://repo.almalinux.org/almalinux/$releasever/BaseOS/$basearch/os/
so I’d interpret that as: https://repo.almalinux.org/almalinux/8/BaseOS/x86_64/os
Watch the capitisation!
@MartinR, are you saying to strictly adhere to the capitilzation of the url you provided?
Also, how do I use this url when I am building a machine and having problems accessing the packages in the url? I know that I am missing something, perhaps it is subtle.
That’s exactly right. “baseos” doesn’t seem to work whereas “BaseOS” does. DAMHIK!
I was referring to the installation summary from whence you set up networking, package selection, disk partitioning etc. One of the sub-screens gives you the option to specify the repo, and AIUI it is from there that the metadata is drawn. I don’t have a spare machine to build on ATM, so this was only mean as something to check, not a guaranteed solution.
So I attempted to use the url, not necessarily in the correct place, but that made no difference. I totally change my software selection so that I was not explicitly installing Gnome Desktop, not even by defaults (no actions on my part). Once I chose software that would not conflict with the DISA Stig security checks at all, the issue went away entirely.
Why do we have the DISA STIG 8 preventing the installation of the OS for nfs-utils conflicts?
The second problem, which compounded on the nfs-utils and masked the issue, was running into with choosing any software that require Gnome installation because of Boxes (libvirt* packages).
Once I avoided nfs-utils and libvirt* packages entirely I could click on the [Installation] button finally.
@ewilliamknowlton, be weary of the latest kernel update as it has a conflict with the kernel option “fips=1”.
The kernel 4.18.0-240.22.1 specifically is the kernel that has a conflict with fips=1 being set.
If you alter the parameter from fips=1 to fips=0 and boot, the machine will boot.
If you boot off of the older kernel-4.18.0-240 with fips=1 set there still is no problem booting and logging into the gui.
I got the alma iso from the download section then used BalenaEtcher to create a distribution USB key. I don’t use rufus as I have found problems with it on CentOS 8.* where it corrupts data. This does not occur on CentOS 7.*. I booted the USB key then built a Server+GUI with no problems.
Hi Warron, yes, I did a yum update and reboot. This made no difference. I tried 3 different sized Kingston USB keys and the result was the same. The Rufus generated key failed each time and the BalenaEtcher key worked each time.
OK, interesting. Our experiences are different for some reason. I installed into a VM, not a physical machine, which by your details including the USB key lead me to believe you built on a physical machine.
The problem I had with respect to the GUI DE after installing “Server with GUI” might be specific to the kernel + Oracle vBox. Not sure though.
