raspberrypi-kernel-headers on > 6.1.19 kernel

[terminet85]

Describe the bug

From 6.1.19 the default kernel booted is arm64, instead of armf. So many systems have kernel in 64bit and userland in 32bit.

I this scenario, apt will check the userland architecture in order to install packages, that's mismatch the kernel one, installing the wrong headers.

In order to fix this would be better include 64bit headers in armhf package too.

#5395 (comment)

[XECDesign]

What would be the point if there's no compiler that would be able to use these in Raspbian?

I think if you require the ability to build out of tree modules or anything else that requires the headers, you'd have to either switch to a 32-bit kernel of a 64-bit userland.

[terminet85]

What would be the point if there's no compiler that would be able to use these in Raspbian?

So in this scenario I cannot compile any new modules... :/ That's odd...

[aurimas-kudarauskas-epam]

Have related issue that after running apt full-upgrade i can not build v4l2loopback module as dkms script fail for missing headers. Also dpk expect that system is running armhf but uname reports arch64
It was working perfectly with 5.xx kernel releases. So I would agree with terminet that it is an issue, as updating to stable version breaks kernel module installation

[pelwell]

What would be the point if there's no compiler that would be able to use these in Raspbian?

sudo apt install gcc-aarch64-linux-gnu works on a 32-bit RPiOS.

[XECDesign]

Oh, I don't remember that being there. Thanks.

I guess we'll need to have a think about how to make that work as expected in this environment.

[aurimas-kudarauskas-epam]

Maybe you have a suggestion what I could do about v4loopback module or should I create a separate bug report?
Already tried to manually reinstall headers.

[pelwell]

Separate bug report, please, otherwise these issues can get very messy.

[Pcdwarf]

Yes. I want to be able to compile out of tree modules.
It seems difficult without the headers.

from what i read here, pios is all 32bit but the kernel is 64 ?
I may be a little bit old fashion but what's the point in not having the same architecture for both ?

BTW, I have no use of a 64bit kernel and would be happy with a 32bit one if it works on the pi4 hardware.
How do I force execution of a 32bit kernel on a Pi4 ?

[XECDesign]

from what i read here, pios is all 32bit but the kernel is 64 ?
I may be a little bit old fashion but what's the point in not having the same architecture for both ?

PiOS comes in 32-bit and 64-bit flavours, but they both now default to a 64-bit kernel, which I believe makes better use of RAM and improves performance in some cases.

How do I force execution of a 32bit kernel on a Pi4 ?

You can add arm_64bit=0 to /boot/config.txt to go back to a 32 bit kernel.

[6by9]

PiOS comes in 32-bit and 64-bit flavours, but they both now default to a 64-bit kernel

Correct on Pi4.

Pi0, 1, and original 2 are only 32bit processors so can't support a 64bit kernel, and later Pi2 & Pi3 have no real gain as they only have 1GB of RAM.

[Pcdwarf]

ok thanks.
I'm switching to the 64bit flavor of pios and will come back here if it still can't do dkms compilation.

Although, just my two cents : for me, it seems wrong to default on a kernel which is not compiled using the same architecture than the main os. Yes, it would restrain maximum addressable memory on some platform but on theses, it is best to run the full 64bit os. BTW, I think that the 32bit pios should encourage the use of the 64bit flavor when it sees an arm64 platform such as pi4.

[terminet85]

@Pcdwarf have you tried to force install the 64bit headers?

[Pcdwarf]

@terminet85 : there is no quick way to force that on 32bit OS. ( RPi-Distro/repo#327)
And as @XECDesign said earlier : I would also need the full compiling stack for 64bit to build a module.
Although it would be possible, cross-compilation is always a little tricky. It is not just apt install and voilà.

[terminet85]

@Pcdwarf you pretty wrong... there are multiple way... as download the .deb e force install it.
And gcc-aarch64-linux-gnu is pretty available as already said.

Of course isn't ant apt install, we aren't talking about dkms compiling, or what?

I think is more constructive, searching to fix this in hybrid environments (kernel arm64, user land armfh), rather than finding the easy way which solves your problem.

We introduced this "problem" so we need to deal with it.

[Pcdwarf]

@terminet85 ok, you're right. At the moment I'm just searching how to compile an out of tree module for my PI4.
switching to arm64 PiOS is by far the simplest way because it don't need to override defaults. I've just done it and it works perfectly.
My point is that I really wasn't expecting that the kernel would had a different arch than the os. At first i thought v7 v7l and v8 were only flavors with different compiled-in drivers but the same arch. My misktake.

Anyway hybrid environments with kernel and userland not using the same arch have always been prone to problems and it seems to me that this kind of environment should not be used by default.

[XECDesign]

I've been taking a look at Debian's kernel packaging, since I was hoping it would resolve the problem. On stock Debian, DKMS seems to work fine in the case of an amd64 kernel with an i686 userland, but the same can't be said with arm64 and armhf. When you try to install the headers package, it tries to pull in the native arm64 toolchain rather than the cross-compiler. Since you can't have the armhf and arm64 toolchains installed side-by-side, apt either fails to resolve dependencies or removes important system packages.

I'm sure somebody will say "then just default to always using the 32-bit kernel on 32-bit userland", but it's a balance between the needs of users who want dkms to work out of the box without further changes and everybody else who would just appreciate the performance boost of a 64-bit kernel and we landed on the latter.

I think once I'm done sorting out the new packaging, I'll add a message so that when dkms hooks run, they inform the user that they need to either set arm_64bit=0 or uninstall the arm64 kernel.

Maybe somebody can raise the issue with Debian's kernel team, but for the foreseeable future, this looks like an unsupported use case.