# Kernel update

## JoHo42

Hi Leute,

ich habe mir einen eigenen Kernel vor zwei Jahren gebaut. Dieser läuft ganz gut und mit der Zeit habe ich den immer weiter auf mein System angepasst.

Dabei ist der Kernel auch schoen klein geworden.

Jetzt wuerde ich den ganz gerne updaten. Allerdings wie kann ich meine Kernel .config am besten auf einen neuen Kernel uebernehmen?

Ich kenne das Kommando make oldconfig allerdings macht der dann alles was als Modul war fest in den Kernel.

Und irgendwie sind dann immer Sachen aktiviert die ich nicht brauche.

Wie kann ich meine jetzige config so uebernehmen das alles wie im alten aktiviert ist und das was ich nicht aktivert hatte auch aus ist.

Also das ich den neuen Kernel habe der aber genauso ist von der Konfig her wie mein alter.

Gruss Joerg

----------

## Christian99

hi, ich verwende eigentlich immer oldconfig und schau dann nochmal kurz drüber, ob irgendwas anders ist als ich möchte.

dass module dann fest einkompiliert werden, stimmt nicht. Meine Module bleiben module.

Christian

----------

## Randy Andy

Juhu JoHo42

 *Quote:*   

> Ich kenne das Kommando make oldconfig allerdings macht der dann alles was als Modul war fest in den Kernel.
> 
> Und irgendwie sind dann immer Sachen aktiviert die ich nicht brauche.

 

Nö, macht er nicht, vermutlich machst du da was falsch...

 *Quote:*   

> Wie kann ich meine jetzige config so uebernehmen das alles wie im alten aktiviert ist und das was ich nicht aktivert hatte auch aus ist.

 

Mit make oldconfig, aber folgendes ist zu beachten:

- Zuerst mal den Symlink auf die neue, bzw. die kernelversion setzen die du erstellen möchtest, z.B. mit eselect kernel list zum prüfen, und dann mit eselect kernel set Nr. diesen auswählen.

- Dann deine alte kernel config Datei von dort wo du sie abgelegt hast, standard wäre /usr/src/linux-deine-letzte-laufende-Version nach /usr/src/linux kopieren, oder mit:

zcat /proc/config.gz > /usr/src/linux/.config die laufende kernel Konfiguration dorthin kopieren, geht aber nur wenn die entsprechende Option im kernel aktiviert ist.

- Dann nach cd /usr/src/linux wechseln und make oldconfig ausführen. Dann werden dir vermutlich einige Fragen gestellt über die neu hinzu gekommenen Optionen, die du entsprechend deinen Wünschen beantworten musst. ? zeigt dir dabei die Hilfstexte an, Enter würde dagegen die jeweilige großgeschriebene (Y,n,m,?)Standardeinstellung selektieren, hier also Y.

Nicht vorhersagbar für mich, ist die von mir häufig gelesene Aussage dass wenn der Abstand der kernelversionen zu groß ist, oldconfig die zu großen Unterschiede nicht mehr Anpassen kann, dann soll man angeblich händisch in menuconfig oder xconfig die gewünschten Einstellungen setzten müssen, aber wer weiss. Versuch macht Klug.

Zu beachten ist, das oldconfig sich die .config datei schnappt, also auch wenn eine zweite config ohne Punkt daneben befindet. Auch reden wir hier nicht über genkernel, denn dieser entnimmt standardmäßig seine letzte config aus /etc/kernels und schert sich nen Teufel um die .config in /usr/src/linux, es sei denn man übergibt diese beim Aufruf.

Falls du's also anders gemacht hast, könnten darin die Ursachen liegen.

----------

## JoHo42

Hi,

genauso habe ich das heute nochmal Probiert.

Folgende Schritte

- eselect kernel set 8

- modprobe configs

- cd /usr/src/linux

- make oldconfig

und dann fast alles mit N beantwortet, trotzdem hat der Kernel wieder keine Module.

Ich möchte von Version 2.6.31 nach 2.6.34 springen.

Gruss jörg

----------

## Randy Andy

JoHo42,

also nicht so wie ich es dir empfohlen habe, denn von modprobe configs habe ich weder etwas geschrieben, noch bis dato gehört.

Hab mal ein wenig recherchiert, und das mag es ja mal gegeben haben, findet aber imho in aktuellen dokumentation oder im Queltext keine Verwendung.

Deshalb, weglassen, so versuchen wie ich es schrieb, aber vermutlich ist der Sprung zwischen Version 2.6.31 nach 2.6.34 auch viel zu groß, und du wirst über --menuconfig oder --xconfig gehen müssen.

War deine alte .config überhaupt von hand (also von dir) optimiert, oder verwendest du'n genkernel?

Ach was red ich, lies am bersten erstmal das, damit du weisst was ich meine:

http://www.gentoo.org/doc/de/kernel-upgrade.xml

Und dann schau'mer mal.

Andy.

----------

## musv

 *JoHo42 wrote:*   

> Hi,
> 
> genauso habe ich das heute nochmal Probiert.
> 
> Folgende Schritte
> ...

 

Öhm, wie auch immer. Probier mal das hier:

Beispiel Deines /usr/src-Verzeichnis

linux = link auf linux-2.6.31

linux-2.6.31 = alter Kernel

linux-2.6.34 = neuer Kernel

```
cd /usr/src

cp linux-2.6.31/.config linux-2.6.34/

cd linux-2.6.34

make oldconfig
```

Danach setzt du noch den linux-Link auf den aktuellen Kernel und kopierst das Image aus /arch/x86_64/boot/bzImage nach /boot.

Wozu man da ein Eselect oder ein modprobe braucht, ist mir schleierhaft.

----------

## Randy Andy

Genau musv,

das mit dem - modprobe configs war mir auch Schleierhaft, aber zu dem eselect könnt ich dir ja was sagen...

Ist halt schön komfortabel, um die symlinks umzusetzten, sach bloß du kennst das nicht, oder willst du's nicht, weil du Purist bist?

Also, das geht so.

```

eselect kernel list                     # zeigt alle installierten kernelquellen an, das * markiert den aktiven, auf den der symlink zeigt.

Available kernel symlink targets:

  [1]   linux-2.6.35-gentoo-r9

  [2]   linux-2.6.35-gentoo-r10

  [3]   linux-2.6.36-gentoo *

```

und mit eselect kernel set x würde man auf einen anderen wechseln

x = 1, 2, oder 3 im obigen Beispiel. Dann nochmal zur kontrolle eselect kernel list  und man sieht das Ergebnis.

Ansonsten sach ich nur ++1   :Wink: 

----------

## musv

 *Randy Andy wrote:*   

> [eselect]  Ist halt schön komfortabel, um die symlinks umzusetzten, sach bloß du kennst das nicht

 

Ich hab schon mal was davon gehört. Allerdings gab's das 2002, als ich mit Gentoo angefangen hab, noch nicht. Und die Macht der Gewohnheit treibt mich halt zur manuellen Methode.

Davon mal abgesehen:

eselect kernel set [x] oder ln -s linux-2.6.xx-rx linux

Wie hoch ist da jetzt der tatsächliche Bequemlichkeitsgewinn?

----------

## Randy Andy

Gut, wenn du nur diese eien Zeile vergleichst müsste ich dir schon recht geben.

Aber eselect tut ja mehr für dich, denn du siehst dabei ja auf den ersten Blick auf welche quellen der link zeigt, 

wieviele Quellen incl. der Versionen noch auf deinem System installiert sind.

Die syntax hat man, wenn man es öfer nutzt ja eh verinnerlicht, z.B. zum wecheln von

OpenGL; Gcc, vdr-plugins, profiles, vim-unterstützungen etc. etc.

Ich möcht's nicht mehr missen.  :Wink: 

----------

## musv

 *Randy Andy wrote:*   

> Aber eselect tut ja mehr für dich, denn du siehst dabei ja auf den ersten Blick auf welche quellen der link zeigt, 
> 
> wieviele Quellen incl. der Versionen noch auf deinem System installiert sind.

 

Nun ja:

la /usr/src vs. eselect kernel list

 *Randy Andy wrote:*   

> Die syntax hat man, wenn man es öfer nutzt ja eh verinnerlicht, z.B. zum wecheln von
> 
> OpenGL; Gcc, vdr-plugins, profiles, vim-unterstützungen etc. etc.

 

Ja, ich sag ja gar nichts gegen eselect. Es ist ein schönes Tool, um bei Gentoo viele Sachen leicht zu konfigurieren. Ich zeig Dir aber mal einen Punkt, der mich daran stört:

Nehmen wir mal eselect gcc. Wie würdest du die GCC-Version manuell setzen? Ich weiß es nicht. Vermutlich wird nur irgendwo ein Link auf /usr/lib/gcc/$arch/$version/irgendwas gesetzt. Was machst du, wenn du mal an einem Suse, Redhat, Debian oder vielleicht sogar einem LFS sitzt und eine andere GCC-Version brauchst?

Ich hab mal etwas mir Arch rumgespielt. Da ich da keine Kernel-Sourcen gefunden hab (wollten die proprietären VMWare-Tools haben), dacht ich mir, ich könnt ja mal einfach den Standard-Vanilla-Kernel installieren. Also Sourcen runtergeladen, konfiguriert, Image nach /boot kopiert, in den Grub eingetragen und neu gestartet. Hat wunderbar geklappt. Probleme hab ich dann bekommen, wenn irgendein Paket erst ab einer bestimmten Kernelversion lauffähig ist und beim Installieren, die Kernelversion als Abhängigkeitsprüfung (nennt sich kernel26) drin hat. Ich hab's ums Verrecken nicht hinbekommen, den manuell installierten Kernel diesen Paketen schmackhaft zu machen. Ich hab alles pacman-spezifische "durchgegreppt", Wikis durchsucht, Google befragt. Schlussendlich hab ich den Standardkernel wieder installiert.

Fazit:

Kleine Helferlein wie eselect sind klasse. Allerdings "vernichten" sie damit eine ganze Menge Linux-Grundlagenwissen, was man schmerzhaft feststellen darf, wenn man mal mit einer anderen Distri zu tun hat.

PS: In Arch einen anderen Kernel zu installieren, ist der pure Horror. Da braucht man ein überdimensionales Script und muss das Zeug über AUR holen.

----------

## Randy Andy

Das mit dem Grundlagenwissen ist in der Tat ein unschlagbares Argument, auch von meiner Warte.

Andererseits will ich's auch nicht übertreiben, sonst müsste man ja gleich LFS oder Slackware nehmen.

Ansonsten braucht's halt immer ein wenig Distributionsspezifisches Wissen, und da finde ich Gentoo's Ansatz zwischen manueller totaler Kontrolle, gepaart mit bestmöglichem Komfort, ungeschlagen.

Das mit dem GCC weiss ich, weil ich's schon ein par mal machen musste, bevor's dafür 'ne eselct Unterstützung gab.

gcc-config -l  #zum listen und 

gcc-config i686-pc-linux-gnu-Versionsnummer #zum setzen der gewünschten Version.

Gruß, Andy

----------

## mv

 *musv wrote:*   

> Nehmen wir mal eselect gcc. Wie würdest du die GCC-Version manuell setzen? Ich weiß es nicht. Vermutlich wird nur irgendwo ein Link auf /usr/lib/gcc/$arch/$version/irgendwas gesetzt.

 

Erstens gibt es kein eselect gcc: Das heißt gcc-config und ist nicht Teil des eselect-Projekts. Und nein: Es setzt nicht nur einen Link. Es setzt Dutzende von Links und installiert ein passendes Frontend. gcc manuell zu wechseln ist alles andere als einfach. Ähnliches gilt auch für so Dinge wie eselect opengl: Es müssen nicht nur ein paar Links umgesetzt werden, sondern es müssen auch entsprechende Header-Files kopiert werden u.ä. Bei eselect python wird sogar jeweils ein passendes Frontend kompiliert. Normalerweise sind die Dinge, die eselect macht, schon verhältnismäßig komplex. Die Paar Module, die nur einen Link setzen oder ein Environment-Variable verändern, fallen insofern schon etwas aus dem Rahmen.

Bei anderen Distributionen hilft Dir das alles ohnehin wenig, weil gerade die Sachen, die eselect typischerweise macht bei fast jeder Distribution prinzipiell anders gelöst sind: Schon das Setzen von Environment-Variablen, das ja auf den jeweils eigenen Shell-Initscripten basiert muss sich ja vollkommen unterscheiden. Von den distributionseigenen Hacks, die zum Parallelbetrieb von verschiedenen Paketen benutzt werden, die von Upstream nicht zum Parallelbetrieb vorgesehen sind (gcc, python, perl, ruby, kernel, opengl, binutils, blas, lapack, java, etags, usw.) mal ganz zu schweigen...

----------

## musv

 *mv wrote:*   

> Erstens gibt es kein eselect gcc:

 

Ist halt immer schlecht, wenn man grad kein Gentoo zum Probieren zur Verfügung hat. 

Trotzdem vielen Dank. Wieder was gelernt.

----------

