# am kernel rumgefummelt->kein kde mehr[solved]

## cHeFr0cKaH

Nabend,

ich hab mir vorgestern 1gb ram noch zugelegt. Bin jetzt also bei 2 gb ram. Ich hab eben im Kernel den high memory support aktiviert und den kernel mit make && make modules_install neu gebaut. Ich habe vorher in /boot eine Kopie der config-namemeineskernels, der System.map und des kernelimages in erstellt bzw diese in mein Homeverzeichnis kopiert. Man weiß ja nie. Ich hab mal wieder irgentetwas falsch gemacht. Jedenfalls lädt gentoo beim booten nicht alle Module und der Kde startet auch nicht. Ich hab mittles Portage die Nvidiatreiber neu installiert->ohne Erfolg. 

Kann mir vielleicht einer mal kurz und knapp aufschreiben was man genau machen muss wenn man den kernel neugebaut hat. Also was muss man von /usr/src nach /boot kopieren etc etc. Ich hab da kaum Erfahrung mit, da ich eigentlich immer sage: "Never touch a running System;)" .

Muss ich noch ein make oldconfig machen? Der schreibt dann was in meine .config datei?

Ich weiß...es gibt wahrscheinlich zich how to's. Aber ich brauchs irgentwie einmal für doofe erklärt  :Embarassed: 

Fakt ist momentan: kde startet nicht, login auf der Konsole ist möglich.

mfg

cHeFr0cKaH

bye!Last edited by cHeFr0cKaH on Thu Nov 01, 2007 6:36 am; edited 1 time in total

----------

## Finswimmer

Tipp mal startx ein und schau, was los ist.

Der Kernel läuft und von daher sollte es daran nicht liegen.Höchstens an den Modulen.

Also schau dir mal die Ausgabe von startx an.

Tobi

----------

## Max Steel

aaalso,

nach make && make modules_install solltest du diese Befehle eingeben

```
ls -l /usr/src/
```

Nun schauen ob der Link linux auf den Kernel zeigt, wenn nicht:

rm /usr/src/linux && ln -s /usr/src/linux-<kernelversion>/

[CODE]cd /usr/src/linux-<kernelversion>

cp System.map /boot/

cp arch/<arch>/boot/bzImage /boot/<name>

cp .config /boot/[/CONFIG]

Dann wären die Meldungen von startx schön.

----------

## Christoph Schnauß

 *cHeFr0cKaH wrote:*   

> Kann mir vielleicht einer mal kurz und knapp aufschreiben was man genau machen muss wenn man den kernel neugebaut hat. Also was muss man von /usr/src nach /boot kopieren etc etc.

 

Das ist nicht viel. Tatsächlich ist es lediglich die System.map und aus dem Unterverzeichnis arch/[Systemarchitektur]/boot die Datei bzImage, die du dann in /boot eventuell umbenennen mußt - bei mir einfach nach "kernel". Es ist eine gute Idee, die "alten" Dateien umzubenennen und noch aufzuheben, falls irgendwas nicht klappt, aber das hast du ja bereits getan.

 *cHeFr0cKaH wrote:*   

> Fakt ist momentan: kde startet nicht, login auf der Konsole ist möglich.

 

Wenn KDE nicht startet, liegt das in der Regel nicht am Kernel. Startet denn dein X-Server? Also: was passiert, wenn du ganz einfach auf der Konsole "xinit" eingibst?

Wenn zugleich mit dem X-Server KDE starten soll, brauchst du eine kleine Datei ".xinitrc" in deinem home-Verzeichnis. Der Punkt am Anfang des Dateinamens ist wichtig. Drin stehen braucht nur eine einzige Zeile: "startkde".

----------

## cHeFr0cKaH

Nabend,

also erstmal danke für die schnellen Antworten  :Smile: 

@Finswimmer: Also startx sagt mir dass der das nvidia-modul net laden kann.

@Max Steel: Ok, ich mach das jetzt gleich mal.

@Christoph Schnauß: Versteh ich das richtig, ich kann das bzImage einfach umbenennen und sage lilo, boote vom Image das Kernel heißt?

mfg

cheFr0cKaH

----------

## Christoph Schnauß

 *cHeFr0cKaH wrote:*   

> Versteh ich das richtig, ich kann das bzImage einfach umbenennen und sage lilo, boote vom Image das Kernel heißt?

 

Das sollte so funktionieren, ja. Egal, ob du lilo verwendest oder GRUB - ich würde dir aber heute immer GRUB empfehlen, wenn du einen Rechner hast, der jünger als fünf Jahre ist (bei älteren Rechnern kann lilo sinnvoll sein)

----------

## Christoph Schnauß

 *cHeFr0cKaH wrote:*   

> startx sagt mir dass der das nvidia-modul net laden kann.

 

_Wie_ wird dir das gesagt? Es gibt, falls der X-Server nicht starten kann, einen exakten Hinweis auf das entsprechende log. Das solltest du dir anschauen und den betreffenden Teil dann hier posten.

Im übrigen: ich habe auch auf zwei Rechnern, auf denen Gentoo läuft, NVidia GForce Grafikkarten drin. Die kann ich auch völlig ohne zusätzliche "NVidia-Module" benutzen. Der X-Server muß in der xorg.conf lediglich mitgeteilt bekommen, daß er das Modul "nv" laden soll - und das wird nun wieder vom Kernel bereitgestellt.

(Ja, ich kenne die Diskussion um "NVidia-Module"...)

----------

## cHeFr0cKaH

@Christoph Schnauß: Sry, ich bin nur grad zu blöd das mit der Ausgabenumlenkung hinzukriegen. startx > dateiname.txt erzeugt nur ein leeres file. Ach ja, in meiner make.conf steht das der xserver nv laden soll. 

Wie war denn da noma die Syntax?

EDIT: Sry...ich hatte

```
startx > dateiname anstatt startx 2>dateiname 
```

 eingetippt. Bin ein bisel eingerostet  :Sad: 

Ausgabe der Fehlermeldung:

```

hostname: Unknown host

xauth:  creating new authority file /root/.serverauth.3839

X Window System Version 1.3.0

Release Date: 19 April 2007

X Protocol Version 11, Revision 0, Release 1.3

Build Operating System: UNKNOWN 

Current Operating System: Linux destiny 2.6.18-gentoo-r2 #7 PREEMPT Sun Jan 7 17:16:23 CET 2007 i686

Build Date: 01 October 2007

   Before reporting problems, check http://wiki.x.org

   to make sure that you have the latest version.

Module Loader present

Markers: (--) probed, (**) from config file, (==) default setting,

   (++) from command line, (!!) notice, (II) informational,

   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.

(==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 29 20:46:08 2007

(==) Using config file: "/etc/X11/xorg.conf"

(II) Module already built-in

WARNING: Error inserting agpgart (/lib/modules/2.6.18-gentoo-r2/kernel/drivers/char/agp/agpgart.ko): Unknown symbol in module, or unknown parameter (see dmesg)

FATAL: Error inserting nvidia (/lib/modules/2.6.18-gentoo-r2/video/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg)

(EE) NVIDIA(0): Failed to load the NVIDIA kernel module!

(EE) NVIDIA(0):  *** Aborting ***

(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:

no screens found

XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"

      after 0 requests (0 known processed) with 0 events remaining.

```

Last edited by cHeFr0cKaH on Mon Oct 29, 2007 7:51 pm; edited 3 times in total

----------

## Christoph Schnauß

hallo,

 *cHeFr0cKaH wrote:*   

> Sry, ich bin nur grad zu blöd das mit der Ausgabenumlenkung hinzukriegen. startx > dateiname.txt erzeugt nur ein leeres file.

 

Du kannst "echte" Programmaufrufe auch nicht in ein Textfile umlenken. "startx" erzeugt aber, genauso wie "xinit", ein logfile, normalerweise /var/log/Xorg.0.log. _Das_ solltest du dir anschauen und die relevanten Teile daraus posten.

 *cHeFr0cKaH wrote:*   

> Ach ja, in meiner make.conf steht das der xserver nv laden soll. 

 

In deiner make.conf steht überhaupt nix, was irgendeine Anwendung (und der X-Server ist eine Anwendung) "laden" soll. make.conf hat mit den USE-flags Bedeutung für den GCC und legt damit fest, mit welchen Optionen der C-Compiler bestimmte Pakete, die du über "emerge" einspielen möchtest, behandelt.  Auch die anderen Einstellungen haben für "emerge" Bedeutung. Mir ist nicht bekannt, daß da irgendwelche Module festgelegt werden können, die irgendeine (andere) Anwendung vielleicht benötigt.

Wenn du "Module" benötigst (was ja an unterschiedlichen Stellen im System der Fall sein kann), so gibt es zwei Wege, sie anzusprechen - sofern sie denn überhaupt vorhanden sind: einmal geht das über die /etc/modules.conf, und zum zweiten geht das über die jeweiligen Konfigurationsdateien der Anwendung, beim X-Server eben über die /etc/X11/xorg.conf.

Wenn du deinen X-Server noch nicht konfiguriert hast, solltest du das nachholen, indem du den Konsolenbefehl "xorgconfig" ausführst.

 *cHeFr0cKaH wrote:*   

> Wie war denn da noma die Syntax?

 

Ich weiß nicht, was "da noma" für ein Programm sein könnte. Bei mir gibts auch leider keine da_noma.conf. Aber wenn es bei dir eine gibt, würde ich gerne wissen, was das nun für ein Programm ist - es scheint ja irgendwie wichtig zu sein.

----------

## ChrisJumper

Sorry, wenn ich mich einmische ich wollte nur mal anmerken das die Nvidia-Treiber (x11-drivers/nvidia-drivers) immer neu emergen muss wenn man einen anderen Kernel startet/wechselt.

Wichtig ist dafür das man den linux Link (/usr/src/linux) auf den neuen Kernel setzt*. Den man als nächstes Booten will. Wenn man zwei Versionen von einem Kernel hat ist die Wahrscheinlichkeit hoch das man nicht extra neu bauen muss.

Z.B. zwischen:

```

linux-2.6.22-gentoo-r1 

linux-2.6.22-gentoo-r2

```

Wie gesagt aber nicht immer. Wenn du mit Modulen arbeitest musst du das wahrscheinlich in diesen Zwischensprüngen eher seltener.

Trotzdem hab ich mir das zur Angewohnheit gemacht immer den Linux Link auf die "aktuell" verwendeten Kernelsourcen zu setzen. Und vorher die Treiber neu zu bauen. So hat man nach dem neustarten keine Probleme.

Speziell handhabe ich das bei mir so das ich zwei drei unterschiedliche Kernelversionen in /boot rumliegen hab. Kommt ein neuer dazu, kopiere ich ihn und die Kernelconfig unter fortlaufender Nummer dahin und erstelle einen neuen Grub-Eintrag und lösche immer die die zu alt werden.

 *Quote:*   

> kernel-2.6.22-gentoo-v8
> 
> kernel-2.6.22-gentoo-v9
> 
> kernelconf-2.6.22-gentoo-v8
> ...

 

*

```

# cd /usr/src

# rm ./linux

# ln -s ./linux-2.6.22-gentoo-r9 ./linux

```

Wenn der neue Kernel z.B. 2.6.22-gentoo-r9 (sys-kernel/gentoo-sources) ist.

**************

 *Quote:*   

> @Christoph Schnauß: Sry, ich bin nur grad zu blöd das mit der Ausgabenumlenkung hinzukriegen. startx > dateiname.txt erzeugt nur ein leeres file. Ach ja, in meiner make.conf steht das der xserver nv laden soll.
> 
> Wie war denn da noma die Syntax?

 

Guck doch einfach mal in den letzten Log vom Xserver..?

```
# less /var/log/Xorg.0.log
```

Zum Wechseln der Treiber:

Solltest du den x11-drivers/nvidia-drivers vorher installiert haben würde ich dabei bleiben und jetzt nicht zum OpenSource Treiber wechseln.

Willst du es umstellen musst du das in der "Section Device" von /etc/X11/xorg.conf verändern.

```

Section "Device"

    Identifier  "nvidia1"

    Driver      "nvidia"

    Screen 0 

EndSection

```

(Ich hab hier zwecks beispiel sämtliche Optionen "X"  weggelassen damit es übersichtlicher ist.)

Es ist ganz einfach, dieser Eintrag startet den offiziellen Nvidia-Treiber

```

     Driver     "nvidia"

```

und dieser den Open-Source Treiber von Xorg.

```

     Driver     "nv"

```

Bei dem Offenen hat man aber diverse Einschränkungen wenn man z.B. Spiele spielen will oder eine 3D-Desktop benutzt.

----------

## Christoph Schnauß

 *ChrisJumper wrote:*   

> Sorry, wenn ich mich einmische

 

Wieso? Es ist dein gutes Recht.

 *ChrisJumper wrote:*   

> ich wollte nur mal anmerken das die Nvidia-Treiber (x11-drivers/nvidia-drivers) immer neu emergen muss wenn man einen anderen Kernel startet/wechselt.

 

Das ist eben etwas, was ich in der gesamten Diskussion um NVidia bisher überhaupt nicht verstehe. Ich komme ohne aus - und ich habe zum Beispiel eine NVIDIA GeForce 6200 LE.

 *ChrisJumper wrote:*   

> Wichtig ist dafür das man den linux Link (/usr/src/linux) auf den neuen Kernel setzt*. Den man als nächstes Booten will.

 

Jaein. Wichtig ist dieser Link für das Kompilieren des neuen Kernels und der entsprechenden Module. Für das Booten hat er keinerlei Bedeutung.

 *ChrisJumper wrote:*   

> Bei dem Offenen hat man aber diverse Einschränkungen wenn man z.B. Spiele spielen will oder eine 3D-Desktop benutzt.

 

Hm. Das mag sein. Ich spiele nicht. Mich interessieren Spiele eigentlich nur als bisweilen lästige Randerscheinung, oder wenn die Jungs von http://www.my-dynastie.de/game.php mir mal wieder ohne Erlaubnis meine Grafiken von der HP klauen (Na gut, ich gebe zu, daß es in KDE immerhin ein nettes Schachprogramm gibt - das aber auch dann wieder langweilig wird, wenn man es ständig besiegt). Aber die paar 3D-Anwendungen, mit denen ich gelegentlich experimentiere (vor allem Fraktale), haben mit dem OpenSource-Treiber keinerlei Probleme.

----------

## jkoerner

 *ChrisJumper wrote:*   

> 
> 
> *
> 
> ```
> ...

 

Und wer 'ne richtig faule Socke wie ich ist, der setzt für die gentoo-sources das USE-Flag symlink und bekommt den oben beschriebenen Arbeitsschritt automatisch   :Wink: 

----------

## firefly

 *Christoph Schnauß wrote:*   

> Hm. Das mag sein. Ich spiele nicht. Mich interessieren Spiele eigentlich nur als bisweilen lästige Randerscheinung, oder wenn die Jungs von http://www.my-dynastie.de/game.php mir mal wieder ohne Erlaubnis meine Grafiken von der HP klauen (Na gut, ich gebe zu, daß es in KDE immerhin ein nettes Schachprogramm gibt - das aber auch dann wieder langweilig wird, wenn man es ständig besiegt). Aber die paar 3D-Anwendungen, mit denen ich gelegentlich experimentiere (vor allem Fraktale), haben mit dem OpenSource-Treiber keinerlei Probleme.

 

Naja 3d hardware beschleunigung hast du mit dem opensource treiber nv aber nicht, der ist rein 2d. Eventuell hast du Nouveau am laufen, denn der hat auch 3d.

----------

## musv

Ok, mal so 'ne kurze Anleitung zum Kernelbauen:

```
cd /usr/src
```

Dann guckst du nach, ob bei Dir ein Symlink auf Deine gewünschte Kernelversion vorliegt. Den braucht man zwar nicht zwangsweise. Man kann auch per Use-Flag das Ganze irgendwie einstellen. Aber aus Gewohnheits- und Sicherheitsgründen verwende ich immer den Symlink. Als Beispiel nehmen wir mal an, daß du Kernel-2.6.23 compilieren willst.

```
ln -s /usr/src/linux-2.6.23 /usr/src/linux
```

(falls Symlink noch nicht gesetzt)

```
cd /usr/src/linux

make xconfig

make && make modules_install

cp arch/i386/boot/bzImage /boot/bzImage-2.6.23
```

Du kannst auch vmlinuz statt bzImage verwenden. Auch mußt du die Kernelversion nicht notwendigerweise setzen. Ich mach das, damit ich mehrere Kernelversionen zu Auswahl per Grub booten kann. Den Kernel trägest du dann in Deine /boot/grub/grub.conf ein. System.map brauchst du nicht zu kopieren. Ich hatte noch nie 'ne System.map im /boot stehen und hatte damit noch nie Probleme.

Danach neustarten und neuen Kernel booten. Zwangsläufig wirst du dann für Pakete die Kernelmodule bauen beim Booten Fehlermeldungen bekommen (z.B. nvidia-drivers). Diese Pakete sind gegen die Kernelsourcen gelinkt und müssen für jeden neuen Kernel neu gebaut werden. Dafür gibt's ein Script:

```
eix module-rebuild

[I] sys-kernel/module-rebuild

     Available versions:  0.1 0.5

     Installed versions:  0.5(00:53:44 10.03.2007)

     Homepage:            http://www.gentoo.org/

     Description:         A utility to rebuild any kernel modules which you have installed

```

Mit 

```
module-rebuild populate
```

 sucht das Script sich alle Module zusammen, die neugebaut werden müssen. Mit

```
module-rebuild rebuild -X
```

 baust du dann die ganzen Module neu. Diese Module mußt du immer neubauen, nachdem du eine neue Kernelversion installiert und compiliert hast. Teilweise mußt duch auch die Module neubauen, wenn du dieselbe Kernelversion neucompilierst und essentielle Dinge in der Kernelkonfiguration geändert hast. 

Danach lädst du die Startup-Skripte neu, die sich beim Booten beschwert haben oder bootest die Kiste neu.

----------

## cHeFr0cKaH

@musv: Mm ok ich versuch das mal. Hoffentlich klappt das. 

mfg

cHeFr0cKaH

bye!

----------

## Christoph Schnauß

 *musv wrote:*   

> 
> 
> ```
> cd /usr/src/linux
> 
> ...

 

Das wird er nicht können, weil dieser Ablauf kein vmlinuz erstellt. Und außerdem: warum "xconfig"? Gehst du davon aus, daß man einen Kernel grundsätzlich von der grafischen Oberfläche im "Terminal" baut? Ich gehe davon aus, daß man, um einen (neuen) Kernel zu bauen, gar nicht erst den X-Server aufrufen sollte, sondern gleich auf der Konsole bleibt. Und dann lautet der Konsolenaufruf für die Konfiguration halt "make menuconfig".

 *musv wrote:*   

> Auch mußt du die Kernelversion nicht notwendigerweise setzen. Ich mach das, damit ich mehrere Kernelversionen zu Auswahl per Grub booten kann. Den Kernel trägest du dann in Deine /boot/grub/grub.conf ein.

 

Ein bißchen genauer: wenn er seinen bisherigen Kernel mit 2.6.20 gebaut hat, bekommt der eben auch den Namen "kernel-2.6.20". Und wenn er einen neuen Kernel baut, jetzt aber auf der Basis von 2.6.23, bekommt der dann den Namen "kernel-2.6.23".

"make modules_install" führt dazu, daß unter /lib/modules die entsprechenden Verzeichnisse angelegt werden, also beispielsweise /lib/modules/2.6.20 und /lib/modules/2.6.23. So lange ein neuer Kernel noch nicht korrekt funktioniert, sollte man es tunlichst vermeiden, einen "alten" Verzeichniseintrag zu löschen, der Kernel sucht sich das Modulverzeichnis, das zu seiner "Version" paßt.

 *musv wrote:*   

> System.map brauchst du nicht zu kopieren. Ich hatte noch nie 'ne System.map im /boot stehen und hatte damit noch nie Probleme.

 

Es mag da unterschiedliche Erfahrungen geben. Ich hatte bereits gravierende Probleme, wenn die System.map nicht zum Kernel gehörte.

----------

## Christoph Schnauß

 *firefly wrote:*   

> Naja 3d hardware beschleunigung hast du mit dem opensource treiber nv aber nicht

 

Das will ich gerne zugeben. Ich habs bloß bisher nirgends wirklich vermißt. Es kann ja durchaus sein, daß jemand anderes andere Anforderungen an seinen Rechner stellt als ich an meinen, und dann eben mit "nv" nicht zurechtkommt. Dann muß man eben, wie hier im Thread ja jetzt geschehen, die "Bedingungen" darstellen, für die die Treiber vom Hersteller (NVidia) gebraucht werden, und auch die Bedingungen, unter denen man auf sie verzichten kann.

----------

## musv

 *Christoph Schnauß wrote:*   

>  *musv wrote:*   
> 
> ```
> cd /usr/src/linux
> 
> ...

 

Naja, ob du vmlinuz oder bzImage ins boot kopierst, ist Dir überlassen. Aber warum sollte "dieser Ablauf" kein vmlinuz erstellen? Die letzten 50-60 Kernel (oder wieviel das auch immer gewesen sein mögen im 2.6-er Kernelzweig) konnte ich damit immer kompilieren und installieren. Wie sollte es denn sonst gehen? (PS: Obige Verzeichnisangabe ist für x86, bei anderen Architekturen muß das i386 dann durch die jeweilige Architektur ersetzt werden.)

 *Christoph Schnauß wrote:*   

> 
> 
> Und außerdem: warum "xconfig"? Gehst du davon aus, daß man einen Kernel grundsätzlich von der grafischen Oberfläche im "Terminal" baut? 
> 
> 

 

Ja, gehe ich. Ich hab bei "make menuconfig" keine Übersicht. xconfig finde ich von den ganzen Varianten (menuconfig, gconfig, manuelles Editieren der .config) am brauchbarsten. Und wenn jemand nach dem Ablauf des Kernelbauens fragt, dann geh ich davon aus, daß derjenige noch nicht sonderlich viel Erfahrung hat. Und da ist xconfig nun mal um Längen übersichtlicher. Mir wurde z.B. in der Uni zur der Linuxeinführung vor 7 Jahren vi in der Konsole erklärt. Als Folge davon hab ich die darauffolgenden 2 Jahre kein Linux angerührt. 

 *Christoph Schnauß wrote:*   

> 
> 
> Ich gehe davon aus, daß man, um einen (neuen) Kernel zu bauen, gar nicht erst den X-Server aufrufen sollte.
> 
> 

 

Was spricht dagegen, den Kernel unter X zu bauen? 

 *Christoph Schnauß wrote:*   

> 
> 
> Ein bißchen genauer: wenn er seinen bisherigen Kernel mit 2.6.20 gebaut hat, bekommt der eben auch den Namen "kernel-2.6.20". Und wenn er einen neuen Kernel baut, jetzt aber auf der Basis von 2.6.23, bekommt der dann den Namen "kernel-2.6.23".

 

Das ist rein subjektiv. Dafür gibt es keine Konvention. Du kannst das Kernelimage auch "Apfelkuchen" nennen. Wenn du das in der grub.conf / lilo.conf richtig angibst, wird der Kernel trotzdem geladen. 

 *Christoph Schnauß wrote:*   

> 
> 
>  *musv wrote:*   System.map brauchst du nicht zu kopieren. Ich hatte noch nie 'ne System.map im /boot stehen und hatte damit noch nie Probleme. 
> 
> Es mag da unterschiedliche Erfahrungen geben. Ich hatte bereits gravierende Probleme, wenn die System.map nicht zum Kernel gehörte.

 

Ich kenn System.map nur von Fedora und Ubuntu. Eventuell könnte System.map auch bei genkernel notwendig sein. Das weiß ich aber nicht, da ich noch nie genkernel verwendet hab. Bei Gentoo mit selbstgebackenem Kernel braucht man das Ding definitiv nicht. Weder bei der 2.6-er noch bei der alten 2.4-er Serie ist / war die System.map notwendig.

----------

## Christoph Schnauß

hallo,

wow, jetzt kriegen wir ja vielleicht ne "richtige" Diskussion, mit persönlichen Erfahrungen, und keinem, der sich jetzt als der "ich hab immer recht" aufspielt ;-) 

 *musv wrote:*   

> Naja, ob du vmlinuz oder bzImage ins boot kopierst, ist Dir überlassen. Aber warum sollte "dieser Ablauf" kein vmlinuz erstellen?

 

Weil er das "bei mir" noch nie gemacht hat. Das Kernel-Image hieß, seit ich überhaupt Gentoo habe, schon immer bzImage. Ich lasse mich aber gerne belehren, wenn du mir jetzt erzählst, daß es bei dir eben "vmlinuz" heißt. Diesen "Namen" kenne ich auch, aber nicht von Gentoo her.

 *musv wrote:*   

>  *Christoph Schnauß wrote:*   
> 
> Und außerdem: warum "xconfig"? Gehst du davon aus, daß man einen Kernel grundsätzlich von der grafischen Oberfläche im "Terminal" baut? 
> 
>  
> ...

 

Ups. 

 *musv wrote:*   

> Ich hab bei "make menuconfig" keine Übersicht. xconfig finde ich von den ganzen Varianten (menuconfig, gconfig, manuelles Editieren der .config) am brauchbarsten.

 

Das reicht mir nicht aus. Der Kernel ist das eigentliche "Linux", alles andere ringsherum ist "Distribution". Ob die nun Gentoo heißt oder SUSE, Mandriva oder Fedora oder sonstwie ist völlig wurscht. Der "Distribution" selber ist nun aber gar nicht "wurscht", welche grafische Obefläche sie dir als default anbietet - und in welchem Runlevel du startest. SUSE und Fedora starten erbarmungslos in Runlevel 5, Gentoo startet glücklicherweise in Runlevel 3, also ohne grafisches login, aber mit vollem Netzwerk.

Wenn du nun einen neuen Kernel bauen willst, geht das zunächst deine "Distribution" überhaupt nix an. Also auch den X-Server und die von ihm gestarteten Prozesse nicht. Aber dein Kernel soll doch nun dem gesamten System zur Verfügung stehen, unabhängig davon, welcher Benutzer sich grade anmeldet - also startest du die Konfigurationsschritte als root, gelle?

Als root hast du aber in der Regel allerhand Alarmzeichen, falls du den X-Server mit root-Rechten starten willst. Ich gebe zu, daß Gentoo im Unterschied zu anderen Distributionen hier etwas schlampig ist. Die SUSE bietet dir immerhin, wenn du als root KDE starten willst, einen martialischen Hintergrund mit allerlei Bomben an, Debian sagt dir, daß es verboten sei, Fedora versteht den Benutzernamen "root" überhaupt nicht ...

Was also spricht dafür, einen Kernel von der grafischen Oberfläche aus zu bauen? Nur die Krücke, daß du mit "su" vorgegaukelt bekommst, du seiest jetzt root und dürftest einen Kernel bauen?

Ja, du bist damit "root". Und darfst einen Kernel bauen, der jedem anderen Benutzer deines Gentoo auch zur Verfügung stehen würde. ABER: hast du mal nachgeschaut, was mit den Rechten passiert, wenn du dich im "Terminal" als root anmeldest?

Im Extremfall (ich gebe allerdings zu, daß man sich dafür auch selten dämlich anstellen muß) kann es dazu führen, daß der X-Server bis zum nächsten reboot mit root-Rechten fährt. Das heißt, du betrittst dieses Forum mit root-Rechten (ähm - nicht für das Forum, aber für deinen Rechner), du surfst im Internet mit "offenen Scheunentoren"...

Daher plädiere ich wärmstens dafür, einen neuen Kernel wirklich _ohne_ X-Server allein auf der Konsole zu bauen, sobald eben mal ein neuer Kernel fällig ist. Auf der Konsole darfst du ohne schwererwiegende Folgen gerne root sein.

 *musv wrote:*   

> Und wenn jemand nach dem Ablauf des Kernelbauens fragt, dann geh ich davon aus, daß derjenige noch nicht sonderlich viel Erfahrung hat.

 

ok, darin stimmen wir wörtlich überein.

 *musv wrote:*   

> Und da ist xconfig nun mal um Längen übersichtlicher.

 

Aber hier unterscheiden wir uns im Grundsatz - siehe oben.

 *musv wrote:*   

> Mir wurde z.B. in der Uni zur der Linuxeinführung vor 7 Jahren vi in der Konsole erklärt. Als Folge davon hab ich die darauffolgenden 2 Jahre kein Linux angerührt. 

 

Mir wurde der VI nie erklärt, ich habe mir alles, was ich zum "Computer" mittlerweile weiß bzw. zu wissen glaube, in den letzten dreizehn Jahren mühsam im "Selbststudium" angelesen. Dabei fiel aber der VI von vornherein wegen Unverständlichkeit aus - ich kann das Ding zwar einigermaßen bedienen, aber ich verstehe sehr gut, wenn mir jemand erzählt, daß er den VI nicht mag.

 *musv wrote:*   

>  *Christoph Schnauß wrote:*   
> 
> Ich gehe davon aus, daß man, um einen (neuen) Kernel zu bauen, gar nicht erst den X-Server aufrufen sollte.
> 
>  
> ...

 

Das hatten wir jetzt schon weiter oben zur Genüge, meine ich. 

 *musv wrote:*   

> Ich kenn System.map nur von Fedora und Ubuntu. Eventuell könnte System.map auch bei genkernel notwendig sein. Das weiß ich aber nicht, da ich noch nie genkernel verwendet hab. Bei Gentoo mit selbstgebackenem Kernel braucht man das Ding definitiv nicht. 

 

Das ist was Neues. Wie das mit genkernel aussieht, weiß ich auch nicht. Aber ich hatte bisher immer eine System.map. Da muß ich erstmal gründlicher prüfen, ob es eben auch "ohne" geht.

----------

## musv

 *Christoph Schnauß wrote:*   

> hallo,
> 
> wow, jetzt kriegen wir ja vielleicht ne "richtige" Diskussion, mit persönlichen Erfahrungen, und keinem, der sich jetzt als der "ich hab immer recht" aufspielt 
> 
> 

 

Na na na, wir haben uns doch alle lieb hier.   :Cool: 

 *Christoph Schnauß wrote:*   

> Das Kernel-Image hieß, seit ich überhaupt Gentoo habe, schon immer bzImage. 

 

Wirf mal einen Blick in /usr/usr/linux/arch/i386 (meinetwegen auch für 'ne andere Architektur). Ich lehn mich jetzt mal etwas weit aus dem Fenster, weil ich hier auf Arbeit an 'ner Windowskiste hinter 'ner dicken Firewall sitz und deswegen nicht bei meinem Gentoo nachsehen kann. Zumindest sollte in dem oben genannten Verzeichnis sowohl ein bzImage als auch ein vmlinuz drinstehen. Welches Kernelimage du von den beiden nach /boot rüberkopierst, sollte egal sein. Bei Gentoo steht halt seit Jahren in der Doku bzImage drin. Andere Distributionen benutzen aus historischen Gründen vmlinuz.

Nochmal zum Nachlesen:

http://en.wikipedia.org/wiki/Vmlinux

http://www.linfo.org/vmlinuz.html

 *Christoph Schnauß wrote:*   

> 
> 
> Das reicht mir nicht aus. Der Kernel ist das eigentliche "Linux", alles andere ringsherum ist "Distribution". Ob die nun Gentoo heißt oder SUSE, Mandriva oder Fedora oder sonstwie ist völlig wurscht. Der "Distribution" selber ist nun aber gar nicht "wurscht", welche grafische Obefläche sie dir als default anbietet - und in welchem Runlevel du startest. SUSE und Fedora starten erbarmungslos in Runlevel 5, Gentoo startet glücklicherweise in Runlevel 3, also ohne grafisches login, aber mit vollem Netzwerk.
> 
> Wenn du nun einen neuen Kernel bauen willst, geht das zunächst deine "Distribution" überhaupt nix an. Also auch den X-Server und die von ihm gestarteten Prozesse nicht. Aber dein Kernel soll doch nun dem gesamten System zur Verfügung stehen, unabhängig davon, welcher Benutzer sich grade anmeldet - also startest du die Konfigurationsschritte als root, gelle?
> ...

 

 :Shocked:   :Shocked:   :Shocked: 

Ich glaub, hier interpretierst du irgendwas falsch. Ich starte meinen Enlightenment nicht als root (X wird ja sowieso bei Benutzung eines Login-Managers als root gestartet), ich mach einfach 'n aterm auf und tipp da "su" ein. Inwiefern sollte das dann eine Krücke sein, die mir nur "root  vorgauckelt"? Meine Updates und Installationen per emerge mach ich übrigens auch unter X in einem aterm per su. Explodiert jetzt mein Computer, sendet das X meine Logindaten + Root-Paßwort an M$?   :Razz: 

 *Christoph Schnauß wrote:*   

> Mir wurde der VI nie erklärt, ich habe mir alles, was ich zum "Computer" mittlerweile weiß bzw. zu wissen glaube, in den letzten dreizehn Jahren mühsam im "Selbststudium" angelesen. Dabei fiel aber der VI von vornherein wegen Unverständlichkeit aus - ich kann das Ding zwar einigermaßen bedienen, aber ich verstehe sehr gut, wenn mir jemand erzählt, daß er den VI nicht mag.

 

Es ging nicht darum, daß mir damals vi erklärt wurde. Ich wollte Dir damit nur aufzeigen, daß man die Leute auch aufgrund einer gewissen unnötigen Umständlichkeit wieder ganz schnell von Linux wegkriegen kann. Bei mir waren die damals damit erfolgreich.

----------

## cHeFr0cKaH

Hallo erstmal,  :Smile: 

ich muss mich leider etwas kurz fassen, da meine Pause gleich vorbei ist. 

Ich hab mir eben mal module-rebuild emerged und ein module-rebuild rebuild -X gemacht. Der hat nur schnell die Nvidiatreiber über portage neu emerged.

Ein startx ergab leider wieder die gleiche Fehlermeldung(siehe weiter oben). Ich bin da jetzt voll durcheinander und weiß grad net wie ich jetzt am Besten weiter vorgehen sollte  :Sad:  . 

@Christoph Schnauß: Versteh ich das richtig. Wenn ich einen Kernel unter X baue, dann kann es sein das X mit root-Rechten startet? Wenn ja, wie kann ich das erkennen und gegebenenfalls ändern? Also sollte man doch lieber die grafische Oberfläche beenden und dann auf der Konsole als root 

```
/etc/init.d/xdm stop
```

 ausführen und dann erst den Kernel bauen?

soo..sry..muss wieder los. Pause ist rum  :Sad: 

mfg

cHeFr0ckaH

bye!

----------

## musv

Ähm, jetzt wo ich grad nochmal genauer die Fehlermeldung von Dir überflieg, fällt mir grad auf, daß das es eventuell gar nicht am fehlenden nvidia-Modul liegen kann.

Scheint so, als ob du bereits das agpgart aus dem Kernel geladen hast und jetzt noch versuchst, den AGP vom Nvidia-Modul zu laden. Poste mal bitte die Device-Section aus Deiner xorg.conf.

Was passiert, wenn du in der Konsole:

```
modprobe nvidia
```

 eingibst? Kommt da irgendeine Fehlermeldung? Was meint dmesg in diesem Fall?

----------

## cHeFr0cKaH

@musv: Also meine Device-Section in der xorg.con schaut so aus:

```

Section "Device"

        ### Available Driver options are:-

        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",

        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"

        ### [arg]: arg optional

        #Option     "SWcursor"              # [<bool>]

        #Option     "HWcursor"              # [<bool>]

        #Option     "NoAccel"               # [<bool>]

        #Option     "ShadowFB"              # [<bool>]

        #Option     "UseFBDev"              # [<bool>]

        #Option     "Rotate"                # [<str>]

        #Option     "VideoKey"              # <i>

        #Option     "FlatPanel"             # [<bool>]

        #Option     "FPDither"              # [<bool>]

        #Option     "CrtcNumber"            # <i>

        #Option     "FPScale"               # [<bool>]

        #Option     "FPTweak"               # <i>

   Option      "UseEdidDpi"      "false"

   Option       "Dpi"         "96 * 96"

    Identifier     "Card0"

    Driver         "nvidia"

    VendorName     "nVidia Corporation"

    BoardName      "NV43 [GeForce 6600 GT]"

EndSection

```

Mich wundert es nur grade warum die meisten Optionen auskommentiert sind. Ich mach regelmäßig ein backup von /etc und hab grad mal im Backup geguckt. Da sind die allerdings auch alle(bis auf die letzten Beiden) auskommentiert. Aber nunja..

Soo weiter im Text.

modprobe nvidia gibt die Meldung aus:

```

WARNING: Error inserting agpgart (/lib/modules/2.6.18-gentoo-r2/kernel/drivers/char/agp/agpgart.ko): Unknown symbol in module, or unknown parameter (see dmesg)

FATAL: Error inserting nvidia (/lib/modules/2.6.18-gentoo-r2/video/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg)

```

und dmesg nvidia das hier:

```

0 11 12 14 15) *0, disabled.

ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.

ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.

ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.

ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.

ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.

ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.

ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.

Linux Plug and Play Support v0.97 (c) Adam Belay

pnp: PnP ACPI init

pnp: PnP ACPI: found 15 devices

SCSI subsystem initialized

PCI: Using ACPI for IRQ routing

PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report

pnp: 00:01: ioport range 0x4000-0x407f could not be reserved

pnp: 00:01: ioport range 0x4080-0x40ff has been reserved

pnp: 00:01: ioport range 0x4400-0x447f has been reserved

pnp: 00:01: ioport range 0x4480-0x44ff could not be reserved

pnp: 00:01: ioport range 0x4800-0x487f has been reserved

pnp: 00:01: ioport range 0x4880-0x48ff has been reserved

PCI: Bridge: 0000:00:09.0

  IO window: a000-afff

  MEM window: d8000000-d9ffffff

  PREFETCH window: 88000000-880fffff

PCI: Bridge: 0000:00:0b.0

  IO window: disabled.

  MEM window: disabled.

  PREFETCH window: disabled.

PCI: Bridge: 0000:00:0c.0

  IO window: disabled.

  MEM window: disabled.

  PREFETCH window: disabled.

PCI: Bridge: 0000:00:0d.0

  IO window: disabled.

  MEM window: disabled.

  PREFETCH window: disabled.

PCI: Bridge: 0000:00:0e.0

  IO window: disabled.

  MEM window: d0000000-d7ffffff

  PREFETCH window: c0000000-cfffffff

PCI: Setting latency timer of device 0000:00:09.0 to 64

PCI: Setting latency timer of device 0000:00:0b.0 to 64

PCI: Setting latency timer of device 0000:00:0c.0 to 64

PCI: Setting latency timer of device 0000:00:0d.0 to 64

PCI: Setting latency timer of device 0000:00:0e.0 to 64

NET: Registered protocol family 2

IP route cache hash table entries: 32768 (order: 5, 131072 bytes)

TCP established hash table entries: 131072 (order: 7, 524288 bytes)

TCP bind hash table entries: 65536 (order: 6, 262144 bytes)

TCP: Hash tables configured (established 131072 bind 65536)

TCP reno registered

audit: initializing netlink socket (disabled)

audit(1193749049.508:1): initialized

audit: cannot initialize inotify handle

squashfs: version 3.1 (2006/08/19) Phillip Lougher

Initializing Cryptographic API

io scheduler noop registered (default)

io scheduler deadline registered

PCI: Linking AER extended capability on 0000:00:0b.0

PCI: Linking AER extended capability on 0000:00:0c.0

PCI: Linking AER extended capability on 0000:00:0d.0

PCI: Linking AER extended capability on 0000:00:0e.0

PCI: Setting latency timer of device 0000:00:0b.0 to 64

pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS

assign_interrupt_mode Found MSI capability

Allocate Port Service[0000:00:0b.0:pcie00]

Allocate Port Service[0000:00:0b.0:pcie03]

PCI: Setting latency timer of device 0000:00:0c.0 to 64

pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS

assign_interrupt_mode Found MSI capability

Allocate Port Service[0000:00:0c.0:pcie00]

Allocate Port Service[0000:00:0c.0:pcie03]

PCI: Setting latency timer of device 0000:00:0d.0 to 64

pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS

assign_interrupt_mode Found MSI capability

Allocate Port Service[0000:00:0d.0:pcie00]

Allocate Port Service[0000:00:0d.0:pcie03]

PCI: Setting latency timer of device 0000:00:0e.0 to 64

pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS

assign_interrupt_mode Found MSI capability

Allocate Port Service[0000:00:0e.0:pcie00]

Allocate Port Service[0000:00:0e.0:pcie03]

Real Time Clock Driver v1.12ac

vesafb: NVIDIA Corporation, nv43 Board - p216h0  , Chip Rev    (OEM: NVIDIA)

vesafb: VBE version: 3.0

vesafb: protected mode interface info at c000:d600

vesafb: pmi: set display start = c00cd636, set palette = c00cd6a0

vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da 

vesafb: VBIOS/hardware doesn't support DDC transfers

vesafb: no monitor limits have been set

vesafb: scrolling: redraw

Console: switching to colour frame buffer device 80x30

vesafb: framebuffer at 0xc0000000, mapped to 0xf8880000, using 10240k, total 262144k

fb0: VESA VGA frame buffer device

PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1

PNP: PS/2 controller doesn't have AUX irq; using default 12

serio: i8042 AUX port at 0x60,0x64 irq 12

serio: i8042 KBD port at 0x60,0x64 irq 1

mice: PS/2 mouse device common for all mice

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0

NFORCE-CK804: chipset revision 242

NFORCE-CK804: not 100% native mode: will probe irqs later

NFORCE-CK804: BIOS didn't set cable bits correctly. Enabling workaround.

NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller

    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA

    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA

Probing IDE interface ide0...

hda: WDC WD800BB-75CAA0, ATA DISK drive

input: AT Translated Set 2 keyboard as /class/input/input0

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

Probing IDE interface ide1...

hdc: AOPEN DUW1608/ARR, ATAPI CD/DVD-ROM drive

ide1 at 0x170-0x177,0x376 on irq 15

hda: max request size: 128KiB

hda: Host Protected Area detected.

   current capacity is 156250000 sectors (80000 MB)

   native  capacity is 156301488 sectors (80026 MB)

hda: Host Protected Area disabled.

hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)

hda: cache flushes not supported

 hda: hda1 hda2 < hda5 hda6 hda7 hda8 >

libata version 2.00 loaded.

sata_nv 0000:00:07.0: version 2.0

ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23

ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IRQ 217

PCI: Setting latency timer of device 0000:00:07.0 to 64

ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 217

ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 217

scsi0 : sata_nv

ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

ata1.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ (depth 0/32)

ata1.00: ata1: dev 0 multi count 1

ata1.00: configured for UDMA/133

scsi1 : sata_nv

ata2: SATA link down (SStatus 0 SControl 300)

  Vendor: ATA       Model: Maxtor 6V300F0    Rev: VA11

  Type:   Direct-Access                      ANSI SCSI revision: 05

ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 22

ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 22 (level, low) -> IRQ 225

PCI: Setting latency timer of device 0000:00:08.0 to 64

ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 225

ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 225

scsi2 : sata_nv

ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

ata3.00: ATA-7, max UDMA7, 586072368 sectors: LBA48 NCQ (depth 0/32)

ata3.00: ata3: dev 0 multi count 1

ata3.00: configured for UDMA/133

scsi3 : sata_nv

ata4: SATA link down (SStatus 0 SControl 300)

  Vendor: ATA       Model: SAMSUNG HD300LJ   Rev: ZT10

  Type:   Direct-Access                      ANSI SCSI revision: 05

SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)

sda: Write Protect is off

sda: Mode Sense: 00 3a 00 00

SCSI device sda: drive cache: write back

 sda: sda1 < sda5 sda6 >

sd 0:0:0:0: Attached scsi disk sda

SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)

sdb: Write Protect is off

sdb: Mode Sense: 00 3a 00 00

SCSI device sdb: drive cache: write back

SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)

sdb: Write Protect is off

sdb: Mode Sense: 00 3a 00 00

SCSI device sdb: drive cache: write back

 sdb: sdb1 sdb2 sdb3 < sdb5 >

sd 2:0:0:0: Attached scsi disk sdb

TCP bic registered

NET: Registered protocol family 1

powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3500+ processors (version 2.00.00)

powernow-k8:    0 : fid 0x2 (1000 MHz), vid 0x12

powernow-k8:    1 : fid 0xa (1800 MHz), vid 0xa

powernow-k8:    2 : fid 0xc (2000 MHz), vid 0x8

powernow-k8:    3 : fid 0xe (2200 MHz), vid 0x6

Using IPI Shortcut mode

ACPI: (supports<6>Time: tsc clocksource has been installed.

 S0 S1 S3 S4 S5)

kjournald starting.  Commit interval 5 seconds

EXT3-fs: mounted filesystem with ordered data mode.

VFS: Mounted root (ext3 filesystem) readonly.

Freeing unused kernel memory: 148k freed

ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17

ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 233

skge 1.6 addr 0xd9000000 irq 233 chip Yukon-Lite rev 9

skge eth0: addr 00:15:f2:35:41:a2

udev: renamed network interface eth0 to eth1

EXT3 FS on hda7, internal journal

loop: Unknown symbol kmap

loop: Unknown symbol kunmap

loop: Unknown symbol kmap_atomic

loop: Unknown symbol kunmap_atomic

loop: Unknown symbol page_address

input: PC Speaker as /class/input/input1

usbcore: Unknown symbol page_address

usbcore: Unknown symbol page_address

ehci_hcd: Unknown symbol usb_hcd_pci_suspend

ehci_hcd: Unknown symbol usb_free_urb

ehci_hcd: Unknown symbol usb_hub_tt_clear_buffer

ehci_hcd: Unknown symbol usb_hcd_resume_root_hub

ehci_hcd: Unknown symbol usb_hcd_pci_probe

ehci_hcd: Unknown symbol usb_calc_bus_time

ehci_hcd: Unknown symbol usb_hcd_pci_resume

ehci_hcd: Unknown symbol usb_get_urb

ehci_hcd: Unknown symbol usb_hcd_giveback_urb

ehci_hcd: Unknown symbol usb_hcd_pci_remove

ehci_hcd: Unknown symbol usb_root_hub_lost_power

usbcore: Unknown symbol page_address

ohci_hcd: Unknown symbol usb_hcd_pci_suspend

ohci_hcd: Unknown symbol usb_hcd_resume_root_hub

ohci_hcd: Unknown symbol usb_hcd_pci_probe

ohci_hcd: Unknown symbol usb_disabled

ohci_hcd: Unknown symbol usb_calc_bus_time

ohci_hcd: Unknown symbol usb_hcd_pci_resume

ohci_hcd: Unknown symbol usb_hcd_giveback_urb

ohci_hcd: Unknown symbol usb_hcd_suspend_root_hub

ohci_hcd: Unknown symbol usb_hcd_pci_remove

ohci_hcd: Unknown symbol usb_root_hub_lost_power

ntfs: Unknown symbol kmap

ntfs: Unknown symbol kunmap

ntfs: Unknown symbol kmap_atomic

ntfs: Unknown symbol kunmap_atomic

ntfs: Unknown symbol page_address

ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 21

ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 21 (level, low) -> IRQ 50

PCI: Setting latency timer of device 0000:00:04.0 to 64

intel8x0_measure_ac97_clock: measured 50707 usecs

intel8x0: clocking to 46807

agpgart: Unknown symbol page_address

nvidia: module license 'NVIDIA' taints kernel.

nvidia: Unknown symbol agp_bind_memory

nvidia: Unknown symbol agp_enable

nvidia: Unknown symbol agp_backend_acquire

nvidia: Unknown symbol agp_bridges

nvidia: Unknown symbol kmap

nvidia: Unknown symbol agp_free_memory

nvidia: Unknown symbol kunmap

nvidia: Unknown symbol agp_allocate_memory

nvidia: Unknown symbol agp_unbind_memory

nvidia: Unknown symbol agp_copy_info

nvidia: Unknown symbol page_address

nvidia: Unknown symbol agp_backend_release

ide_cd: Unknown symbol page_address

usbcore: Unknown symbol page_address

usbhid: Unknown symbol usb_alloc_urb

usbhid: Unknown symbol usb_free_urb

usbhid: Unknown symbol usb_register_driver

usbhid: Unknown symbol usb_reset_composite_device

usbhid: Unknown symbol usb_submit_urb

usbhid: Unknown symbol usb_control_msg

usbhid: Unknown symbol usb_deregister

usbhid: Unknown symbol usb_lock_device_for_reset

usbhid: Unknown symbol usb_string

usbhid: Unknown symbol usb_kill_urb

usbhid: Unknown symbol usb_buffer_free

usbhid: Unknown symbol __usb_get_extra_descriptor

usbhid: Unknown symbol usb_buffer_alloc

forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.

ACPI: PCI Interrupt Link [APCH] enabled at IRQ 20

ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 20 (level, low) -> IRQ 58

PCI: Setting latency timer of device 0000:00:0a.0 to 64

forcedeth: using HIGHDMA

eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0

kjournald starting.  Commit interval 5 seconds

EXT3 FS on sdb1, internal journal

EXT3-fs: mounted filesystem with ordered data mode.

kjournald starting.  Commit interval 5 seconds

EXT3 FS on sda5, internal journal

EXT3-fs: mounted filesystem with ordered data mode.

kjournald starting.  Commit interval 5 seconds

EXT3 FS on sda6, internal journal

EXT3-fs: mounted filesystem with ordered data mode.

kjournald starting.  Commit interval 5 seconds

EXT3 FS on sdb2, internal journal

EXT3-fs: mounted filesystem with ordered data mode.

usbcore: Unknown symbol page_address

Adding 979924k swap on /dev/hda6.  Priority:-1 extents:1 across:979924k

NET: Registered protocol family 17

ipv6: Unknown symbol page_address

agpgart: Unknown symbol page_address

nvidia: Unknown symbol agp_bind_memory

nvidia: Unknown symbol agp_enable

nvidia: Unknown symbol agp_backend_acquire

nvidia: Unknown symbol agp_bridges

nvidia: Unknown symbol kmap

nvidia: Unknown symbol agp_free_memory

nvidia: Unknown symbol kunmap

nvidia: Unknown symbol agp_allocate_memory

nvidia: Unknown symbol agp_unbind_memory

nvidia: Unknown symbol agp_copy_info

nvidia: Unknown symbol page_address

nvidia: Unknown symbol agp_backend_release

agpgart: Unknown symbol page_address

nvidia: Unknown symbol agp_bind_memory

nvidia: Unknown symbol agp_enable

nvidia: Unknown symbol agp_backend_acquire

nvidia: Unknown symbol agp_bridges

nvidia: Unknown symbol kmap

nvidia: Unknown symbol agp_free_memory

nvidia: Unknown symbol kunmap

nvidia: Unknown symbol agp_allocate_memory

nvidia: Unknown symbol agp_unbind_memory

nvidia: Unknown symbol agp_copy_info

nvidia: Unknown symbol page_address

nvidia: Unknown symbol agp_backend_release

agpgart: Unknown symbol page_address

nvidia: Unknown symbol agp_bind_memory

nvidia: Unknown symbol agp_enable

nvidia: Unknown symbol agp_backend_acquire

nvidia: Unknown symbol agp_bridges

nvidia: Unknown symbol kmap

nvidia: Unknown symbol agp_free_memory

nvidia: Unknown symbol kunmap

nvidia: Unknown symbol agp_allocate_memory

nvidia: Unknown symbol agp_unbind_memory

nvidia: Unknown symbol agp_copy_info

nvidia: Unknown symbol page_address

nvidia: Unknown symbol agp_backend_release

agpgart: Unknown symbol page_address

nvidia: Unknown symbol agp_bind_memory

nvidia: Unknown symbol agp_enable

nvidia: Unknown symbol agp_backend_acquire

nvidia: Unknown symbol agp_bridges

nvidia: Unknown symbol kmap

nvidia: Unknown symbol agp_free_memory

nvidia: Unknown symbol kunmap

nvidia: Unknown symbol agp_allocate_memory

nvidia: Unknown symbol agp_unbind_memory

nvidia: Unknown symbol agp_copy_info

nvidia: Unknown symbol page_address

nvidia: Unknown symbol agp_backend_release

```

----------

## Christoph Schnauß

hallo,

 *cHeFr0cKaH wrote:*   

> Versteh ich das richtig. Wenn ich einen Kernel unter X baue, dann kann es sein das X mit root-Rechten startet? 

 

Nein, so herum ist das nicht so. Es kann aber passieren, daß du deinem X-Server root-Rechte verpaßt, wozu du dich allerdings etwas vertippen mußt. Und es ist nun einmal nicht sinnvoll, den X-Server als root zu benutzen - obwohl ich etliche Leute kenne, die das einfach nicht einsehen und sich grundsätzlich als root anmelden.

 *cHeFr0cKaH wrote:*   

> Wenn ja, wie kann ich das erkennen und gegebenenfalls ändern? Also sollte man doch lieber die grafische Oberfläche beenden und dann auf der Konsole als root [...] den Kernel bauen?

 

Ich plädiere dafür, ja. Und ich meine auch, daß du mit "make menuconfig" auf der Konsole eine durchaus vrständliche kleine "Oberfläche" bekommst.

----------

## Finswimmer

 *Christoph Schnauß wrote:*   

> hallo,
> 
>  *cHeFr0cKaH wrote:*   Versteh ich das richtig. Wenn ich einen Kernel unter X baue, dann kann es sein das X mit root-Rechten startet?  
> 
> Nein, so herum ist das nicht so. Es kann aber passieren, daß du deinem X-Server root-Rechte verpaßt, wozu du dich allerdings etwas vertippen mußt. Und es ist nun einmal nicht sinnvoll, den X-Server als root zu benutzen - obwohl ich etliche Leute kenne, die das einfach nicht einsehen und sich grundsätzlich als root anmelden.
> ...

 

Das ist doch kompletter Unsinn.

Wenn ich mich als normaler User anmelde, dann in xterm root werde, dann "make menuconfig" starte, ist doch alles super. Dazu muss ich X nicht beenden.

Genauso geht es, wenn ich sux root "make xconfig" eingebe. Dann starte ich das einzelne Fenster mit Root Rechten.

Ich verstehe nicht, warum du Leuten sowas erklärst...   :Rolling Eyes: 

----------

## Christoph Schnauß

 *Finswimmer wrote:*   

> Ich verstehe nicht, warum du Leuten sowas erklärst...

 

Weil ich "sowas" schonmal bei jemand gesehen habe.  Habs mir zwar nicht in allen Details gemerkt, weil es zu abstrus war, aber da hatte jemand einen neuen Kernel bauen wollen - im XTerm - sich irgendwo vertippt, ein zweites XTerm aufgemacht und irgendwann aus lauter Verzweiflung, weil "nichts mehr ging" irgendwo "halt" eingegeben. Die Folge war eine "kernel panic" beim nächsten Hochfahren, und dann durfte ich "retten".

Das mag nun wirklich selten so extrem vorkommen. Ich selber habe mich halt an diese Vorgehensweise gewöhnt, daß ich "verwaltungsaufgaben", die root zu erledigen hat, eben auf der Konsole mache - der X-Server kann ja, wenn er benötigt wird, unter einer anderen Anmeldung trotzdem laufen. Es muß nun nicht jeder auf dieselbe Weise verfahren. Wenns im XTerm auch geht - na bitte. Bei älteren Rechnern kann es allenfalls vorkommen, daß es mit dem Speicher ein bißchen eng wird.

----------

## musv

@cHeFr0cKaH:

Ich poste Dir mal meine Device-Section. 

```

Section "Device" 

   Identifier "device0" 

   VendorName "nvidia" 

   Driver "nvidia" 

   BusID "PCI:2:0:0" 

   Option "NoLogo"             "1"

   Option "NvAGP"              "1"

#   Option "DigitalVibrance"    "0"

   Option "RenderAccel"        "1"

   Option "Overlay"             "1"

   Option "HWCursor"           "1"

   Option "CursorShadow"       "1"     

   Option   "DPI"               "75 x 75"

   Option      "backingstore" "true"

   Screen 0 

EndSection 

```

Wenn du nur einen Monitor benutzt, kannst du die BusID weglassen. Wichtig ist eher NvAGP. 

Link dazu:

http://http.download.nvidia.com/XFree86/Linux-x86/1.0-8774/README/appendix-d.html

Und überprüf bei der Gelegenheit mal im Kernel, ob du agpgart aktiviert hast. (Device Drivers -> Character Devices -> /dev/agpgart (AGP Support))

Da ich den AGP-Support vom Nvidia-Treiber verwende, hab ich den agpgart im Kernel deaktiviert. Es ist zwar auch möglich, den kernelinternen AGP-Treiber zu verwenden, nur weiß ich nicht, ob sich da manchmal ein paar Konflikte auftun könnten in Verbindung mit dem propietären Nvidia-Treiber. 

 *cHeFr0cKaH wrote:*   

> 
> 
> modprobe nvidia gibt die Meldung aus:
> 
> ```
> ...

 

Sieh Dir mal bitte diesen Link an:

https://forums.gentoo.org/viewtopic.php?t=367321

Ist zwar englisch, aber der Typ scheint genau dieselben Probleme gehabt zu haben. Und als Fazit aus dem Posting:

Überprüf bitte noch mal genau, ob der von Dir zuletzt gebaute Kernel auch der Kernel ist, zu dem du die Module gebaut hast (Symlink: /usr/src/linux) und ob du den Kernel nach Compilieren auch nach /boot kopiert hast, und ob du auch diesen Kernel dann tatsächlich gebootet hast. Es scheint zumindest so, daß die Kernelversion nicht mit der Modulversion übereinstimmt und deshalb die Module nicht geladen werden können. Das betrifft bei Dir das Nvidia-Modul, den USB-Support und auch den AGP-Support.

----------

## Inte

 *musv wrote:*   

> Da ich den AGP-Support vom Nvidia-Treiber verwende, hab ich den agpgart im Kernel deaktiviert. Es ist zwar auch möglich, den kernelinternen AGP-Treiber zu verwenden, nur weiß ich nicht, ob sich da manchmal ein paar Konflikte auftun könnten in Verbindung mit dem propietären Nvidia-Treiber.

 Wenn Du schon sowas empfiehlst, dann solltest Du auch wissen, was Du tust. In der Appendix F ist eine Liste von Mainboards zu finden, die mit dem nVidia-Äquivalent zu agpgart klarkommt. Deswegen ist der default von NvAGP auch 3 und nicht 1 (wie bei älteren Treibern). Der aktuelle Wert lässt sich durch ein cat /proc/drivers/nvidia/registry abfragen.

Des weiteren wird bei vielen das Modul nvidia bereits beim booten geladen. Deswegen sollte man solche Optionen in die /etc/modprobe.d/nvidia eintragen und dann ein update-modules ausführen. Die Optionen kann man sich mit modinfo nvidia anzeigen lassen.

----------

## cHeFr0cKaH

Hi,

also ich hab mal den Symlink überprüft.

ls -l in /usr/src gibt das hier aus :

```

total 12

-rw-------  1 root root 1275 Aug  3 12:18 DEADJOE

lrwxrwxrwx  1 root root   22 Jan  7  2007 linux -> linux-2.6.18-gentoo-r2

drwxr-xr-x 20 root root 4096 Nov 20  2006 linux-2.6.17-gentoo-r8

drwxr-xr-x 20 root root 4096 Oct 29 19:46 linux-2.6.18-gentoo-r2

```

Der 2.8.18-r2 ist auch der Kernel, den ich bisher verwendet hab.

in /boot schauts so aus:

```

total 8164

-rw------- 1 root root     704 Jun 12 21:29 DEADJOE

lrwxrwxrwx 1 root root      27 Aug  3 11:59 System.map -> System.map-2.6.18-gentoo-r2

-rw-r--r-- 1 root root  572202 Sep 27  2006 System.map-2.6.17-gentoo-r8

-rw-r--r-- 1 root root  600600 Oct 29 19:56 System.map-2.6.18-gentoo-r2

-rw-r--r-- 1 root root  600634 Jan  7  2007 System.map-2.6.18-gentoo-r2.old

lrwxrwxrwx 1 root root      31 Jan  6  2007 System.map.old -> System.map-2.6.18-gentoo-r6.old

lrwxrwxrwx 1 root root       1 Sep 30  2006 boot -> .

-rw-r--r-- 1 root root     512 Sep 28  2006 boot.0300

-rw-r--r-- 1 root root 1287422 Oct 29 19:56 bzImage-2.6.18-gentoo-r2

lrwxrwxrwx 1 root root      23 Aug  3 11:59 config -> config-2.6.18-gentoo-r2

-rw-r--r-- 1 root root   34199 Sep 27  2006 config-2.6.17-r8

-rw-r--r-- 1 root root   33622 Oct 29 20:01 config-2.6.18-gentoo-r2

-rw-r--r-- 1 root root   33551 Jan  7  2007 config-2.6.18-gentoo-r2.old

lrwxrwxrwx 1 root root      27 Jan  6  2007 config.old -> config-2.6.18-gentoo-r6.old

-rw-r--r-- 1 root root 1239831 Sep 27  2006 kernel-2.6.17-gentoo-r8

-rw-r--r-- 1 root root 1289869 Oct 29 19:09 kernel-2.6.18-gentoo-r2

-rw------- 1 root root   29696 Oct 29 20:02 map

lrwxrwxrwx 1 root root      24 Aug  3 11:59 vmlinuz -> vmlinuz-2.6.18-gentoo-r2

-rw-r--r-- 1 root root 1284125 Aug  3 11:59 vmlinuz-2.6.18-gentoo-r2

-rw-r--r-- 1 root root 1288227 Nov 26  2006 vmlinuz-2.6.18-gentoo-r2.old

lrwxrwxrwx 1 root root      28 Jan  6  2007 vmlinuz.old -> vmlinuz-2.6.18-gentoo-r6.old

```

Ich könnte hier eigentlich mal ein bisel aufräumen. Aber wenn das System einmal läuft fummel ich da net so gerne drann rum.

uname -a:

```

Linux destiny 2.6.18-gentoo-r2 #7 PREEMPT Sun Jan 7 17:16:23 CET 2007 i686 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux

```

Und noch die lilo.conf:

```

boot=/dev/hda

root=/dev/hda7

prompt

timeout=100

image=/boot/kernel-2.6.18-gentoo-r2

label="Gentoo"

root=/dev/hda7

read-only

other=/dev/hda1

label="Windows_Xp"

```

----------

## musv

Vorweg: Ich hab keine Ahnung von Lilo, da ich von jeher immer Grub verwendet hab. Aber in Verbindung mit dem Link, den ich Dir genannt hab, ist mir folgendes aufgefallen:

 *cHeFr0cKaH wrote:*   

> Hi,
> 
> in /boot schauts so aus:
> 
> ```
> ...

 

Ich hab zwar oben geschrieben, daß es egal ist, wie das Kernelimage heißt, was auch problemlos für den grub gilt. Jedoch weiß ich nicht, wie der Lilo das umsetzt. Im dümmsten Fall versucht der Lilo das alte Kernelimage vom 3. August zu laden, was dann die Fehler beim Laden der Module erklären würde. 

@Christoph Schnauß:

In /usr/src/linux/arch/i386/boot gibt es bei mir ein bzImage und ein Image namens vmlinux.bin.

----------

## cHeFr0cKaH

Hi,

Mm also ich hatte in der Lilo.conf bisher immer den kernel-namemeineskernels bei image stehen. Und bisher hats auch immer funktioniert. Aber vielleicht hast du Recht und der versucht wirklich dieses Image vom 3. August zu laden.  Was ich nur nicht verstehe, vmlinuz hat doch einen Symlink auf vmlinuz-2.6.18-gentoo-r2 und nicht auf kernel-2.6.18-gentoo-r2 .  So wie's bei mir in der lilo.conf steht.

```

image=/boot/kernel-2.6.18-gentoo-r2

 
```

Warum würde der dann eventuell versuchen das alte Image vom August zu laden?

----------

## mastacloak

 *cHeFr0cKaH wrote:*   

> 
> 
> uname -a:
> 
> ```
> ...

 

Du lädst noch nicht mal das Image vom 3. August, sondern anscheinend eines vom 7. Januar. Hast Du auch nochmal 

```
lilo
```

 nach dem Überschreiben des Kernel-Images ausgeführt?

----------

## cHeFr0cKaH

 *Quote:*   

> 
> 
> Hast Du auch nochmal
> 
> ```
> ...

 

Jap, hab ich gemacht.

----------

## cHeFr0cKaH

Guten Morgen,

also ich werd nachher mal wenn ich zuhause bin die Lilo.conf editieren und bei image das hier reinschreiben:

```

image=/boot/bzImage-2.6.18-gentoo-r2

```

anstatt

```

image=/boot/kernel-2.6.18-gentoo-r2 

```

Dann müsste er ja eigentlich das image booten, welches ich am 29 Oktober erstellt hab. Hoffentlich klappt das dann.

mfg

cHeFr0cKaH

bye!

----------

## cHeFr0cKaH

Soo...der Kernel lädt wieder alle Module  :Smile:  . Kde startet auch wieder. Es lag wohl wirklich an dem alten Image vom 7 Januar.

Danke mastacloak  :Smile:  . Das mit dem alten Image hätte ich glatt übersehen. Und natürlich vielen dank an die Anderen!  :Smile: 

Ach eine Frage hätte ich noch. Wenn man die alte Kernelconfig behalten möchte, dann mach ich nachdem der kernel mit 

```

make && make modules_install && make install

```

gebaut wurde ein make oldconfig in /usr/src/linux  und kopiere dann die .config nach /boot/config-kernelname ? Ist das so richtig in der Reihenfolge?

mfg

cHeFr0cKaH

bye!

----------

## musv

Neeeee  :Smile: 

Wenn du den Kernel konfiguriert hast (menuconfig, xconfig usw.), wird diese Konfiguration in einer Datei namens .config gespeichert. Die befindet sich in Deinem Kernelverzeichnis (/usr/src/linux). Wenn du jetzt einen neuen Kernel installieren willst, dann kannst du die .config von Deinem alten Kernelverzeichnis in das neue reinkopieren. Und danach machst du ein:

```
make oldconfig
```

,

um die alte .config mit eventuell veränderten Kerneloptionen (neue Treiber, Wegfall alter Treiber) zu modifizieren.

Btw:

Die Konfiguration des aktuell gebooteten Kernels steht auch in /proc/config.gz. Die ist identisch zu der .config im Kernelverzeichnis des aktuellen Kernels.

Und "make oldconfig" kannst du Dir theoretisch auch sparen, wenn du danach die Konfiguration eh noch mit "make xconfig" oder "make menuconfig" bearbeitest.

----------

## firefly

 *musv wrote:*   

> Btw:
> 
> Die Konfiguration des aktuell gebooteten Kernels steht auch in /proc/config.gz. Die ist identisch zu der .config im Kernelverzeichnis des aktuellen Kernels.
> 
> Und "make oldconfig" kannst du Dir theoretisch auch sparen, wenn du danach die Konfiguration eh noch mit "make xconfig" oder "make menuconfig" bearbeitest.

 

Aber nur wenn es in der kernel-konfiguration ausgewählt ist  :Wink: 

----------

## cHeFr0cKaH

Guten Morgen,

ahh ok:) . Dann weiß ich da jetzt auch besser bescheid  :Smile:  . Danke euch!

mfg

cHeFr0cKaH

bye!

----------

