-
Notifications
You must be signed in to change notification settings - Fork 122
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
Kernel Packages #126
Comments
Hi JRWR thanks for your support the offer sounds great! Are you talking about deb-pkg/.deb kernel package or are there any other possible ways to do that? 459below and me tried that and failed. maybe you have some ideas, maybe stuff has changed since that: ps. I would love to have rpi23 deb-pkg/.deb kernels! |
Hrm, I could compile the kernels on hardware, dedicate a scaleway instance to it, since they use the same arch |
Hi my point was that we tried to use make-kpkg - that should exactly do the "need the script to build and package them". it was tried but (back then) not possible. no matter if a cross_compiler was used or if the package was build inside qemu/bootstrap environment. (#98). I am not very used to create debian packages and I am not very used to make-kpkg. From my basic understanding it just creates a .deb file that includes kernel-source, kernel-image and kernel-headers. I would not like to maintain, or better be responsible for maintaining binary images (of generated rpi23-$release.img and kernels). But I would love to just a link/ref to the generated kernel packages like the "Weekly image builds" at the end of the README page. I don't know if I find time to include a "EXPORT_KERNEL_PKG" parameter in the script that works like "make-kpkg". |
Linux kernel source has within already scripts for building kernel as a binary package set;
so there's no great need for However, it may be more long-term helpful to work with Debian project to have kernels built; the Fedora project does so, after they overcame some licensing issues. If I recall correctly. |
@quozl cool - never heard or this |
Any news on this? I have started back up my builds for the images again, updated to buster this time for my weekly builds |
So I just skimmed the whole topic here but I want to point out that I've been building kernel deb-packages for a system setup by rpi23-gen-image this whole time without any problems. The script I used for that is here
and obviously config.txt would need kernel=vmlinuz and maybe the respective initramfs line if one needs ramfs for encryption or so. Though leaving the old kernel and _sed_ing the config.txt would be more appropriate, obviously. I think the rpi3-firmware package in the Debian repo has something like this. The other thing is the official Debian support is in the making https://salsa.debian.org/raspi-team/image-specs though my rpi3 runs rpi23-gen with a kernel made by the gist mentioned earlier my rpi2 runs this official debian preview with the official 5.2.0-2-armmp kernel from the official Debian repo. A lot of official. However, when I tried to get a proper shutdown/power-on GPIO button through the gpio-shutdown.dtbo I noticed that the Debian kernel doesn't seem to have the expected GPIO support. I just learned about this Debian GPIO project, which seems to make "basic" GPIO on the rpi possible, though I suspect it won't be like just setting dtoverlay=awesome-overlay in the config.txt, though. So I like the idea of having a proper officially supported Debian on the pi with kernel updates and all, but at least GPU /edit |
OK, so on the image by gwolf I'm still able to swap the kernel with the one I'm running on the rpi23 image, as expected. The thing is that the rpi is so very picky about the DT and fixup stuff. So the Debian kernel is version 5, to which I've not yet upgraded to. Like always: the wifi doesn't want to just work OOTB after the upgrade. Since I now need a kernel module, hence I'm going to setup a docker build image to produce crosscompiled .deb. |
https://hub.docker.com/r/459below/rpi So I've already build .deb packages with this. |
sounds good! |
If this project wants to maintain them, I can do weekly packages for rpi2/3 kernels for people to update their Raspberries with
just need the scripts to build and package them
I suggest a flag to export the kernel packages out so I can sign then externally and put them in a custom repo.
The text was updated successfully, but these errors were encountered: