Building kernel from source at /usr/src as user
 

Up until recently I've been building my kernels as a root. Today I had some free time and decided to read the whole README file accompanying the latest kernel-source (3.2.13, Slackware). The author of this file (Linus Torvalds?) clearly states the we should avoid building the kernel as root. Does anybody know why? If that is the case why slackpkg preserves root:root ownership during kernel-source installation? I am aware that this is a Slackware related issue, since one can download the vanilla source in his home directory and build it without su permission.

There are some opinions that one can change the ownership of /usr/src to root:xxx granting write access to user from the group xxx, but after installing a new kernel-source the ownership is reverted back to root:root and I need to change to ownership of the directory every time I install a new kernel-source.

Does anybody has a clue what would be the safest (without using another machine) and elegant way to build and install new kernels?

Cheers

Install the kernel in ~/ - that's the safest way. You need most of a gig in home to do that, but whatever blows up, it will stay as a luser.

BTW I take these discussions with a grain of salt, because a kernel compile is the most tried & tested build system anywhere. Heads debate how safe is safe; It's really _you_ is the danger. The scripts work, but what are you going to type.

I wrote this for my own use but you're welcome to take a look/use it if you wish. It's a little unconventional.

It works best if you have set LOCALVERSION in your config files. I use "-generic" and "-custom" for mine, depending on whether it's based on Pat's .config file or my own..

Interesting and useful. Many thanks for sharing!

This is the definitive guide to building a new kernel on Slackware.

http://alien.slackbook.org/dokuwiki/...kernelbuilding

And this is the definitive guide to building Linux kernels, written by a kernel maintainer. He gives an example why you shouldn't build as root.

http://www.kroah.com/lkn/

The paragraph

Sometimes it is easier to have the source code for the kernel tree in a read-only
location (such as on a CD-ROM, or in a source code control system), and place
the output of the kernel build elsewhere, so that you do not disturb the original
source tree. The kernel build system handles this easily, by requiring only the
single argument O= to tell it where to place the output of the build. For example, if
the kernel source is located on a CD-ROM mounted on /mnt/cdrom/ and you wish
to place the built files in your local directory, enter:
$ cd /mnt/cdrom/linux-2.6.17.11
$ make O=~/linux/linux-2.6.17.11
All of the build files will be created in the ~/linux/linux-2.6.17.11/ directory.
Please note that this O= option should also be passed to the configuration options
of the build so that the configuration is correctly placed in the output directory
and not in the directory containing the source code.

from the book, Linux Kernel in a Nutshell, by Greg Kroah-Hartman, published by O'Reilly have helped me figure out an elegant way of building the Linux kernel as user. Still not very clear why I shouldn't build it as root though...
@hf2046 Thanks for the link, very helpful.

... which is exactly the approach my build script above takes, only my script has a bit added onto the end that packages it up.


The "don't build as root" thing is simply a "We might make a mistake in the Makefile and if we do and it's running as root anything can happen" sort of deal. Its more likely a consideration with the development kernels or release candidates though. By the time it gets to a release tarball these sorts of problems ought to have been discovered and shouldn't be an issue.

Even those who say "Don't build as root" generally tell you the 'make modules_install' has to be done as root, and if that has to be done as root then I really don't see much advantage from not doing the rest of it as root.

I see... "O=" is something new for me, thanks. I can mark this thread as solved, thanks to everyone.

Generally I like the idea of staying away from root as much as possible :). Only because I might be careless enough to leave myself in root and accidently bringing up an application that probably shouldn't be run as root.

Sometimes we have to protect us from ourselves :).

Anyways, my point in regards to this thread is that I haven't seen any issues at all in compiling the linux kernel as the user. As Gazl points out though, you can't get away w/ running make modules_install w/o running as root. And most likely to update your boot location, and also lilo, you'd have to run as root as well, but these don't take any time at all to do compared to compiling the kernel.

In the end, do what you got to do to get the job done with whatever security works for you.

Strictly speaking you can, but you'll need root at some point to make it possible (even if it's only a little chowning before and after). It all depends on how many hoops you're prepared to jump through to avoid it and whether it's worth the effort.

Well it turns out that the method with outputting the build to another directory (O=) requires preliminary use of "make mrproper" which wants to remove "./kernel/bounds.s" and "./arch/x86/kernel/asm-offsets.s" files from the source directory. Is it save to remove these files? Are they unnecessary? I presume these are Slackaware specific?

They won't be slackware specific. And it's always a good idea to do make mrproper or make distclean before you build from the source.

Ah I see, but then it requires su permissions...

I just updated to 3.2.14 and thought you might be interested in seeing my approach in action.
.
As you can see the new kernel was built by 'build' and not root.


And this is how I got there.

History of my 'build' user
(I prefer to keep my git tree separate to the source I build from, but I could have built from the git tree if I had wanted to and avoided an additional step and a 'su' .)


And then as root:
(Don't worry too much about the initrd_build script: it is just a front end to mkinitrd - nothing much of interest in there.)

... and job done... reboot to shiny new kernel.

I see that you are fetching an untouched source of the Linux kernel (linux-stable) and thus avoiding to run of "make mrproper". I am obtaining my source through slackpkg and therefore need to run "make mrproper" :). I would be grateful if somebody explains what is the difference between the two sources. Thanks

Alkin

Not really avoiding a make mrproper, but the "git clean" does a similar job. I probably ought to be doing a "make distclean" before that cp step to be absolutely sure nothing slips through, but so far I've not had a problem skipping that step and I'm just being lazy and relying on git being in a clean state..


The slackware packaged kernel source tree appears to already contain a .config so it's not entirely clean. Which explains why you're having permission problems when running the make mrproper as a non-root user. If you want to clean up the slackware shipped sources then you're going to have to do it as root.

Ahh I see, thanks.