Gigastrand FAIL and what we know now

Failure at Gigastrand is always an option. To fail is acceptable as long as there is a lesson in it.

Many months ago, Gigastrand set out to do something impossible: piggyback a 64-bit architecture onto a 32 bit system. In Linux there was a slim possibility that this could work with multiarch support built into Debian. We postulated that by installing the architecture, as long as the hardware was there to support it, we could run 64 bit programs on a 32 bit system. We have done the reverse of this in Gigastrand OS 3.x (32 bit architecture on 64 bit system) with great success.

Why in the world would we want to do this? For a lot of reasons. 

1. It would extend the viability of Gigastrand OS 2.x


2. It would force compatibility with 64-bit software like Chrome with a 32 bit OS


3. It will maintain compatibility with older hardware while allowing advancements to the OS

We came close – really close – to making it work. In the end, the one program we really wanted to work, Chrome, just would not even install.

We still believe that it is hypothetically possible, but beyond our capabilities.

So, we began going around to our customers and upgrading their systems to 3.0 so they can still use Chrome. We fixed the version of Chrome in place in version 2.4.

Then we come to fail number 2.

We were upgrading a machine from 2.2 to 3.2 when we noticed the system would boot very slow, error out with a “no microcode for this processor” then fail when trying to start X – the user interface (UI) for Linux. We tried all the usual troubleshooting (replacing discs, trying different drives, etc.) but all gave the same result. Without being able to boot into X, installing the OS will be nearly impossible.

So, we booted back into this customer’s original OS and checked to see if the microcode was installed. It wasn’t.

Then we opened a terminal window and did an lspci command (you can also look at Go>System>Kinfocenter for a graphical depiction and a few more tools). Via chipset, Via graphics, Via processor.

Our best guess is that the processor microcode that is installed in 3.x – specifically the Intel microcode – is mis-identifying the processor and activating. As there is nothing we can do about it once the install image is created, we simply went back to the original build and created a new image without any of the microcode.

If it works, we will release that image with the 3.4 update. If it doesn’t. We will let you know.

Gigastrand FAIL and what we know now