Hi to all,

there is a bug impacting all Liquorix 32bit kernels. No 32bit kernel boots but stuck in a loop and end in a kernel panic.

The kernel tries to load binfmt-464c module which is 64 bit format and of course fails.
Bootmessage: "request_module: modprobe binfmt-464c cannot be procesed"

You can find informations here:
https://stackoverflow.com/questions/12223258/cross-compiled-kernel-unable-to-boot-because-of-a-strange-module-loop

It would be nice if this can be fixed.

Best regards
df8oe
Back to top

Hmm, the timing of this report isn't too bad. I've been thinking of sunsetting support for 32-bit kernel builds.

1) Building for 32-bit / 32-bit PAE takes twice the CPU resources to compile than 64-bit

2) The 32-bit / 32-bit PAE kernels take up twice the storage space than 64-bit

3) Per my access log metrics and some data from the Ubuntu PPA, 1 out of 250 users installs a 32-bit kernel

4) Canonical no longer makes 32-bit images to use 32-bit kernels with, you must install an older 32-bit version of Ubuntu and upgrade all the way to the latest

6) Canonical is planning to only support key important 32-bit libraries to support steam and wine

7) Arch, the distribution I run all my kernel builds from doesn't support 32-bit other than multilib libraries, similar to what Canonical is planning

And finally, the number of machines running 32-bit is so small that a report like this happens that looks completely absurd - a module is some how compiled into a 64-bit format that a 32-bit kernel cannot read, in the actual kernel build itself that is mainline.

Yup, no one is testing 32-bit anymore. On the switch to 5.2 I'll disable 32-bit builds for Debian (these are done from my machines), and leave the code in the Debian package in-case someone needs to build 32-bit kernels for themselves or a project they're part of.
Back to top

Thanks for your answer - so I am leaving the project. The only argument I had was 32bit support for recent kernels. If it is stopped I do not need Liquorix kernels...

Best regards
df8oe
Back to top

We've talked about this a bit, and the conclusion we came to was similar, people who want to run 32 bit systems should probably not be using liquorix kernels at this point, so your decision to stop using them is probably the correct one.

I was, by the way, one of the later people to still use 32 bit kernels as well, and PAE, but particularly in the case of 32 bit non PAE, the only realworld systems I know of that could run that, or should, were Pentium M class laptops, which did not have the PAE flag/feature. That's for example an IBM/Lenovo T40 to T42 laptop, which is really old at this point.

I tend to agree with what damentz says here, the userbase numbers are simply too small to warrant his time/energy in terms of 32 bit, and users of 32 bit kernels are almost certainly better off not using performance oriented cutting edge kernels like liquorix, but instead, a distro kernel that is stable and reliable for old hardware.

Once the testing pools fall off, as is the case for 32 bit, that means, basically none of the kernel developers are running 32 bit systems, which means, none of the alpha and primary beta testers are running that kernel, which means, a ton of bugs are going to start appearing, since they won't get caught and handled at the proper stages of development for each kernel release.

The exception to 32 bit is in ARM, but liquorix doesn't do 32 bit ARM so that doesn't matter, but ARM does have realworld hardware that is current that is 32 bit, though that too is decreasing steadily. But it does exist.
Back to top

I understand all you have written. You have done nice work and I like it very much. But - as we already stated - I must take a look at other places fo 32bit kernels.

Best regards
df8oe
Back to top

Just for completion, I'll link the github issue I made recently and mark this thread as solved: github.com/damentz/liquorix-package/issues/18
Back to top