Integrating cusom kernel builds & packaging with pi-gen #768
Comments
Not that I am aware of, but it's a fairly frequent request, so it's worth thinking about.
How would these be kept up to date after the customer installs the image?
That's right.
In the
Another person was working on something like this recently. You can see how far they've got here: raspberrypi/linux#6063 (comment) One thing to keep in mind is that our |
|
That's a perfect leg up to get started, thanks!
The main thing I'm trying to avoid is doing things outside of the debian packaging model. For example, the documented kernel install method here : details just copying binaries over the top of what the apt package installed. I'm not quite sure of exactly what the interactions are having not tried it, but it looks like an Ideally I'd like to be able to create a parallel set of custom linux-image packages that one can update from a private PPA that are separate to standard linux-image-xx much in the same way as you have in debian using linux-image-rt- or linux-image-cloud-. I think the other piece of the puzzle is tracking where the apt-get source packages are put together. So I can see that it's from the rpi linux kernel and the linux-packaging repo ; Id assumed the repos would be tagged with a script somewhere to put together the build but I couldn't find such a thing anywere. Is there even a log of git revisions used per release or do we need to compare source packages coming from apt-get source to the originating repositories manually to do this? |
There's a few ways to make this work - you could use the Replaces directive on your new package, or apt pinning to disallow the regular linux-image* packages. A PPA is a very Ubuntu concept, but there's little stopping you hosting your own apt repository using Reprepro or aptly. To make use of that, you'd adjust the default sources.list specified in Stage0. Don't forget to enforce your signatures! Generally, you'd expect a release to have an associated annotated tag - but you might also be able. to retrieve the source from apt itself: https://www.cyberciti.biz/faq/how-to-get-source-code-of-package-using-the-apt-command-on-debian-or-ubuntu/ |
It's still just an apt repo underneath and Raspberry Pi OS would happily use them. However, if I recall correctly, to add something to a PPA, you upload the source package and then Launchpad builds it for the appropriate architectures and releases. The main problem is that the build environment (Ubuntu) would not match the target. It 'should' work, but if you'd like to avoid potential headaches, build packages in the environment they are intended to run on.
I don't quite understand what you feel is missing. The linux-packaging repo is all that should be needed. The changelog contains the upstream kernel version and the git hash of the raspberrypi/linux commit used to generate rpi.patch. A debian source package is meant to be self contained, you don't need something outside of the packages listed in build-depends to build it. One sec, I'll provide some examples... |
Ignore my reference to PPA's, that's me brain-farting ; using an apt repository would be ideal. |
Ah, OK that makes more sense - I'd not realised that was captured in the changelog... I think my brain was fixated on expecting a tag reference somewhere! So, one only needs the linux-packaging repository? I had a read though both README's and its not clear how the build should be performed. Following README.source I did : But that just applied the debian patches but not anything rpi related. Looking at what "apt get source" supplies compared to what's committed in linux-packaging, I can see that the debian dir that apt get source gives us also includes a "rules.gen" and a lot of rpi specific scripts that aren't present in linux-packaging repo so things don't quite seem the same (unless there's a step Im not aware of that generates these?) - looking at the script from another user you refrerenced in a comment previously I can see that in their build script https://github.com/febus982/rpi-kernel/blob/7d7c33fb020149449ffcd06e53573d277d70d082/scripts/build_kernel.sh#L56 they refernce this rules.gen... Can you shed any light on how these relate? I also looked at README.Debian, which confusingly states "We recommend using the 'make deb-pkg' target provided by the upstream kernel source." - which was in fact what I tried doing originally before logging as an issue because it didn't work ; I haven't looked further yet as wasn't sure which direction to spend effort, but I suspect that maybe the package is OK but update-initramfs doesn't do the right thing to allow to work? So now Im not quite sure whether I should focus attention on getting the normal deb-pkg target to work, or the build via linux-packaging... |
|
I am actually interested in doing something similar. @XECDesign
in the past I used to build a deb package for this in a certain stage, but that no longer works |
Hi,
I've been looking around and I can't seem to find any examples of people integrating custom kernel builds into pi-gen, do any exist?
In an ideal world, I'd like to build a modified kernel from the same source as the RPI OS (Im using bookworm 64-bit and cross compiling) and pump out a set of uniquely named .deb files that then get pulled into our pi-gen stage. I can see that the source comes from (I think!) linux stable and rip-distro/linux-packaging but I cant find any docs / scripts / forum posts / anything demonstrating how these packages get built...
With the lack of anything else, I managed to get the 'build-kernel' script from the RPI forums to work and I'm contemplating hacking this into pi-gen and copying the images into /boot/firmware as a temporary solution but of course it's less than ideal and would be (rightly) over-written by any apt udpates.
If anyone can point me in the right direction to get this working at my end, I'd be delighted to put together a documented fork of pi-gen showing how to do it for others to find in the future...
Thanks!
The text was updated successfully, but these errors were encountered: