I’ve just switched over to EOS on my Pi 4 and I’m loving it so far. It’s nice to have a match with my main system.
One of favourite things to do on Raspberry Pi OS (RPOS) and Manjaro was build a kernel with a few patches and tweaks according to the Raspberry Pi Documentation. However, I can’t get these kernels working on EOS.
I’ve tested the very same custom kernel on both RPOS and Manjaro where it boots as expected, with uname -r confirming the new kernel is in use. On EOS, I get the Pi’s usual rainbow splash screen and then nothing. I’ve removed quiet from cmdline.txt and also tried loglevel=7 but nothing ever comes up, so I’m assuming it never gets that far.
The options in config.txt have been the same in all three distros. Does EOS do something different that prevents custom kernels from working without additional configuration?
No. 1 is called “The Linux Kernel and modules - AArch64 multi-platform”
No. 2 is referred to “RPi Foundation patched Linux kernel and modules”
EnOS uses the linux-rpi kernel that is from the Raspberry Pi Foundation. We use this kernel as is from the Archlinux ARM repositories. No modifications what so ever are made.
I have no idea which kernel of the two offered that Manjaro uses. I also don’t know what modifications Manjaro does or does not make on their offered kernel. It would be unfair for me to speculate on anything in their offering.
We then remove the linux-aarch64 kernel and uboot-raspberrypi
Then install linux-rpi raspberrypi-bootloader raspberrypi-firmware
Here is the code for that
I’ve had a look through the scripts you linked and the process makes sense.
The linux-rpi kernel is working as expected and I’ve cheked that raspberrypi-bootloader and raspberrypi-firmware are installed and up to date. Since that’s all working, I’m not sure why my custom kernel won’t boot if the working linux-rpi kernel works in the same way.
One difference I’ve spotted is that the modues in /usr/lib/modules for the default linux-rpi kenel contains a build folder, while the modules folder generated by the custom kernel doesn’t. I’m not experienced enough to know exactly what that means but a quick search tells me it’s something to do with the kernel headers.
linux-rpi-headers is installed, but linux-rpi (and subsequently linux-rpi-headers) are 6.1.xx, while the custom kernel I’m trying to install is 6.2.x.
I believe the default Manjaro kernel for the Rpi4 pulls straight from the default branch of the raspberrypi/linux Github by looking at this PKGBUILD. I don’t remember the Manjaro default kernel modules in /usr/lib/modules having a build folder either, though I could be misremembering that. It’s difficult to tell exactly what’s what since the package naming conventions for the three distros are different.
That build folder might not have anything to do with it at all but the difference is interesting.
It would be cool to figure this out as EnOS is the only distro so far that has the problem but since it functions perfectly fine on the standard kernel I can’t really complain. Learning more about how it all works is interesting anyway.
If you have a spare micro SD card, and some spare time, would you be interested in doing some testing?
Starting with Cassini, the EnOS liveISO and Calamares started installing and enabling firewalld. Prior to that, no firewall was installed by default, and I installed ufw for the RPi 4 headless server.
So, I had to update the script that creates the RPi 4 headless server image, and all of the How-to articles to work with firewalld.
If interested have a look at the following to see what you would be getting into.
This is the How-To for installing the headless server. Listed at the bottom are the associated How-To’s which had to be edited for the new procedure. The Homeserver X How-to’s are still a work in progress so any critiques would be appreciated.
If you don’t have the time or inclination to test, I understand completely.
Pudge
EDIT:
Anyone else interested in doing some testing, jump on in.
Sure, I’d be happy to do that. I just can’t guarantee it will be very prompt.
I’ve decided to try installing the custom kernel by modifying EnOS’ linux-rpi PKGBUILD but I’m running into a problem. make INSTALL_DTBS_PATH="${pkgdir}/boot" dtbs_install is failing with the error make: *** No rule to make target 'dtbs_install'. Stop..
I don’t understand enough of the kernel’s makefile to figure out why dtbs_install isn’t working. It’s a rather specific question, but is there a way to solve/get around this?
There probably is, but I don’t know much of anything on compiling a kernel.
Here are the PKGBUILDS we use for EnOS ARM.
linux-odroid compiles a kernel for the Odroid N2+
linux-eos-arm compiles a kernel for the PineBook Pro laptop.
Maybe you can look these over and come up with something. The linux-odroid would probably be better for this.
These are the only two kernels we currently use, and they are @sradjoker 's domain.
Unfortunately his availability is at a minimum for the next few months.
I got it working at last by chaning Arch Linux ARM’s linux-rpi PKGBUILD to make and install a new kernel.
I wouldn’t recommend this method to anyone else who might be looking to do this as I ran into trouble if the package was named differently, meaning this custom kernel is seen as an update to the linux-rpi kernel provided. As a result they can’t be installed simultaneously (and pacman complains that the current kernel is more up to date than the one in the repos). If a version of this custom kernel ever breaks, there will be no second option to boot back to. Perhaps someone more experienced than I can find a way to get aroundt that problem; but for me, getting it to work at all is a win.
Now to spend too much time poorly automating the process for next time.
Just to make sure I am onboard with what you are doing.
What is different with your kernel from the original ArchLnux ARMR kernel? Added Kernel modules or something?
This one is based on the 6.2.y branch of the Raspberry Pi kernel and has some additional patches pulled from other sources, mainly augmenting the behaviour of CFS slightly. I also compile it with Clang/LLVM and on top of that, change the config a bit to enable LTO, use ZSTD compression for the modules, etc.
It’s mainly just for fun to see how it all turns out with the added benefit of having a slightly more responsive desktop (sometimes).
