Trying to Install alma 10 on an Celeron N3150, But as soon as I select the installation option, it reboots.
AlmaLinux 10 requires CPU instructions known as “x86_64_v3 microarchitecture”.
Celeron N3150 does not have all those instructions. It does support x86_64_v2.
AlmaLinux 9 requires x86_64_v2, so your CPU can run AlmaLinux 9.
There is also AlmaLinux 10 v2 that is built to require only x86_64_v2. Your CPU could run that too. However, all third-party packages would also have to build for x86_64_v2 – packages built for el10 distros do require x86_64_v3 because the el10 distros do require x86_64_v3. (AlmaLinux does rebuild EPEL for 10 v2.)
I’ve been through this exact process.
I have an old laptop I’m using as a router and got caught when I upgraded to Alma 10.
I was able to find the alma 10_v2 option but it was pretty earlier in the cycle so there was some difficulty obtaining some of the packages I needed. The EPEL for v2 is MUCH better now, THANKS!
What I was able to do before the updates happened was use packages from an earlier release. I just added the repo for alma 9 or EPEL9 or wherever the repo the package was housed ( I can’t remember exactly… it’s been a few seconds
). That was an effective stop gap until everything got up to speed.
YMMV, but for what I needed, this worked.
Just parking this here for future updates ![]()
That may or may not succeed, depending on package. RPM packages have both implicit and explicit dependencies.
The explicit ones are “requires feature/package” rules that package manager follows. If no package for new distro provides what is required, then DNF refuses to install the “third-party” package.
The implicit requirements could be use of other program or library that is not stated as requirement in the RPM metadata. Package installs, but program fails to run properly.
The less a package/program depends on others, the better the chance it can install/run on “other distros”.
Some of those issues may be resolved by taking src.rpm (rather than “binary” rpm) and rebuilding the binary rpm on the target platform. There is rpmbuild tool, but the mock (from EPEL) makes a bit “cleaner” rebuild.
Even the rebuild process can be a rabbit’s hole when your package requires other packages to be rebuilt too. Likewise, a fundamental change in system – e.g. version of openssl in el9 compared to el8 – may need big changes to the source code (aka porting software to new platform).
This is because your CPU is not a v3 or higher, and the default AlmaLinux 9 and 10 for “x86-64” target and ISO are build for v3 CPU or higher.
Running this ISO on a v2 CPU will generate the exact same issue that you have.
Hence you need to download the ISO file for the “x86-64_v2” target and try to install again.
Go to the almalinux.org site and select “Download”, and then click on “Almalinux 10” drop-down menu. You will see several targets. Select “x86-64 v2”, and the page will reload with this target ISOs. Unfortunately, the target title is not shown at the top of the page, but you really get the “x86-64_v2” target by doing this.
Then, click on the ISO bundle you want (DVD, boot, minimal) and verify that the “x86-64_v2” text is present in the downloaded file name, else you did download the “x86-64” version.
Burn it and try to install AlmaLinux with this version and it should work.
To know if your Intel CPU has a v2 or a v3 version, boot from a Live DVD, and type this command:
cat /proc/cpuinfo
If you do not see the “avx” keyword, then your CPU is not a v3, and hence probably a v2. There are some scripts to provide you with the exact version of your CPU that you can download and run on your Live DVD.
To summarize: If you have a v2 CPU, you need to download the “X86-64_v2” target ISO, else you will not be able to install AlmaLinux 9 or 10 on your system.
Warning:
With the “x86-64_v2” ISO, you will not be able to get all packages of some third-parties repositories, like elrepo for example.
Typically, some “kmod-*” kernel modules rpm packages are hence not available for now.
However, you can follow other threads to see how to build your own kernel modules using the kernel SRPM way to do it.
With the “x86-64_v2” target, you can easily enable those repositories at least, covering most of your needs (and their devel and sources repos for each):
AppStream, BaseOS, CRB, Epel, Extras, HighAvailability, NFV, RT, SAP, SAPHANA