Can't install 64b version on Dual Xeon setup

[bmx34]

Please add code tags to the terminal output in the first post

Apologies for that. That's fixed.

might try checking if there's a newer bios version

Indeed; I have found a "more recent" BIOS, from 2007 (previous was dated 2005). Flashed it via FreeDOS, but no improvement.

but may be video card be something to investigate at ?

Done that, I tried with something more recent (GTX750), but still no difference.

[CwF]

Back to the blinking cursor, that is maybe a failed VT7. Try switching Ctrl+Alt+F1 or F2. You tried that right?

[bmx34]

Yes, I did

[p.H]

Back to the blinking cursor, that is maybe a failed VT7.

There is no tty7 in the installer. Do you mean GUI (tty5) ?
Besides, if it was A GUI issue, the boot in expert mode should display a lot of text before.

[Deb-fan]

Really seems time to just accept your hardware limits that system to use of 32bit software. Shuffling components around, things like hdd's-etc is clearly not going to accomplish anything, it's just needless hassle and risk. Something gets damaged, incorrectly reinstalled or static discharge zaps something you'd prefer remains unzapped. All this time, effort and x-risk for zero real gain. Nothing you or anyone else can do is going to get around hardware limitations. Minecraft isnt the only thing in the world and thanks to Debian gnu/Linux that system can go on being a useful piece of equipment for a long time to come. Amazing in/of itself, a 15yr old PC can still be made to run well in 2020.

Ps, also doubt you're the only person ever, who wanted to use Minecraft servers on 32b, if you're going to dump more time into this would start googling on that angle see if somebody has already posted work-arounds online. Ah either way, good luck. You dang sure get A for effort.

[axon3]

issue looks to be low level. Would compiling your own kernel on your config help ?

[bmx34]

You dang sure get A for effort.

Thanks

Kernel compilation definitly looks a good idea, and I'll try that if nothing else works. But before, I wanted to test very old images, and here is a nice surprise, I have found debian-live-500-amd64-standard working fine !

Now I will try to find the latest image that works / the first that fails, and will surely let you know. I think it will help understanding what's wrong (could it be that past a certain point, kernel is built with SSE4, or any other extention that my CPU does not have ?)

[Head_on_a_Stick]

debian-live-500-amd64-standard working fine !

Perhaps a kernel regression then. See https://wiki.debian.org/DebianKernel/GitBisect but you can't really follow that without a working system.

EDIT: confused nonsense removed.

[bmx34]

OK, now I have nailed down the first distribution causing issues : Jessie.
I can install 7.11, but 8.0.0 fails. Looks like a regression indeed.

Next step : have a look at GitBisect !

[Deb-fan]

Make that A+ for effort.

Rampant speculation follows. It did cross my mind to suggest trying older kernels, though have zero clue what quality in terms of performance or other significant metrics such an install would be likely to have. Would be far too many question marks to endorse or advise anyone of such a course of action. Like many things could be a try it and see situation. Using older kernels on Buster. Have formerly installed archived software from former releases (gksu) and yep, continues working w/o problems. Might also focus on older versions of gnu/nix firmware. At some point software must be slated to being dropped and that system would reasonably be a candidate for that type of thing @15yrs. Can't be very many pc's that old still commonly in use.

As with so much else hardware related, comes back to kernel + firmware.

[trinidad]

https://www.supermicro.com/support/reso ... bility.cfm

TC

[Deb-fan]

Might have something to do with it. The date of that system, stems from a time Intel was just starting to release 64bit chips apparently. AMD beat them out, doing so in 2003, depending on reference ... Intel didn't follow until 04 or 2005. Looks like that architecture was abandoned in Jessie onwards.

https://wiki.debian.org/Ports/ia64

PS, not that overly matters, you got 64b. Should mean 64b Java, thus Minecrafty goodness for the younguns. Have said often just because x-software goes end-of-life clearly doesn't mean it ceases working or being perfectly good software.

[p.H]

Xeon processors are x86, not Itanium. Itanium (ia64) has nothing to do with x86_64 (amd64). They are totally unrelated architectures and processors.

[bmx34]

It took me a few days of dichotomy in kernels, but now I know which is the first one failing.

3.4.113 is OK
3.5.1 fails.

I've had a look at the changelog (https://mirrors.edge.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.5.1), and some changes are definilty cpu specific, but nothing obvious to me can explain my problem.

Bisect can now help me spoting the faulty commit I guess.

[p.H]

What about 3.5 ?
ChangeLog-3.5.1 only contains changes between 3.5 and 3.5.1.