| Summary: | linux-2.eclass: (initial) portage kernel building support | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Rick Farina (Zero_Chaos) <zerochaos> |
| Component: | Eclasses | Assignee: | Rick Farina (Zero_Chaos) <zerochaos> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | bertrand, dist-kernel, dschridde+gentoobugs, nikoli, rich0, tomwij |
| Priority: | Normal | ||
| Version: | autobuilds | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | stable-sources-3.9.5.ebuild | ||
So here is what I have so far. I've added USE=genkernel which is 100% functional except I have no idea how to mount /boot (if needed).
src_compile() {
kernel-2_src_compile
if use genkernel; then
dodir /boot
dodir /lib/modules
#build out of tree with --kernel-outputdir=
genkernel all --kerneldir="${S}" --logfile=/dev/null --no-symlink --no-mountboot --bootdir="${ED}"/boot --module-prefix="${ED}" --tempdir="${T}" --no-save-config
fi
}
ideally this would go into kernel-2.eclass and be line wrapped for readability.
Created attachment 350852 [details]
stable-sources-3.9.5.ebuild
I work on it since some times for stable and longterm kernel from k.org. This ebuild is fully functional and used in many production system (native or cross compile). Here is how it work.
Ebuild have the possibility to install sources (USE flag source), to be build (USE flag build).
If build is needed, savedconfig eclass is used to restore user .config otherwise, defconfig is generated.
src_prepare() define some pure kernel compile variable (KBUILD_SRC, KCONFIG_CONFIG from where savedconfig restore the config or generated one), then toolchain (CC, HOSTCC, CROSS_COMPILE, ARCH and SUBARCH).
Then, src_compile() check if .config is uptodate (make oldconfig), then bzImage and modules (if CONFIG_MODULE is defined in .config) are compiles.
Then, src_install() install sources if USE flag define it.
Then, src_install() install modules if CONFIG_MODULE is defined, strip then before compressing them with gz or xz if one-of USE flag zlib or lzma is defined, then generate System.map, and finally install /lib/firmware.
Pretty easy.
/boot look like this :
/boot/3.8.13-stable/kernel.cfg
/boot/3.8.13-stable/kernel.img
/boot/3.8.13-stable/System.map
Then main issue I have with it is extra vanilla modules like xtable-addons or rtsp-conntrack that relie on a .config, sources and a prepared kernel. This is why the source USE flag is there.
More over, it use the kernel-2 eclass so it make it easy to apply patches via epatch_user.
Any comments are welcome
I forget to tell that all this work is available here: http://git.meleeweb.net/cgit.cgi/distros/gentoo/portage.git/log/sys-kernel (In reply to Bertrand Jacquin from comment #3) > I forget to tell that all this work is available here: > http://git.meleeweb.net/cgit.cgi/distros/gentoo/portage.git/log/sys-kernel Thanks a lot for pointing this out. I've been studying the work done by Fabio for Sabayon as well: https://github.com/Sabayon/sabayon-distro/blob/master/eclass/sabayon-kernel.eclass And mount-boot.eclass is of course a favorite for making sure /boot is actually mounted. It really helps to have so much work to draw on, even at first glance I see a lot of this as very very useful as problems I have not even considered may already be solved. Are you aware of how CoreOS (based on Gentoo) does this? They have a sys-kernel/coreos-kernel ebuild [1] that depends on the corresponding sys-kernel/coreos-sources package and builds a regular, installable Gentoo package from it, using a config file in $FILESDIR. This seems like a very good solution, as it can make use of out-of-source builds and thus leaves the system clean after finishing the build, but still allows the user to build their own variants of the *-sources using their own config. For the Gentoo ebuild, in pkg_postinst(), it could use e.g. kernel-install (I believe this belongs to systemd) or similar methods to setup /boot according to the user's choice. Which method to take (systemd/kernel-install, cp to /boot/vmlinuz-$ver, ...) could be determined by a use-flag. This appears like something that could be of much use to the GRS (Gentoo Reference System [2]), too. They currently use a custom building and packaging method that produces a plain tarball in the end (i.e. not manageable by Portage). [1]: https://github.com/coreos/coreos-overlay/tree/master/sys-kernel/coreos-kernel [2]: https://wiki.gentoo.org/wiki/Project:RelEng_GRS This has essentially been implemented via the Distribution Kernel [0] project and the kernel-build and kernel-install eclasses. It does not use genkernel though. [0] https://wiki.gentoo.org/wiki/Project:Distribution_Kernel (In reply to Sam James from comment #6) > This has essentially been implemented via the Distribution Kernel [0] > project and the kernel-build and kernel-install eclasses. > > It does not use genkernel though. > > [0] https://wiki.gentoo.org/wiki/Project:Distribution_Kernel Closing as OBSOLETE accordingly. |
Before you quit reading, this is intended to be for basic/emergency use and binary packages. Power users (read 99.999% of gentooers) will likely have very little interest in this. I'd like to add a few flags to sys-kernel/*-sources or linux-2.eclass (linux-3.eclass?) Ideally, one should be able to set a use flag, and have portage automatically build the kernel with genkernel defaults and install the kernel, initrd, and config in /boot, as well as the modules in /lib/modules and the sources in /usr/src/${P} with at minimum "make modules_prepare" run and the .config in place. We can argue details as we go along the way (implement as part of *-sources or as completely new package *-kernel) but the following flags have been suggested already: USE=genkernel This controls if the kernel is built automatically or not, this would apply only to the *-sources modification idea, a new package would obviously be meant just for the built kernel so having a flag like this is silly. USE=objects Controls if the built objects are installed into /usr/src/${P} or not. "make modules_prepare" must always be run, but the rest of the objects really are not nessesary for anything but potentially speeding up a later kernel rebuild (and honestly many of use "make distclean" or worse before rebuilds) so we could save the space and not install it by default.