Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 472906 - (initial) portage kernel building support
Summary: (initial) portage kernel building support
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Rick Farina (Zero_Chaos)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-10 18:51 UTC by Rick Farina (Zero_Chaos)
Modified: 2016-02-28 13:07 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
stable-sources-3.9.5.ebuild (stable-sources-3.9.5.ebuild,4.19 KB, text/plain)
2013-06-12 20:11 UTC, Bertrand Jacquin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rick Farina (Zero_Chaos) gentoo-dev 2013-06-10 18:51:13 UTC
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.
Comment 1 Rick Farina (Zero_Chaos) gentoo-dev 2013-06-10 20:25:32 UTC
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.
Comment 2 Bertrand Jacquin 2013-06-12 20:11:01 UTC
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
Comment 3 Bertrand Jacquin 2013-06-12 20:11:49 UTC
I forget to tell that all this work is available here: http://git.meleeweb.net/cgit.cgi/distros/gentoo/portage.git/log/sys-kernel
Comment 4 Rick Farina (Zero_Chaos) gentoo-dev 2013-06-12 20:19:59 UTC
(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.
Comment 5 Dennis Schridde 2016-02-28 13:07:38 UTC
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