# [S]Kernel ohne genkernel kompilieren?

## Tinitus

Hallo,

wie bekomme ich möglichst schmerzfrei einen Wechsel zu einem selbstgebauten Kernel hin.

Meine -zwar mit genkernel erstellte- config ist schon auf das Nötigste beschränkt. Aber einfach wechseln hat doch nicht geklappt.

Wie kriege ich das dennoch hin?Last edited by Tinitus on Thu Sep 13, 2012 10:54 am; edited 1 time in total

----------

## Christian99

Hiermit für die allgemeinen Einstellungen, und hiermit für die Treiber.

Weitere Fragen darüber hinaus natürlich im Forum  :Smile: 

Viel Erfolg!

----------

## Tinitus

Hallo,

ich wollte eigentlich die config Datei unter etc/Kernels ins Kernel Verzeichnis unter .config speichern.

dann ein make oldconfig

make

make modules_install

dann bzImage und System.map nach /boot

Aber dann bootet der Rechner nicht.

Was ist mit der initrd? Ich wollte gerne darauf verzichten.

Wie muß ich dann meine menu.lst anpassen? Die sieht jetzt so aus.

```
title Gentoo Linux 3.5.3-gentoo

root (hd0,0)

kernel /boot/kernel-genkernel-x86_64-3.5.3-gentoo real_root=/dev/sda8

initrd /boot/initramfs-genkernel-x86_64-3.5.3-gentoo
```

Edit:

habe jetzt noch einen heise Artikel gefunden: http://www.heise.de/open/artikel/Linux-Kernel-massgeschneidert-1402386.html

also statt oldconfig make localmodconfig

Aber geht das dann auch ohne initrd gleich?

Wie änder ich die menu.lst

----------

## Christian99

naja, also auf initrd kannst du auf jeden fall verzichten. Dafür gibt es aber ein paar Dinge zu beachten. ZB Dateisystemtreiber und Festplattengerätetreiber fest (nicht als Modul) in den Kernel einkompilieren. Die genkernel config macht das eventuell nur als Module.

Was sonst noch essentiel ist stand glaube ich auf der kernelseeds seite. Es ist zwar für das erstemal einiges zum durcharbeiten, aber danach kann man für neue kernel oldconfig machen. Außerdem wirst du vermutlich nicht alle Treiber wollen die genkernel baut, sondern nur die die du brauchst.

In der menu.lst musst du nur die initrd zeile entfernen und "real_root=" in "root=" ändern, glaub ich.

----------

## Schorchgrinder

Der Christian99 hat es schon richtig angesprochen, man muss ohne Kernel einige Module fest einkompilieren 

```
    Symbol: BLK_DEV_INITRD [=n]                                                                                                                                        │  

  │ Type  : boolean                                                                                                                                                    │  

  │ Prompt: Initial RAM filesystem and RAM disk (initramfs/initrd) support                                                                                             │  

  │   Defined at init/Kconfig:1093                                                                                                                                     │  

  │   Depends on: BROKEN [=n] || !FRV                                                                                                                                  │  

  │   Location:                                                                                                                                                        │  

  │     -> General setup
```

habe ich zb au,s weil es da Probleme gab, ich nutze allerdings schon langen Genkernel nicht mehr.

Du solltest auch mal per lsmod schauen was der genkernel-kernel so läd und das dann fest einbinden.

Wenn der Kernel boote kann man ja versuchen Stück für Stück zu testen was er braucht.

bei menu.lst braucht man keinen initrd Eintrag mehr

----------

## Yamakuzure

Was stimmt denn mit der offiziellen Anleitung nicht? ("Manuell" und "per genkernel" sind zweich komplett unterschiedliche Paar Schuhe!)

----------

## Gentoo-kid

Ich wuerde die .config  in  

```
  /src/dein_Kernel/   
```

  kopieren und make menuconfig ausfuehren.

Dann hast du eine Beschreibung fuer die neu dazugekommenen Einstellungen, die du bei make oldconfig nicht hast.

----------

## Christian99

doch, die beschreibung hast du auch bei oldconfig. wenn du nach was gefragt wirst, kannst du "?" eintippen, und dann kommt die selbe beschreibung wie in der menuconfig umgebung.

----------

## platinumviper

 *Yamakuzure wrote:*   

> Was stimmt denn mit der offiziellen Anleitung nicht? ("Manuell" und "per genkernel" sind zweich komplett unterschiedliche Paar Schuhe!)

 

An der Anleitung ist nicht viel auszusetzen, wenn man einen 2.2 oder noch älteren Kernel bauen will.

Die Anleitung ist kompletter Schrott und gehört in die Tonne. Die Autoren der Anleitung haben offensichtlich noch nie in diesem Jahrhundert die README gelesen und lesen auch nicht die Mailing List.

 *README wrote:*   

> If you install the full sources, put the kernel tarball in a
> 
> directory where you have permissions (eg. your home directory) and

 

 *README wrote:*   

> Do NOT use the /usr/src/linux area!

 

 *README wrote:*   

> To do the actual install, you have to be root, but none of the normal
> 
>    build should require that. Don't take the name of root in vain.

 

Die obigen Zitate stehen seit Version 2.4.0 in jeder Kernel-README, gültig waren sie aber schon früher. Es gab scheinbare Fehler im Kernel, die nur dann auftraten, wenn er durch "root" kompiliert wurde, bei den Entwicklern war so ein Fehler natürlich nicht reproduzierbar, keiner von denen kompiliert den Kernel mit dem root-Account.

----------

## platinumviper

Ich fange bei einem neuen Rechner immer mit "make defconfig" an und passe den Kernel anschließend mit "make menuconfig" an. Das dauert bei mir knapp 30 Minuten, da Du Anfänger bist, wirst du viel mehr Hilfstexte lesen müssen, wirst also mindestens ein bis zwei Stunden brauchen. Lohnt sich aber, man erfährt viel und später geht es auch sehr viel schneller. Die Hilfstexte sind eine große Hilfe, solltest Du unbedingt lesen.

Bevor Du anfängst einen eigenen Kernel zu bauen, solltest Du die README lesen. 

```
vi /lib/modules/`uname -r`/source/README
```

Eine weitere gute Quelle ist das Buch "Linux Kernel in a Nutshell" von Greg Kroah-Hartman, dem Verwalter des Stable-Zweigs des Kernels. Das Buch ist zwar schon ein paar Jahre alt, aber da sich am Build-Prozess nichts wesentliches geändert hat, ist es noch topaktuell. Das Buch kannst Du mit "emerge linux-kernel-in-a-nutshell" downloaden oder im Buchhandel kaufen. Was Du zu diesem Thema im Internet findest, ist zu 99% völlig veraltet und unbrauchbar.

----------

## schmidicom

@platinumviper

Der Kernel wird von emerge ja auch nicht in /user/src/linux abgelegt sondern daneben, /usr/src/linux ist nur ein symlink ohne den wohl einiges schief laufen würde.

Und das man diesen nicht unter root kompilieren soll empfinde ich als schlechter scherz seitens der Devs. Das erstellen eines Kernels ist die Aufgabe des Systemadministrator also hat das einfach zu funktionieren.

----------

## mv

 *schmidicom wrote:*   

> Und das man diesen nicht unter root kompilieren soll empfinde ich als schlechter scherz seitens der Devs.

 

Überhaupt nicht. Die Aufgabe ist viel zu komplex für root. Mehr als das was unbedingt unter root passieren muss - also das Kopieren der Files - sollte man auch nicht unter root machen. Dass die Notwendigkeit, unter root nichts Komplexes zu tun, von einigen Leuten nicht verstanden wurde (namentlich *kit-Enwickler...), ist keine Entschuldigung für eigenes Fehlverhalten.

----------

## schmidicom

Dann wünsche ich euch viel vergnügen beim versuch ohne root den von emerge heruntergeladenen und unter /usr/src/ abgelgten Kernel zu kompilieren.

Ich würde mal anhand der von emerge verteilten Dateirechten sagen das vermutlich nicht einmal "make menuconfig" ohne root funktionieren wird.

EDIT:

Habe mir grade das offizielle Tar-File von www.kernel.org angesehen und dort drin ist auch root die user und group id aller Dateien mit den Rechten rwxrwxr-x

----------

## Tinitus

Hallo,

ich habe es mal mit localmodeconfig versucht. Das hat geklappt.

Da meine verzeichnisse über mehrere Partitionen verteilt sind brauchte ich doch noch eine initrd. Deshalb konnte ich auch die Einträge in der menu.lst belassen.

Danke für die vielen Antworten (auch zum Thema;-)).

----------

## fndark

Hi,

@ alle betreffent kernel bauen mit userrechten

die sourcen bauen wenn se mit emerge runtergeladen wurden funktioniert mit userrechten in soweit das ein wechsel nach /usr/src/linux und ein make nconfig funktioniert, würde man also die dateiberechtigungen ändern sollte auch mit userrechten das kernelbauen funzten, berichtigt mich wenn es an noch etwas anderem scheitern sollte? will ja auch bissl was lernen  :Wink: 

somit sollte doch das kernel bauen funzten wenn man ein packet von kernel.org runterladet und mit normalem user baut!????

werds dann gleichmal probieren  :Smile: 

grüsse ....

----------

## forrestfunk81

Hab mir die Sourcen jetzt nicht angesehen, aber iirc hat ein normaler User in /usr/src/linux* keine Schreibrechte, kann also auch das Ergebnis / den kompilierten Kernel nicht in die Unterverzeichnisse schreiben. Es ist auch gut so, dass normale User dort keine Schreibrechte haben, sonst könnte ein böser User die Kernel Sourcen austauschen oder modifizieren.

----------

## Yamakuzure

```
sed@sed-notebook ~ $ cd /usr/src/linux

sed@sed-notebook /usr/src/linux $ make menuconfig

*** Unable to find the ncurses libraries or the

*** required header files.

*** 'make menuconfig' requires the ncurses libraries.

***

*** Install ncurses (ncurses-devel) and try again. 

*** 

make[1]: *** [scripts/kconfig/dochecklxdialog] Fehler 1

make: *** [menuconfig] Fehler 2
```

Ich hab aber schon eine config... moment...

```
sed@sed-notebook /usr/src/linux $ make

scripts/kconfig/conf --silentoldconfig Kconfig

*** Error during update of the configuration.

make[2]: *** [silentoldconfig] Fehler 1

make[1]: *** [silentoldconfig] Fehler 2

make[1]: Für das Ziel »all« ist nichts zu tun.

make[1]: Für das Ziel »relocs« ist nichts zu tun.

make: *** Keine Regel vorhanden, um das Target »include/config/auto.conf«, 

  benötigt von »include/config/kernel.release«, zu erstellen.  Schluss.
```

Also "Bauen muss als user geschehen!" ist schlicht quatsch. Aber davon einmal abgesehen, dass es so unter /usr/src/linux eh nicht geht, habe ich noch nie seit kernel-2.4 einen kernel nicht als root gebaut, und noch nie irgendwelche Probleme damit gehabt. *Kernel README wrote:*   

> To do the actual install you have to be root, but none of the normal
> 
>    build should require that. Don't take the name of root in vain.

 Das heißt nur, dass man nicht root sein muss um die sourcen zu bauen, für die Installation aber schon. Wichtig ist dieser Absatz nur für jeden, der sich die Quelltexte selber herunterlädt und in seinem Home-Verzeichnis bauen will. *http://kernelnewbies.org/FAQ/KernelCompilation wrote:*   

> Become root to be able to install modules and kernel. Everything before this point can and should be done as a normal user, there is really no need to be root to compile a kernel. It's actually a very bad idea to do everything as root because root is too powerful, one single mistake is enough to ruin your system completely.

 Nur um, falls das sonst jemand zitieren will, zu verdeutlichen. Der Text besagt, dass es nicht notwendig ist, den Kernel als "root" zu kompilieren. Und dass es generell keine gute Idee ist, alles als root zu tun. Letzteres ist eine Anspielung auf den "Administrator" unter Windows. Sonst nichts. Es bedeutet nicht, dass etwas schlimmes passiert, wenn man als root "make" im kernel-Verzeichnis eingibt. *http://debian-handbook.info/browse/stable/sect.kernel-compilation.html wrote:*   

> Traditionally, Linux kernel sources would be placed in /usr/src/linux/ thus requiring root permissions for compilation. 

 Also Fazit: Es ist durchaus möglich, und sogar wünschenswert den kernel als regulärer Benutzer zu bauen. Das geht aber _nur_ wenn man die Quellen von /usr/src/linux woanders hin kopiert, wo man als nicht-root auch bauen darf. Wer dem letzten Link folgt, wird sehen, das Debian das zum Beispiel auch dringend rädt.

Dieses zu tun bedeutet sogar einen besonderen Vorteil: Man muss nach einem Update die Leichenteile nicht von Hand löschen.  :Wink: 

----------

## mv

 *schmidicom wrote:*   

> Dann wünsche ich euch viel vergnügen beim versuch ohne root den von emerge heruntergeladenen und unter /usr/src/ abgelgten Kernel zu kompilieren.

 

Dafür setzt man die KBUILD_OUTPUT Environment-Variable (in der systemweiten Environment) auf ein Directory, des beispielsweise portage gehört. Um das Compilieren dann automatisch unter User "portage" laufen zu lassen (und dabei ggf. ccache zu benutzen) und trotzdem als root zu installieren, kannst Du beispielsweise das "kernel"-Script aus dem mv-Overlay benutzen.

----------

## toralf

Hhm, also ich nutze nur noch den git tree der kernel sourcen (Linus Torvald + stable tree im selben Repository). Dann reicht ein 

```
make -j5 && sudo su -c "mount /boot/; make install && make modules_install"

```

i.d.R. aus. Einmalig etwas in dieser Art 

```
tfoerste@n22 ~ $ cat /etc/portage/profile/package.provided

sys-kernel/vanilla-sources-3.4.10

sys-kernel/vanilla-sources-3.5.3

```

zurechtgeschustert , um portage zu beruhigen, und dem eigenen - stets aktuellen - (stable) Kernel steht nix mehr Wege,.

----------

## platinumviper

 *schmidicom wrote:*   

> @platinumviper
> 
> Der Kernel wird von emerge ja auch nicht in /user/src/linux abgelegt sondern daneben, /usr/src/linux ist nur ein symlink ohne den wohl einiges schief laufen würde.
> 
> Und das man diesen nicht unter root kompilieren soll empfinde ich als schlechter scherz seitens der Devs. Das erstellen eines Kernels ist die Aufgabe des Systemadministrator also hat das einfach zu funktionieren.

 

Du hast die README des Kernels noch nie gelesen, oder?

Lies dir mal die zweite Seite dieser Datei http://files.kroah.com/lkn/lkn_pdf/ch01.pdf durch, einschließlich Fußnote.

Ob /usr/src/linux ein Verzeichnis oder ein Link auf ein Verzeichnis ist spielt keine Rolle, der aktuelle Kernel hat dort nichts zu suchen. Das Verzeichnis enthielt früher einmal den Kernel, da einige systemnahe Programme die Header-Files brauchen. Da es zu Problemen führen kann, wenn sich die Header-Files ändern, ohne dass die davon abhängigen Programme neu kompiliert werden, werden bei allen mir bekannten Distributionen die Header entweder in /usr/src/linux untergebracht und entsprechende Links in /usr/include gesetzt oder (wie bei Gentoo) direkt in /usr/include gespeichert. Als Gentoo User kannst und solltest du den Link ersatzlos löschen um Probleme zu vermeiden. Enige Programme, z.B. ältere nVidia Treiber, suchen den Kernel erst in /usr/src/linux und erst dann an der korrekten Stelle /lib/modules/"Kernel-Version"/source bzw /lib/modules/"Kernel-Version"/build und kompilieren dann für eine falsche Kernel-Version.

Also immer "make menuconfig" oder xconfeg/gconfig/nconfig und "make -j<CPU-cores*2> all" als normaler User und nur "make modules_install install" als root.

Falls debianutils installiert ist und du kein eigenes ~/bin/installkernel hast und LILO als loader nutzt, muss noch ein "sudo lilo" folgen.

----------

## platinumviper

 *mv wrote:*   

> Um das Compilieren dann automatisch unter User "portage" laufen zu lassen (und dabei ggf. ccache zu benutzen) und trotzdem als root zu installieren, kannst Du beispielsweise das "kernel"-Script aus dem mv-Overlay benutzen.

 

Sieht gut aus, aber warum hast du für "Normal-User" ccache defaultmäßig deaktiviert? Gerade die profitieren doch besonders davon, da sie nicht alle Nase lang irgendwas kompilieren, sondern sich auf wenige eigene Programme und den Kernel beschränken.

----------

## mv

 *platinumviper wrote:*   

> Sieht gut aus, aber warum hast du für "Normal-User" ccache defaultmäßig deaktiviert?

 

Der "Kernel-Compilierer" für das Script ist portage; und portage hat i.d.R. kein permanentes $HOME, in dem man solche Settings macht. Das ccache-Verzeichnis von portage muss i.d.R. aus /etc/portage/make.conf ausgelesen werden, weil es normalerweise nicht ~/.ccache ist.

Außerdem sollte man auch als Normal-User immer mit einem Script compilieren, in dem CCACHE_BASEDIR auf das Projekt-Directory gelegt wird, weil man dann beim Verschieben/Umbenennen dieses Directories nicht den ccache verliert. Dann kann man in dem Script auch gleich den Rest von ccache aktivieren...

----------

## toralf

 *platinumviper wrote:*   

> Ob /usr/src/linux ein Verzeichnis oder ein Link auf ein Verzeichnis ist spielt keine Rolle, der aktuelle Kernel hat dort nichts zu suchen

 Sag das doch mal den Gentoo devs  :Smile: 

----------

## Yamakuzure

Was hat denn dann dort etwas zu suchen? Die kernel-header sind schon in /usr/include/linux. Was soll also in /usr/src/linux? Ich habe jedenfalls noch kein System gesehen, dass ein Problem damit hatte, dass der aktuelle Quellbaum dort rumschnoddert. Bemerke die Namen der Verzeichnisse:/usr/src/linux - Sourcen aka "Quellen"/usr/include/linux - Includes aka "Headerdateien".

Ich habe gerade diesen Artikel von 2001 gefunden. Hier votieren Kernel-Entwickler gegen /usr/src/linux, weil zu diesem Zeitpunkt (vor 11 Jahren) symlinks von /usr/include/linux/ in /usr/src/linux/include existierten. Das bedeutete natürlich, dass das Wechseln des Kernels ein Problem für alles, was ein "#include <linux/...>" enthielt, war.

Da /usr/include/linux heutzutage aber autark ist (ich kann zumindest keine symbolischen Verknüpfungen mehr finden), sollte diese Gefahr wohl mitlerweile irrelevant sein.

----------

## platinumviper

 *toralf wrote:*   

>  *platinumviper wrote:*   Ob /usr/src/linux ein Verzeichnis oder ein Link auf ein Verzeichnis ist spielt keine Rolle, der aktuelle Kernel hat dort nichts zu suchen Sag das doch mal den Gentoo devs 

 

Völlig aussichtslos, ich weiß   :Laughing: 

----------

## platinumviper

 *Tinitus wrote:*   

> Hallo,
> 
> ich habe es mal mit localmodeconfig versucht. Das hat geklappt.
> 
> Da meine verzeichnisse über mehrere Partitionen verteilt sind brauchte ich doch noch eine initrd. Deshalb konnte ich auch die Einträge in der menu.lst belassen.

 

Wenn die verwendeten Filesysteme fest einkompiliert sind, sollte eigentlich keine RAM-Disk nötig sein. Aber schön, das es geklappt hat. Jetzt ist eine gute Gelegenheit eine boot-fähige CD zu erzeugen: "make FDINITRD=/Pfad/zu/deiner/RAM-Disk isoimage", damit kannst du unter Umgehung des Boot-Managers direkt booten. Es soll ja bösartige Betriebssysteme geben, die als allererstes den Bootmanager massakrieren.  :Wink: 

----------

## schmidicom

Nun platinumviper ich habe es jetzt mal testweise so gemacht wie du das vorschlägst und siehe da schon das erste Paket das mit dieser Vorgehensweise offensichtlich nicht ganz einverstanden ist:

```
>>> Emerging (5 of 7) www-client/chromium-23.0.1271.10-r1

 * Fetching files in the background. To view fetch progress, run

 * `tail -f /var/log/emerge-fetch.log` in another terminal.

 * chromium-23.0.1271.10.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                            [ ok ]

 * Determining the location of the kernel source code

 * Unable to find kernel sources at /usr/src/linux

 * Please make sure that /usr/src/linux points at your running kernel, 

 * (or the kernel you wish to build against).

 * Alternatively, set the KERNEL_DIR environment variable to the kernel sources location

 * Unable to calculate Linux Kernel version for build, attempting to use running version

 * Found kernel object directory:

 *     /home/schmidicom/Downloads/linux-3.5.4

 * Found sources for kernel version:

 *     3.5.4

 * Checking for suitable kernel configuration options...                                                                                                         [ ok ]

 * bindist disabled: Resulting binaries may not be legal to re-distribute.
```

Es hat den Kernel letzten Endes zwar doch gefunden aber gemerkt wurde trotzdem.

----------

## mv

 *schmidicom wrote:*   

> 
> 
> ```
>  * Alternatively, set the KERNEL_DIR environment variable to the kernel sources location
> ```
> ...

 

Warum tust Du das nicht?

----------

## schmidicom

 *mv wrote:*   

>  *schmidicom wrote:*   
> 
> ```
>  * Alternatively, set the KERNEL_DIR environment variable to the kernel sources location
> ```
> ...

 

Weil es nicht nötig sein sollte?

----------

## mv

 *schmidicom wrote:*   

> Weil es nicht nötig sein sollte?

 

Selbstverständlich ist es nötig: Ebuilds, die kernel-Module bauen oder Details der Kernel-Version oder -Konfiguration übrprüfen, müssen das Kernel-Directory kennen. Der Name dieses Directories sollte auch die Hauptversionsnummer beinhalten.

----------

## schmidicom

 *mv wrote:*   

>  *schmidicom wrote:*   Weil es nicht nötig sein sollte? 
> 
> Selbstverständlich ist es nötig: Ebuilds, die kernel-Module bauen oder Details der Kernel-Version oder -Konfiguration übrprüfen, müssen das Kernel-Directory kennen. Der Name dieses Directories sollte auch die Hauptversionsnummer beinhalten.

 

Ich dachte genau dafür wären die beiden symlinks da die von "make modules_install" im dem Verzeichnis angelegt werden wo auch die Module liegen.

----------

## platinumviper

Wenn du mit dem neuen Kernel gebootet hast ist alles OK, dann reichen die Symlinks. Wenn du vor dem booten noch etwas kompilieren musst, z.B. nvidia-drivers, dann zeigt /lib/modules/`uname -r`/source auf die Sourcen des aktuellen Kernels und nicht auf die Sourcen des neuen Kernels, für den du eigentlich kompilieren willst. In dem Fall brauchst du die Variable $KERNEL_DIR. Ich habe beide in /etc/profile stehen.

----------

## bell

Normalerweise gehen alle Ebuilds auf den Symlink /usr/src/linux der auf den Kernel gesetzt sein sollte. KERNEL_DIR braucht man nur wenn man seinen kernel wo anders hat. *Quote:*   

>  * Unable to find kernel sources at /usr/src/linux
> 
>  * Please make sure that /usr/src/linux points at your running kernel, 

 

Also setze mal den Symlink sauber

```
eselect kernel list

eselect kernel set ..
```

----------

## mv

 *bell wrote:*   

> Normalerweise gehen alle Ebuilds auf den Symlink /usr/src/linux der auf den Kernel gesetzt sein sollte.

 

Es ging in dem Thread darum, dass die Existenz dieses Symlinks nicht unbedingt eine gute Idee ist, und z.B. von Kernel-Upstream explizit davon abgeraten wird.

Vor allem, wenn man selbst Ebuilds schreibt oder Sachen installiert, die nicht im Gentoo-Baum sind, will man zur Kontrolle gerne sicher stellen, dass diese nicht "hart" von /usr/src/linux abhängen.

----------

## bell

Naja, wenn man LFS fährt, dann kann man selbst entscheiden wo der Kernel liegt und auch die Empfehlung befolgen nur als User zu kompilieren. In Gentoo ist es jedoch anders vorgesehen.

Wenn Du eigene Ebuilds schreibst, so solltest Du auch das linux-mod.eclass nutzen. Dort wird das KERNEL_DIR verwaltet.

----------

## mv

 *bell wrote:*   

> In Gentoo ist es jedoch anders vorgesehen.

 

KBUILD_OUTPUT wird von Gentoo vollkommen unterstützt.

----------

## bell

Gut zu wissen. Danke mv. Ich habe KBUILD_OUTPUT noch in keiner einzigen Dokumentation / Howto gesehen. Daher ist die "Standard"-Vorgehensweise für mich als root im /usr/src zu kompilieren. Die Systemwartung sehe ich auch als eine Aufgabe von "root". Daher passt es. Aber gut zu wissen dass es eine Möglichkeit gibt als normaler User einen Kernel zu kompilieren, der als "root:root" auf der Platte liegt.

----------

