| 1 |
In linux.gentoo.user, Mick wrote: |
| 2 |
>> |
| 3 |
>> I use a separate output directory that is under control of the user. |
| 4 |
>> What I do as an ordinary user: |
| 5 |
>> |
| 6 |
>> mkdir <kerneloutputdir> |
| 7 |
>> |
| 8 |
>> zcat /proc/config.gz > <kerneloutputdir>/.config |
| 9 |
>> |
| 10 |
>> # assuming you have this option set in your kernel ie the current |
| 11 |
>> kernel # config saved in /proc/config.gz |
| 12 |
>> |
| 13 |
>> cd /usr/src/linux |
| 14 |
>> |
| 15 |
>> # assuming that /usr/src/linux is a soft link to your new kernel # |
| 16 |
>> directory. |
| 17 |
>> |
| 18 |
>> make O=<kerneloutputdir> oldconfig |
| 19 |
>> |
| 20 |
>> # The "O=" makes sure that any kernel output goes to the directory |
| 21 |
>> under # the permissions and control of the kernel builder user rather |
| 22 |
>> than in # the kernel directory under root permissions. |
| 23 |
>> |
| 24 |
>> # If you want to make changes to the new kernel then: |
| 25 |
>> |
| 26 |
>> make O=<kerneleoutputdir> menuconfig |
| 27 |
>> |
| 28 |
>> You can then proceed with building kernel and modules. Yes, I know |
| 29 |
>> that "make" without a command will automatically build both kernel |
| 30 |
>> image and modules but I prefer to do things explicitly. |
| 31 |
>> |
| 32 |
>> make O=<kerneleoutputdir> bzImage make O=<kerneleoutputdir> modules |
| 33 |
>> |
| 34 |
>> You can then install the new kernel and modules as root: |
| 35 |
>> |
| 36 |
>> make O=<kerneleoutputdir> modules_install make O=<kerneleoutputdir> |
| 37 |
>> install |
| 38 |
>> |
| 39 |
>> You need to set the following environment variable: |
| 40 |
>> |
| 41 |
>> KBUILD_OUTPUT=<kerneloutputdir> |
| 42 |
>> |
| 43 |
>> This variable ensures that any emerged app can find the kernel output |
| 44 |
>> if necessary. I've created a script in /etc/profile.d that |
| 45 |
>> automatically keeps this environment variable up to date. Oh, |
| 46 |
>> remember to unset this variable if you do *anything* requiring a |
| 47 |
>> busybox build (eg genkernel). |
| 48 |
>> |
| 49 |
>> An enjoyable side-effect of this system is that when you remove an |
| 50 |
>> obselete kernel from your system using "emerge -C |
| 51 |
>> <oldkernelversion>", everything will be removed because there are no |
| 52 |
>> changes, no files added to those portage added kernel directory. |
| 53 |
>> |
| 54 |
>> The kernel builder user does nothing but build new kernels. This |
| 55 |
>> user's home directory is a hierarchy containing current kernel |
| 56 |
>> builds. |
| 57 |
>> |
| 58 |
>> I've been using this system for years now, on all my gentoo systems. |
| 59 |
>> It is second nature. Of course, the .bash_history of the kernel |
| 60 |
>> builder user is *very* useful for quickly doing all this from the |
| 61 |
>> command line. |
| 62 |
>> |
| 63 |
>> I used to have a script to automate all this, but it is just as easy |
| 64 |
>> to do from the command line. |
| 65 |
> |
| 66 |
> What is the benefit of this approach vis a vis su to root first as the |
| 67 |
> gentoo handbook suggests? |
| 68 |
|
| 69 |
You've answered your own question. I'm of the opinion that it is far |
| 70 |
better to do the absolute *minimum* commands as the superuser, for your |
| 71 |
own system security. My way of compiling a new kernel means that only |
| 72 |
the "install" commands are done as superuser. |
| 73 |
|
| 74 |
-- |
| 75 |
Regards, |
| 76 |
Gregory. |
Archives