Trying to install Alma 10, but installation fails

Support
1

Trying to Install alma 10 on an Celeron N3150, But as soon as I select the installation option, it reboots.

2

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.)

1 Like
3

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 :slight_smile: ). 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 :slight_smile:

4

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).