# [solved] Kernel .config "schön" darstellen?

## Ezekeel

Hi,

ich wollte fragen ob es ein tool gibt, bzw. es eine möglichkeit gibt die momentane Kernel .config übersichtlich darzustellen. Mein Problem ist, dass ich ungern make oldconfig verwende und deswegen den Kernel immer von Hand neu baue. Aber selbst nach dem 10ten mal vergesse ich immer wieder was ich in der alten .config aktiviert hatte, dass alles einwandfrei funktioniert, da es schließlich etwas ist, dass ich nicht täglich mache... Natürlich vergesse ich nicht die elementaren sachen sonderen eher unwichtiges, was dennoch nervend ist. Wenn ich nun die alte .config anschaue dann steht da alles ziemlich unübersichtlich so nach dem Stil:

```

CONFIG_NLS_ISO8859_15=y

# CONFIG_NLS_KOI8_R is not set

# CONFIG_NLS_KOI8_U is not set

CONFIG_NLS_UTF8=y

#

# Instrumentation Support

#

CONFIG_PROFILING=y

CONFIG_OPROFILE=y

CONFIG_KPROBES=y

#

# Kernel hacking

#

# CONFIG_PRINTK_TIME is not set

CONFIG_DEBUG_KERNEL=y

CONFIG_MAGIC_SYSRQ=y

CONFIG_LOG_BUF_SHIFT=18

CONFIG_DETECT_SOFTLOCKUP=y

# CONFIG_SCHEDSTATS is not set

# CONFIG_DEBUG_SLAB is not set

# CONFIG_DEBUG_SPINLOCK is not set

# CONFIG_DEBUG_SPINLOCK_SLEEP is not set

# CONFIG_DEBUG_KOBJECT is not set

# CONFIG_DEBUG_INFO is not set

CONFIG_DEBUG_FS=y

# CONFIG_DEBUG_VM is not set

# CONFIG_FRAME_POINTER is not set

# CONFIG_RCU_TORTURE_TEST is not set

CONFIG_INIT_DEBUG=y

# CONFIG_IOMMU_DEBUG is not set

```

Im Forum habe ich schon oft gesehen, dass manche die .config graphisch dargestellt haben mit Ascii art oder auch anders. Am besten wäre es wenn sowieso die Sachen ausgeblendet würden die man nicht aktiviert hat um es handlich auf eine oder mehrere A4 Seiten zu bringen und das ganze mit Subkategorien. 

Ist denn jemandem eine Möglichkeit oder ein Tool bekannt um das zu bewerkstelligen? Das würde das Konfigurieren um ein vielfaches einfacher und schneller machen?!? 

Vielen Dank für eure Antworten!!

----------

## hoschi

Wieso benuetzt du den "make oldconfig" nicht, ich sehe keine rationellen Grund warum man es nicht benuetzen sollte solange im Kernel nicht gleich massive Aenderungen vorkommen, oder gleich ein paar Kernelversionen uebersprungen werden. An deine Vergesslichkeit aendert eine grafisches Frontend aber auch nichts  :Wink: 

Trotzdem wuerde ich auch gerne wissen wie man diese schoenere Config-Auszuege erhaelt  :Very Happy: 

----------

## /dev/blackhawk

Schonmal "make xconfig" oder "make menuconfig" probiert?

Falls Dir das nicht reicht, hab ich evtl. dein Problem falsch verstanden.

MFG

/dev/blackhawk

----------

## hoschi

Ich gehe jetzt mal davon aus, dass er "make menuconfig" verwendet wie die meisten. Per Hand...

Unmenschlich  :Very Happy: 

----------

## Ezekeel

naja ich will die config schön aussehen lassen um sie auszudrucken und dann an Hand des ausdrucks den neuen Kernel konfigurieren... das ist Hintergrund meiner Frage und insofern habe ich meine Vergesslichkeit dann ausgehebelt!  :Smile: 

make manuconfig kenne ich - nur ausdrucken kann man es dann nicht!! 

Ich hätte eben gerne etwas im Stil von

```

|

|---->blabla

           |

           |-----lala on

```

Ich hoffe das war in etwa verständlich mir sind im moment keine typischen Kernelkategorien eingefallen...

----------

## l3u

Aber warum willst du das denn von Hand machen?! Mach halt make oldconfig oder kopier einfach die alte .config ins neue /usr/src/linux ...

----------

## doedel

man kann doch auch die config extra speichern und wieder laden, ich speichers bei mir jedes mal im home verzeichnis unter kernel-[datum]-[evtl_nr_wenn_mehrere_an_einem_tag]

----------

## Ezekeel

 *Quote:*   

> Aber warum willst du das denn von Hand machen?! Mach halt make oldconfig oder kopier einfach die alte .config ins neue /usr/src/linux ...

 

Nun ja ich habe um ehrlich zu sein nicht wirklich viel Ahnung von der Kernelconfig... Wie gesagt es ist etwas das man nicht täglich macht und dabei ist es ein so umfangreiches thema, dass man es nicht in kurzerZeit abhandeln kann. Ergo habe ich mich an das gehalten was in den Manuals stand. Ich kann nun zwar nicht die stelle genau nennen, aber soweit ich mich erinnern kann wurde von einem make oldconfig bedingt abgeraten in besonderm aber dann wenn der Kernel um eine Versionsnummer also von 2.6.15 auf 2.6.16 (in diesem Fall) nach oben geht und nicht nur wie sonst ein neues release rauskommt wie z.B. von 2.6.15-r6 auf 2.6.15-r7 bei denen ich jedesmal make oldconfig der einfachheit halber verwendet habe. 

Ergo habe ich mir diesmal gedacht, dass es keine so gute Idee ist wieder die alte config zu verwenden?!

Davon mal abgesehen fände ich es eben schlicht und ergreifend praktisch das ganze mal auf papier zu haben um im falle eines Systemabsturzes oder was auch immer das ganze auf papier zu haben.

----------

## schachti

 *Ezekeel wrote:*   

> 
> 
> Ergo habe ich mich an das gehalten was in den Manuals stand. Ich kann nun zwar nicht die stelle genau nennen, aber soweit ich mich erinnern kann wurde von einem make oldconfig bedingt abgeraten in besonderm aber dann wenn der Kernel um eine Versionsnummer also von 2.6.15 auf 2.6.16 (in diesem Fall) nach oben geht und nicht nur wie sonst ein neues release rauskommt wie z.B. von 2.6.15-r6 auf 2.6.15-r7 bei denen ich jedesmal make oldconfig der einfachheit halber verwendet habe. 
> 
> 

 

Also ich mache seit 2.6.5 oder so bei jedem neuen Kernel immer make oldconfig, und bisher hat es problemlos funktioniert. Man sollte sich halt bewußt sein, daß theoretisch etwas schiefgehen könnte - das wird man aber schon merken, und dann kann man es immer noch manuell probieren.   :Wink: 

----------

## STiGMaTa_ch

 *schachti wrote:*   

> [...]Man sollte sich halt bewußt sein, daß theoretisch etwas schiefgehen könnte[...]

 

Also das müsst Ihr mir mal genauer erklären was da schief gehen sollte...   :Shocked: 

Oldconfig macht doch nichts anderes als die alten Optionen mit den (eventuell) neuen zu vergleichen. Dabei gibt es dann folgende Situationen:

- In der alten Config gab es eine Option die es nun nicht mehr gibt   :Arrow:  Option wird ignoriert.

Risiko: Da es diese Option nicht mehr gibt, wird die auch nirgends ausgewertet. Ergo, kein Risiko.

- In der neuen config gäbe es Optionen welche es in der alten noch nicht gab  :Arrow:  Du wirst gefragt was gemacht werden soll.

Risiko: Keines. Wenn du mit (?) die Hilfe liest wird dir gesagt welches die Empfehlung ist.

- In beiden stehen selbe Optionen  :Arrow:  Die Werte werden übernommen.

Risiko: Keines.

- In beiden stehen selbe Optionen, allerdings kann man die Option nicht mehr gleich Konfigurieren  :Arrow:  Du wirst gefragt was gemacht werden soll.

Risiko: Entweder wählst du wieder eine ähnliche Option aus wie damals oder hältst dich an die Empfehlung. Ergo, kein Risiko.

Natürlich ist es umständlich, wenn man von Kernel 2.6.1 auf Kernel 2.6.11 umsteigt. Dann bringt oldconfig so viele Fragen, dass man besser die Config neu erstellt. Aber wer lässt schon seinen Kernel so lange auf einer alten Version???

Lieber Gruss

STiGMaTa

----------

## schachti

 *STiGMaTa_ch wrote:*   

> 
> 
> Also das müsst Ihr mir mal genauer erklären was da schief gehen sollte...  
> 
> 

 

Vielleicht eine aus dieser Warnung entstandene urban legend?

 *STiGMaTa_ch wrote:*   

> 
> 
> - In der alten Config gab es eine Option die es nun nicht mehr gibt   Option wird ignoriert.
> 
> Risiko: Da es diese Option nicht mehr gibt, wird die auch nirgends ausgewertet. Ergo, kein Risiko.
> ...

 

Warum kein Risiko? Irgend ein Feature oder eine Option, die für Dein System wichtig war, ist nicht mehr im Kernel, und Du merkst es nicht - erst nach dem Reboot, wenn es vielleicht schon zu spät ist... Irgendwann wird vielleicht der schon seit langem als deprecated markierte Support für cryptoloop aus dem Kernel fliegen, also eine Option einfach verschwinden. Wer das nicht merkt und / mit cryptoloop verschlüsselt hat, kommt dann nicht mehr ohne weiteres an sein System, wenn er den alten Kernel einfach gelöscht hat.

----------

## /dev/blackhawk

Einen alten Kernel einfach zu löschen, bevor der neue getestet wurde, ist aber auch grob fahrlässig. Außerdem besteht ja immer die Möglichkeit nochmal die alten Source zu holen und einfach den Kernel mit einer bekannten config neu zu übersetzten. Wenns sein muss auch auf einem anderen PC. (Und wer jetzt sagt, er hat kein Backup von config.... ist IMHO selber schuld  :Wink: )

MFG

/dev/blackhawk

----------

## STiGMaTa_ch

Hallo Schachti

 *schachti wrote:*   

>  *STiGMaTa_ch wrote:*   
> 
> Also das müsst Ihr mir mal genauer erklären was da schief gehen sollte...  
> 
>  
> ...

 

Eher eine Missinterpretation der Leser  :Very Happy:  Es steht dort nur folgendes: *Quote:*   

> Don't use "make oldconfig" with a 2.4 .config

 Die Unterschiede vom 2.4er zum 2.6er waren nicht trivial (Da hat schliesslich auch das ganze erstellen des Kernel geändert (weniger Befehle), während des kompilierens wird nicht mehr der gcc Output gezeigt sondern nur noch woran der Kernel grad rumkompiliert, etc). Von den geänderten Optionen in der Config ganz zu schweigen. Darum wird von make oldconfig abgeraten. Aber das gilt explizit nur wenn man vom 2.4er zum 2.6er wechselt.

 *schachti wrote:*   

>  *STiGMaTa_ch wrote:*   
> 
> - In der alten Config gab es eine Option die es nun nicht mehr gibt   Option wird ignoriert.
> 
> Risiko: Da es diese Option nicht mehr gibt, wird die auch nirgends ausgewertet. Ergo, kein Risiko.
> ...

 

Wenn das passiert, dann klopfe ich demjenigen auf die Schulter und sage zu ihm:"Denk mal darüber nach, warum das passiert ist. Vielleicht solltest du mal deine Update Strategie ändern..."  :Mr. Green: 

Ich bin da mit /dev/blackhawk einer Meinung. Wer einfach den alten Kernel, die alte Config etc. löscht ist selber Schuld. Es kostet ja nichts einfach den Kernel, die System.map und die Konfiguration schnell nach /boot zu kopieren, im Grub den alten Kernel Eintrag zu kopieren und anzupassen und beide Kernel drauf zu haben.

Ausserdem...

Wenn du ewig deprecated Optionen verwendest und dich nicht darum kümmerst, warum diese deprecated ist (das wird nicht einfach zum Spass der Entwickler gemacht oder um dich zu ärgern  :Wink:  ) dann hast du es nicht besser verdient, plötzlich vor vollendeten Tatsachen zu stehen  :Smile: 

Lieber Gruss

STiGMaTa

----------

## hoschi

Tschuldigung, aber wer die 2.4er Config fuer den 2.6er uebernimmt gehoert auch geschlagen  :Wink: 

"make oldconfig" ist ideal, wenn man nur von einer Versionsnummer zur naechsten huepft, oder sich nicht viel getan hat. Hat man ein dagegen ein paar Nummern Uebersprungen, hat sich viel getan oder es gab sogar ein neues Major-Release, dann muss man sich eben ran setzen und von vorne Anfangen um eine saubere Config zu erhalten.

Fazit: Ab und zu man von vorne Anfangen kann nicht verkehrt sein, genauso wie man einen Desktop irgendwann mal neu aufsetzt. Jedoch kann man ruhig "make oldconfig" verwenden, da erhaelt man weder ein schmutzige noch sonstwie kaputt Config.

----------

## schachti

 *STiGMaTa_ch wrote:*   

> 
> 
> Wenn das passiert, dann klopfe ich demjenigen auf die Schulter und sage zu ihm:"Denk mal darüber nach, warum das passiert ist. Vielleicht solltest du mal deine Update Strategie ändern..." 
> 
> Ich bin da mit /dev/blackhawk einer Meinung. Wer einfach den alten Kernel, die alte Config etc. löscht ist selber Schuld. Es kostet ja nichts einfach den Kernel, die System.map und die Konfiguration schnell nach /boot zu kopieren, im Grub den alten Kernel Eintrag zu kopieren und anzupassen und beide Kernel drauf zu haben.
> ...

 

Ich sehe das genauso - aber ich wette um eine Kiste Bier, daß es hinreichend viele User gibt, die genau sowas machen.   :Laughing: 

----------

## misterjack

 *hoschi wrote:*   

> hat sich viel getan oder es gab sogar ein neues Major-Release, dann muss man sich eben ran setzen und von vorne Anfangen um eine 
> 
> saubere Config zu erhalten

 

warum sollte man? fragen beantworten und gut ist. das ding übersetzen und booten. sinnlos unnötige arbeit machen nenne ich config-neuerstellen, wenn man eine gute hat  :Smile: 

----------

## hoschi

Na ja, wenn ich von 2.6.10 auf 2.6.17 springen wuerde. Dann nehme ich halt gleich "make menuconfig", ist natuerlich jedem persoenlich ueberlassen.

----------

## michel7

Ich machs immer über make menuconfig. Kenne den Kernel mittlerweile auswendig, daher ist es ne Sache von 5 Minuten für mich ... Vertraue irgendwie nicht dem oldconfig  :Wink: 

----------

## musv

 *hoschi wrote:*   

> Na ja, wenn ich von 2.6.10 auf 2.6.17 springen wuerde. Dann nehme ich halt gleich "make menuconfig", ist natuerlich jedem persoenlich ueberlassen.

 

Also ich find "make xconfig" klasse. Das ist richtig schön grafisch aufbereitet mit ausklappbaren Bäumen.

Und falls sich mal beim Releasesprung doch etwas mehr geändert haben sollte, ist die Standardprozedur folgende:

cp $alter_Kernel/.config $neuer_Kernel/

make oldconfig

make xconfig

make menuconfig find ich zu unübersichtlich. Ist aber Geschmacksache.

----------

## misterjack

 *michel7 wrote:*   

> Vertraue irgendwie nicht dem oldconfig 

 

Begründung? Es macht genau das, was es machen soll. Wie es schon im Thread erwähnt wurde.

----------

## energyman76b

 *schachti wrote:*   

>  *STiGMaTa_ch wrote:*   
> 
> Wenn das passiert, dann klopfe ich demjenigen auf die Schulter und sage zu ihm:"Denk mal darüber nach, warum das passiert ist. Vielleicht solltest du mal deine Update Strategie ändern..." 
> 
> Ich bin da mit /dev/blackhawk einer Meinung. Wer einfach den alten Kernel, die alte Config etc. löscht ist selber Schuld. Es kostet ja nichts einfach den Kernel, die System.map und die Konfiguration schnell nach /boot zu kopieren, im Grub den alten Kernel Eintrag zu kopieren und anzupassen und beide Kernel drauf zu haben.
> ...

 

wieso? 

man benutzt doch sowieso make install und hat in der grub.conf/menu.lst einen vmlinuz und einen vmlinuz.old eintrag.

make oldconfig

make all modules_install install

viel einfacher geht es wirklich nicht mehr ...

----------

## Ezekeel

naja wie dem auch sei ich habs nun eben auch mit dem make olcondig und anschließendem make menuconfig gemacht. Wegen dem "schön" dartstellen werde ich mich mal gezwungenermaßen in das shellscripting reinlesen um zu schauen ob man das nicht mit ein paar befehlen und schleifen (cat, grep...) in der Shell erstellen kann...

 *Quote:*   

> 
> 
> 10. Advanced: Using your old kernel .config to configure a new one
> 
> It is sometimes possible to save time by re-using the configuration file from your old kernel when configuring the new one. Note that this is generally unsafe -- too many changes between every kernel release for this to be a reliable upgrade path.
> ...

 

Und was das make oldonfig anbelangt - es ist keinesfalls eine Urban Legend sondern eine Textpassage in den aktuellen Gentoo Docs die ich zumindest für voll genommen habe!?!

----------

## STiGMaTa_ch

 *Ezekeel wrote:*   

> Und was das make oldonfig anbelangt - es ist keinesfalls eine Urban Legend sondern eine Textpassage in den aktuellen Gentoo Docs die ich zumindest für voll genommen habe!?!

 

Und wieder einmal bewahrheitet sich der Spruch: "Wer lesen kann ist KLAR im Vorteil!"  :Mr. Green: 

 *Quote:*   

> 
> 
> 10. Advanced: Using your old kernel .config to configure a new one
> 
> It is sometimes possible to save time by re-using the configuration file from your old kernel [...]

 

Hier geht es eindeutig darum, dass man eine alte .config Datei nimmt, diese in das neue Kernel Verzeichnis kopiert und damit seinen Kernel backt! Aber wir sprechen von make oldconfig!!! Das ist ein himmelweiter Unterschied. Nicht ohne Grund  steht weiter unten in deinem Zitat:

 *Quote:*   

> To reuse your old .config, you simply need to copy it over and then run make oldconfig. In the following example, we take the configuration from gentoo-sources-2.6.9-r1 and import it into gentoo-sources-2.6.9-r2. 

 

Zusammengefasst:

 *PFUI wrote:*   

> cp /usr/src/linux-2.6.14 /usr/src/linux-2.6.15
> 
> cd /usr/src/linux-2.6.15
> 
> make && make modules_install
> ...

 

 *HUI wrote:*   

> cp /usr/src/linux-2.6.14 /usr/src/linux-2.6.15
> 
> cd /usr/src/linux-2.6.15
> 
> make oldconfig
> ...

 

Lieber Gruss

STiGMaTa  :Wink: 

----------

## schachti

Hmm, STiGMaTa_ch, ich glaube, dieses Mal ist es an Dir, nochmal genau zu lesen...   :Embarassed: 

----------

## hoschi

Da hat Schachti wohl recht  :Wink: 

Klarer Fall von Wunschdenken *gg*

Wobei ich diese Ausfuerhung in der Doku schon sehr konservativ finde, wenn auch ich in solchen Dingen lieber vorsichtig bin und mit "make menuconfig" immer nochmal schnell das Ganze ueberfliege, oder wie gesagt sogar komplett von Vorne anfange.

----------

## STiGMaTa_ch

Hmm... also ich würde mal sagen, der Absatz in der Doku lässt Raum für Interpretationen    :Laughing: 

Aber zurück zum Thema (sonst wird der Thread noch wegen Themenabschweifung geschlossen):

Falls jemand wirklich Interesse hätte solch einen Configviewer zu schreiben, hier mal einige Resourcen:

Die Menustruktur wird mit dem File /usr/src/linux/arch/xxx(z.B. i386)/Kconfig erstellt (welches aber noch einige andere Kconfigs nachlädt). Wie das File aufgebaut ist und was die einzelnen Einträge bedeuten wird in /usr/src/linux/Documentation/kbuild/kconfig-language.txt erklärt.

Und hier eine Copy & Paste Lösung:

Anstatt die Menus mit verschachtelten Untermenus darzustellen, kann man auch die gesammte Konfiguration in einem Tree darstellen. Danach kann man einfach Seitenweise einen Copy&Paste in eine Datei machen. Diesen Initialaufwand muss man nur einmal tätigen. Später kann man einfach nur noch die veränderten Passagen anpassen.

Und so erhält man alles in einem Tree:

```
make MENUCONFIG_MODE=single_menu menuconfig
```

Lieber Gruss

STiGMaTa

----------

## Ezekeel

naja wie gesagt der Abschnitt lässt wirklich unterschiedliche Interpretationen zu und ich habe es eben so gelesen, dass make oldconfig damit gemeint ist... wie dem auch sei - zu meiner eigentlichten Frage hat es nicht viel beigetragen, ausser dass ich nun egal wie weit die Versionssprünge nun sein mögen, es sei denn es ist ein major release immer wieder make oldconfig verwenden werde... 

Was das darstellen anbelangt werde ich mir dann Gedanken darüber machen wenn ich wieder mal urlaub habe, da ich gerne an dem Thema bleiben möchte. Ich dachte es sei schon etwas in der Richtung vorhanden, da ich immer wieder solche Posts im Forum gesehen habe die vermuten ließen als ob sie mit irgend einem Tool erstellt worden seien. 

```
make MENUCONFIG_MODE=single_menu menuconfig
```

 ist mir neu und auch ein netter Anfang, aber nicht ganz das was ich mir wünsche. 

Ich danke allen die sich an der Diskussion beteiligt haben und beende das ganze mal in dem ich den Thread auf solved setze. Wer noch gerne weiterhin darüber Diskutieren möchte ist herzlich dazu eingeladen. Aber was ich als Resümee des ganzen Ziehen kann, ist dass eine "schöne" Darstellung eine wunschidee von mir ist, die deswegen bisher wahrscheinlich nicht verwirklicht wurde weil sie keinen Nutzen hat. Weiterhin kann ich make oldconfig immer verwenden, es sei denn es handelt sich um ein major release wie z.B. von 2.4 auf 2.6.

Schönen Sonntagabend noch!  :Smile: 

----------

