New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing kernel headers #4
Comments
|
For what it is worth I have been making functional arm64 header packages for the current firmware rpi kernels for use in ubuntu 64 bit on my RPI4 with this hacky script: https://gist.github.com/satmandu/a507c59d84737f6d29ff353395819d51 |
|
There's no good way to get a headers package without throwing the current kernel package out and doing it the right way from the start. That is a WIP, but won't ship in the near future. |
I was just trying a custom driver with DKMS and it progressed through armv7 correctly and just stopped on aarch64 because one didn't exist. It looked like the addition raspberrypi-kernel-headers:aarch64 would work as expected with raspberrypi-kernel-headers:armhf but is just missing? |
i've just tried your script on Raspberry Pi OS which builds deb headers & kernel packages fine , error setting ownership of './boot/config-5.4.42-v8+': Operation not permitted any idea how to solve this? |
Sorry, but no, it's not that simple. It's certainly possible but would add a lot of extra manual steps to the build process involving running things in containers of different architectures in two passes. That will waste me many hours in the future. That time would be better spent upfront fixing the package so that everything just builds as expected in the first place. |
|
@tomerr: you cannot set ownership/permission on /boot because it is fat32 Maybe unmounting /boot while performing the process and make the false /boot directory will help to finish the process. |
Hi, I am testing your script on a 4GB raspberry 4 with the following operating system : Raspberry Pi OS (64 bit) beta test version :
I need linux-headers so I can install wireguard, but when I launch your script comes out with this error:
could you tell me what to do? |
i think you're not using the official raspberry kernel - uname should read Linux raspberrypi 5.4.42-v8+ #1319 SMP PREEMPT Wed May 20 14:18:56 BST 2020 aarch64 GNU/Linux |
but "raspberry" or "enterprise" are the hostname |
|
oh , sorry. i can run the script again to test what results am i getting now. |
|
you'd be very kind, but as soon as there's a kerel update, I'll be in the same situation. I need to figure out what's wrong. EDIT: I understood the problem, I was doing it like this: sudo sh./make_deb.sh |
|
I'm about to load up the test 64-bit image... so I'll try to get the script fixed then. |
|
I had to keep my script from dropping the kernel config file into /boot and trying to set permissions on it. Once that was commented out, the headers package installs fine. |
The script works flawlessly and I've got kernel headers for 5.4.44-v8+ working without any issue. +1 Kudos! |
@XECDesign What qualifies as the "near future"? Are we past that yet? |
|
A headers package may or may not show up at some point. I'd like to promise that it will, but something more important always comes along. |
Could I try to help out with that? What are the blocking issues? |
|
Wireguard is a must for me, and it's very easy to install in Ubuntu 20.04 64bit for the RPi4. So that's why this bug means to a lot to me, to be resolved. I'd like for Wireguard to be easy to install, and not break every time some kernel security update is released, downloaded, and installed. |
Can you please tell us more about what a proper fix would entail, @XECDesign ? Can you please break it down for us? |
Just build your own kernel if this is urgent. It's pretty straightforward. I've been doing it since a long time on the RPi itself. This is enough for extracting the headers (based on kernel scripts): Then move it to the /usr/src and re-link /lib/modules/$KERNEL_VERSION/build to that directory. I'm using wireguard too – on arm64:
|
|
Now that we have a 64bit Raspberry Pi OS, the raspberrypi-kernel-headers package for arm64 would be something nice to have. It would allow easier kernel updates when we are running out-of-tree kernel modules. |
|
For everyone landing on this Page. With this solution it finally worked: WATCH OUT ! -> Don't install raspberrypi-kernel-headers (its mentioned in the Guide above in the category "Setting Up a VPN with WireGuard". Just use this command instead -> Installed Pi OS64 from scratch Used my little update command -> sudo apt update && sudo apt-get -y upgrade && sudo apt-get -y dist-upgrade && sudo apt-get -y autoremove && sudo apt-get -y autoclean Used this script to build the kernel headers -> https://gist.github.com/satmandu/a507c59d84737f6d29ff353395819d51 Installed the builded image with -> sudo dpkg -i --force-all linux-image-5.4.51-v8+_arm64.deb (some error messages appeard but wayne) Installed the builded headers with -> sudo dpkg -i --force-all linux-headers-5.4.51-v8+_arm64.deb If dependencies are missing use -> sudo apt --fix-broken install Now Proceed with the Guide above and the installation of Wireguard should work, even on 64. |
|
copy pasted this nice script into this nano make_deb.sh |
|
Removing the non-arm64 headers and modules per @MichaIng's instructions did the job for me too. Presumably this is a fragile solution though – it will break with the next kernel update when new headers and modules are installed? |
|
Good to know that it was not only us where it is required. Yes, unless there is something changed to fix non-arm64 WireGuard builds, the next package upgrade would fail the same way. Although you could make it permanent by adding a script to Another cleaner solution would be to skip installing non-arm64 kernel modules + headers from the DEB packages in the first place via But that does not work for |
|
Added a 5.10 kernel to the 'untested' component with non-64bit files removed, if anyone would like to test it. Wireguard dkms.conf from debian-backports doesn't try to build it for 5.10, but v4l2loopback-dkms seems to work as a test. |
|
Great, many thanks! The current firmware (libraspberrypi0/-bin) libraries and binaries do work with this kernel build, don't they? |
|
No promises |
|
Fair enough. If anyone faces issues, affected binaries/libraries (/ |
looking good, Wireguard works for me |
|
WireGuard is built into this kernel anyway, so headers and dkms are not required to get it running with this kernel, simply do |
|
It looks like headers weren't built for the latest kernel? |
|
It looks like you haven't installed them: |
|
but it is the 32bit apt package. isn't it?
|
|
This is automatically built for all architectures, including x86_64 and i386, maybe for cross-compiling: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel-headers_1.20210201-1_arm64.deb |
|
So can the issue be closed then? |
|
The only case I remember where a build failed, despite the kernel headers package, was with WireGuard which is shipped as builtin since Linux v5.10, so I'd say yes. Any build issues make more sense in an own issue. |
|
Cheers, thanks for testing. |
|
You're on the wrong repository here. You run an ARMv7 kernel, hence it's impossible that you use the Raspberry Pi OS 64-bit image. What tools is it that shows you this wrong and misleading message? "v8+" wouldn't be a "new" kernel version, but the kernel for the ARMv8 architecture, hence for the 64-bit image indeed. Since your kernel is the ARMv7 one, that should stay as it is. But it is correct that your kernel is outdated (current is 5.10.x), and furthermore you don't have the headers package installed, hence the missing headers. Do the following to upgrade it and install headers: |
|
Thanks
I did run the update and install and I have a question it INSTALLS vga666
is that for REAL ?
[image: image.png]
Thanks in advance
Ra
…On Sat, Jun 12, 2021 at 7:55 PM MichaIng ***@***.***> wrote:
You're on the wrong repository here. You run an ARMv7 kernel, hence it's
impossible that you use the Raspberry Pi OS *64-bit* image.
What tools is it that shows you this wrong and misleading message? "v8+"
wouldn't be a "new" kernel version, but the kernel for the ARMv8
architecture, hence for the 64-bit image indeed. Since your kernel is the
ARMv7 one, that should stay as it is.
But it is correct that your kernel is outdated, and furthermore you don't
have the headers package installed, hence the missing headers. Do the
following to upgrade it and install headers:
apt update
apt install raspberrypi-kernel raspberrypi-kernel-headers raspberrypi-bootloader
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHISA7BIKKI7PTWVSLK4PQDTSPXVJANCNFSM4NNBBQHQ>
.
|
Yup https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L3310 - the "666" just means 6 bits for red, 6 bits for green and 6 bits for blue. |
|
FWIW, I rather think that it is not 6-bit red / 6-bit green / 6 bit blue , but just 6 red + 6 green + 6 blue . 6 x 6 x 6 = 216, which is smaller than 255. This is a way of doing 8-bit colors using a 6 x 6 x 6 color cube. It knows about 216 different colors in total.
Having vga at 8-bit color, using a 6x6x6 representation of colors, makes a lot of sense. It is a color vga with very "blocky" (non-24-bit) colors.
Sometimes you uses vga at 16 bit color at a 5 bit red / 6 bit green / 5 bits blue representation . 5 + 6 + 5 = 16; or just waste one bit at 5-bit / 5-bit / 5-bit. Some would allocate one more bit to green which the eyes are more sensitive to.
These are all very old representations, before 24-bit true colours on computers became the norm.
|
|
FWIW, you're wrong - this uses 20 pins to provide 18-bit colour with 2 sync signals: |
|
Oops. How's that 18-bit byte-aligned? That's more than 2-bytes and less than 3 - seems wasteful. One might want to do 24-bit color (padding and dropping the lower 2 bits) anyway, if 3-byte is being moved about...
|
|
I believe the firmware will do the best it can with any source display format, e.g. a full 24-bit RGB, 565 etc. The overlay is just asking the kernel to set or preserve the alternate function selectors on those pins. |
|
There's more info here: https://www.raspberrypi.org/documentation/hardware/raspberrypi/dpi/README.md |
|
Argh, thanks both of you for the raspberrypi display info! That's quite different from x86 land! |
|
RGB565 and RGB888 (and others) exist as input pixel formats to be rendered to a display device. However the vga666 overlay is for a hardware device called the vga666 that converts the DPI interface (which I don't believe any x86 platform has ever supported) into VGA using a simple 6-bit per component resistor ladder. It's never a format that is stored in memory, so byte alignment is irrelevant. |
|
So vga666 is a HAT? That's cool. Fen Logic sounds like a company based in north east Cambridge... |
Not a HAT as it doesn't have the ID EEPROM, but an add-on board, yes. It can be bought from the likes of Pi Supply, and various eBay sellers.
The board was designed by Gert van Loo who is one of our former colleagues at Broadcom in Cambridge, and he open sourced that design via his side-line consultancy firm - https://www.fenlogic.com/index.html |

The image contains the kernel package in version 1.20200527-1
But there is no matching header package available in the APT repository.
The text was updated successfully, but these errors were encountered: