Unable to boot Centos Stream 9 installer on 2008 Apple Xserve

[TrevorH]

I'm guessing this is the bit you missed https://www.redhat.com/en/about/press-r ... oin-forces

And then the reverse is on https://blog.centos.org/2020/12/future- ... os-stream/

[AppleGuy14]

Ah, that makes sense. Thank you for linking those. It just seems ironic that CentOS completely switched sides. Oh well, the beauty of open source is that things such as Rocky and Alma Linux come around.

[AppleGuy14]

So Rocky Linux 9.1 did not work either, same issue. I also tried those two arguments in addition to nomodeset. I can try Rocky 8, but at this point it seems futile. What do you think? I can experiment a little bit more with arguments and booting procedures, but it does feel like I have exhausted the possibilities.

[TrevorH]

Can you remember what version your original install was and do you have the iso from those days still around (they will probably still be available from vault.centos.org if you need to get it again). If that works then we shall at least know how you got it installed. And if it doesn't work then you are right and there is some magic incantation you need to perform to make it do so. One that you found back then and have now forgotten.

[AppleGuy14]

I'm afraid I do not have the ISO anymore, but I know roughly when it was from. The CentOS 7 mirrors provide two ISOs, one from November 2020 and one from late July 2022. I got my first installation working in early July of 2022, so I either used a prior subversion or the original "2009" DVD image. I will get it downloading, but I am about to be away from the server for dinner.

[jlehtone]

So Rocky Linux 9.1 did not work either, same issue. I also tried those two arguments in addition to nomodeset. I can try Rocky 8, but at this point it seems futile. What do you think? I can experiment a little bit more with arguments and booting procedures, but it does feel like I have exhausted the possibilities.

The el9 kernel is built to use CPU instructions that are present on "x86-64-v2 microarchitecture level". (See table in https://en.wikipedia.org/wiki/X86-64 and https://developers.redhat.com/blog/2021 ... ture-level )
The Xeon E54xx series does not have all those instructions. Hence the el9 kernel can't run.

The el8 kernel does not have such requirement. Rocky 8 should run.

Ah, that makes sense. Thank you for linking those. It just seems ironic that CentOS completely switched sides.

CentOS Linux had limited benefits to Red Hat. CentOS Stream is their way to make development of RHEL a bit more "open".
Carl has some diagrams in https://twitter.com/carlwgeorge/status/ ... zpW9A&s=19
(I've seen a better blog on that, but can't recall where. EDIT: Found it: http://crunchtools.com/the-state-of-ent ... x-in-2022/ )

[AppleGuy14]

So the Rocky Linux 8 booted right up with the flags added, "video=efifb" and "noefi". have yet to install it because of my schedule, but I envision it will work since CentOS 7 did just fine once the installer booted. Thank you both for the suggestions.

Unfortunately, referencing my original post where I mentioned GLIBC versions, the version present in el8 is still too low for some of what I would like to run. One example of this is https://github.com/ryandesign/xserve-fr ... tree/linux, allowing the CPU lights on the server to work again. It requires GLIBC 2.34, while el8 only includes up to 2.28. Is there any possibility of upgrading that, or is that just something considered impossible to do? Since el9 is dead to me due to my CPU architecture, I am wondering if it may just be time to find some newer hardware...

Thank you both for the help getting the installer to work though. I cannot express how much relief I felt when it finally went past the black screen. I realize this was such a specific use case, so thank you for dealing with the oddity of the problem.

[jlehtone]

It requires GLIBC 2.34, while el8 only includes up to 2.28. Is there any possibility of upgrading that, or is that just something considered impossible to do?

Packages of the distro are built together so that they are binary compatible with each other.
One might be able to replace some packages that "nobody" depends on. For example, there are multiple (mutually exclusive) "streams" of PHP for el8; one can switch to different PHP.

The glibc is something that everybody depends on. Quite "impossible".

Red Hat does backport both security fixes and features to the branch of glibc that el8 has. Therefore, 2.28.el8 can differ from upstream 2.28, just like the kernel-3.10.0-*.el7 (of RHEL 7) is way different from the 3.10 that kernel developers had a decade ago.


By "requires GLIBC 2.34" you probably mean that the program cannot compile, because it has API calls that the glibc of el8 does not provide.
(Some have executables -- without sources -- that have been built against newer libs and hence runtime linker fails.)


One option is containers, although I don't know whether one can access "CPU lights" via glibc that is in a container.

[AppleGuy14]

Packages of the distro are built together so that they are binary compatible with each other.
One might be able to replace some packages that "nobody" depends on. For example, there are multiple (mutually exclusive) "streams" of PHP for el8; one can switch to different PHP.

The glibc is something that everybody depends on. Quite "impossible".

Ah, I see. I didn't think it was possible from the research I had done a while back, but I wanted to make sure. I will look into containers but you're right, it may or may not work.

Thank you both for all of the help along the way. I am writing down the solution in case I need it again, and hopefully it can be of use to someone else too one day.