# Probleme beim Kernel backen

## ModellbahnerTT

Hallo @all,

ich habe beim Kernel backen ein Problem ich bin nach dieser Anleitung gegangen.

http://de.gentoo-wiki.com/Kernel_manuell_kompilieren

Jetzt erhalte ich die Fehlermeldung:

```
VFS: Cannot open root device "hda8 or unknown-block(0,0)

Please append a correct "root=" boot option

Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
```

Meine Konfiguration sieht so aus

grub.conf

```
default 0

timeout 10

title=Gentoo

root (hd0,2)

kernel /boot/kernel root=/dev/hda8
```

lspci sagt folgendes:

```

0000:00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)

0000:00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)

0000:00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)

0000:00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)

0000:00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)

0000:00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)

0000:00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)

0000:00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)

0000:00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)

0000:00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)

0000:00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)

0000:00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)

0000:00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)

0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration

0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map

0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller

0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control

0000:01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600 GT] (rev a2)

0000:05:06.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)

0000:05:06.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 03)

0000:05:06.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port

0000:05:08.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
```

genkernel habe ich nicht verwendet da ich kein Netz habe wenn ich genkernel einsetze. Kann mir jemand sagen was ich als Kerneloption wählen muss oder wie ich genkernel dazu bringe die Netzwerkkarte mit reinzunehmen?

Danke im Voraus für eure Hilfe.

ModellbahnerTT

Mein System:

CPU: AMD Athlon 64 3500+

MB: Abit AN8

RAM: 1024 MB

GK Nvidia 6600 GT

----------

## himpierre

1. root=hda8? Stimmt das denn?

2. Sata oder IDE Platte?

3. IDE bzw. Sata Treiber fest im Kernel?

4. Um die Netzwerkkarte kannste Dich später kümmern.

cheers

t.

----------

## ModellbahnerTT

Zu 1.) Ja root=hda8 stimmt

hda3 ist boot

hda7 ist swap

hda8 ist root

Zu 2.) Platte ist IDE

Zu 3.) Welche IDE muss ich nehmen? Die Standart IDE sind fest im Kernel

Zu 4.) Das ist richtig aber mit genkernel läuft ja alles ich müsste genkernel nur noch sagen das er die Netzwerkkarte mit nehmen soll.

ModellbahnerTT

----------

## mv

 *ModellbahnerTT wrote:*   

> 
> 
> ```
> VFS: Cannot open root device "hda8 or unknown-block(0,0)
> ```
> ...

 

Du brauchst eine Ramdisk, in der Du mit einem Startskript /dev/hda8 erstellst (oder udev startest).

Benutze lieber genkernel, das macht das richtig.

 *Quote:*   

> genkernel habe ich nicht verwendet da ich kein Netz habe wenn ich genkernel einsetze.

 

Unwahrscheinlich, dass das mit genkernel zusammenhängt: Der Zweck von genkernel ist es i.W., Dir das "händische" Bauen der erwähnten Ramdisk zu ersparen. Konfigurieren musst Du den Kernel natürlich trotzdem selbst - sinnigerweise genau so, wie Du es ohne genkernel tun würdest. Benutze doch dazu einfach eine alte Kernel-Konfiguration von Dir, bei der Deine Netzwerkkarte geht.

----------

## himpierre

 *Quote:*   

> Du brauchst eine Ramdisk

 

Das wäre mir neu. /Ich/ habe noch nie eine Ramdisk eingesetzt.

 *Quote:*   

> Welche IDE muss ich nehmen?

 

```
Symbol: BLK_DEV_AMD74XX [=y]                                            

                     Prompt: AMD and nVidia IDE support

                     Defined at drivers/ide/Kconfig:485 

                     Depends on: IDE && BLK_DEV_IDE && BLK_DEV_IDEDMA_PCI

  Location:

       -> Device Drivers

       -> ATA/ATAPI/MFM/RLL support

           -> ATA/ATAPI/MFM/RLL support (IDE [=y]) 

             -> Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support

               -> PCI IDE chipset support (BLK_DEV_IDEPCI [=y])

                 -> Generic PCI bus-master DMA support (BLK_DEV_IDEDMA_PCI) 
```

Netzwerkkarte:

```
Device Drivers --->

    Networking support  --->    

         [*] Ethernet (10 or 100Mbit) 

           <*>   Generic Media Independent Interface device support   

           [*] EISA, VLB, PCI and on board controllers

           <*>   National Semiconductor DP8381x series PCI Ethernet support
```

Geht das?

----------

## mv

 *himpierre wrote:*   

>  *Quote:*   Du brauchst eine Ramdisk 
> 
> Das wäre mir neu. /Ich/ habe noch nie eine Ramdisk eingesetzt.

 

Bevor man zu udev "gezwungen" war (also vor 2.6.16 oder so), hatte man keine gebraucht. Aber seitdem wird /dev/hd* doch nur von der Userland-Seite von udev erzeugt. Oder kann man das neuerdings auch irgendwie Kernel-intern erreichen?   :Question:   Das wäre mir wiederum neu... zumindest bei /mir/ hat immer /dev/hda* gefehlt, wenn ich udev/genkernel nicht ordentlich eingerichtet hatte.

----------

## himpierre

Ich bin jetzt weit davon entfernt die BootMechanismen von Gentoo 100% zu verstehen, aber bisher habe ich Gentoo immer installiert ohne einen Kernel mit Ramdisk zu erstellen. Und das sind schon einige Installationen. Selbstverständlich auch neuere KernelVersionen. Sind nicht im Stage3 alle möglichen Devices mit dabei?

cheers

t.

----------

## mv

 *himpierre wrote:*   

> Sind nicht im Stage3 alle möglichen Devices mit dabei?

 

Ich habe keine halbwegs aktuelle Gentoo-CD, aber wie sollte das gehen? Solange /dev/hda* nicht existiert, können ja von dort auch keine device-Nodes gelesen werden! Woher sollten sie also kommen können (oder auch nur der Befehl, sie zu lesen!), wenn nicht von einem initramfs (oder eben durch ein mir bislang unbekanntes Kernelfeature)?

----------

## ModellbahnerTT

Danke für die Antworten.

@mv Von einer Ram Disk steht auch nichts in der Anleitung.

@himpierre Deinen Vorschlag werde ich jetzt gleich mal testen und dann posten ob es geklappt hat.

ModellbahnerTT

PS: Sorry das ich erst jetzt antworten kann aber es ist etwas wichtiges dazwischen gekommen.

----------

## ModellbahnerTT

@himpierre Dein Vorschlag hat leider nicht so ganz funktioniert.  Die Fehlermeldung beim booten lautet:

```
network interface eth0 does not exist

Please verify hardware or kernel module (driver)

ERROR: Problem starting needed service net.eth0

            netmount was not started.

```

ping 127.0.0.1 geht  :Smile:  aber ping 192.168.0.2 geht nicht  :Sad: . ifconfig eth0 sagt:

```
eth0: error fechting interface information: Device not found
```

ModellbahnerTT

----------

## Erich

 *ModellbahnerTT wrote:*   

>   Die Fehlermeldung beim booten lautet:
> 
> ```
> network interface eth0 does not exist
> 
> ...

 

Modellbahner:

Network device suporrt-->

Wan interfaces--->

<M>  PPP  (point-to-point protocol) support

Brauchst ,um ins Internet zu kommen.

Und weiter:

von

<M> PPP support for async serial ports

bis

<M>PPP over Ethernet

alle ins Modul einkompilieren.

Gruß Erich.

----------

## ModellbahnerTT

 *Erich wrote:*   

>  *ModellbahnerTT wrote:*     Die Fehlermeldung beim booten lautet:
> 
> ```
> network interface eth0 does not exist
> 
> ...

 

Die Fehlermeldung bleibt trotzdem immer noch bestehen.  :Sad: 

ModellbahnerTT

----------

## STiGMaTa_ch

 *mv wrote:*   

> [...]Das wäre mir wiederum neu... zumindest bei /mir/ hat immer /dev/hda* gefehlt, wenn ich udev/genkernel nicht ordentlich eingerichtet hatte.

 

Die Aussage, dass zum erzeugen der /dev/hda* Devices zwingend eine initialramfs benötigt wird ist falsch.

Es ist kein Zwang sondern vielmehr eine Möglichkeit! Meistens wird diese Methode verwendet, wenn ein sehr modular aufgebauter Kernel (wie etwa der genkernel) verwendet wird. Dann wird zuerst eine initramfs gebootet und von dort aus werden dann die benötigten devices erzeugt.

Alternativ kann udev aber auch einie initiale /dev Struktur erzeugen mit Infos aus dem virtuellen Kernel Dateisystem /sys. In /sys wird für jedes Device welches der Kernel erkennt die entsprechende Information gespeichert. Darum muss man auch alle Dinge welche "beim booten" schon benötigt werden fix in den Kernel kompilieren. Sobald der Kernel also den Chipsatz des Systems erkannt hat, kann er auch die daran angeschlossenen Harddisks erkennen. Und sobald diese erkannt wurden werden die Informationen in /sys abgelegt. Und diese Informationen liest wiederum udev aus und erzeugt damit die initiale /dev Struktur.

Und bevor du jetzt fragst wie udev eigentlich gestartet werden kann, da es sich ja auf der / Partition befindet...

Nun, hier kommt das selbe Problem zum tragen wie beim aufrufen von init. Denn init befindet sich normalerweise in /sbin/init. Um das jedoch aufrufen zu können muss ja aber / bereits gemountet sein, doch wie soll das gehen, wenn init der Vater aller Prozesse ist und mouten etc. erst erfolgt wenn init bereits gestartet wurde?

Ganz einfach...

Du übergibst GRUB ja die Option root=xxx. Diese Information wird wiederum dem Kernel übergeben, welcher dadurch automatisch das device /dev/root erzeugt. Ueber dieses Device kann der Kernel nun / mounten und dann /sbin/init aufrufen. Dieser liest wiederum /etc/inittab aus und der Bootvorgang kann gestartet werden. Eines der ersten Scripts wird dann hingehen und die root Partition remounten und dabei anstelle von /dev/root das korrekte device verwenden.

Lieber Gruss

STiGMaTa

----------

## mv

 *STiGMaTa_ch wrote:*   

> Die Aussage, dass zum erzeugen der /dev/hda* Devices zwingend eine initialramfs benötigt wird ist falsch.

 

Das erklärt, weshalb es in keiner Anleitung steht, aber ich bin immer noch nicht sicher, ob ich richtig verstanden habe, wie es ohne gehen kann:

 *Quote:*   

> Du übergibst GRUB ja die Option root=xxx. Diese Information wird wiederum dem Kernel übergeben, welcher dadurch automatisch das device /dev/root erzeugt.

 

Das würde aber bedeuten, dass der Kernel bereits alle für root=xxx möglichen Devices kennen müsste? Er müsste also beispielsweise wissen, welche major/minor device nodes /dev/hdc11 oder /dev/sda oder was auch immer bekommen werden, wenn der entsprechende Parameter mit root=xxx übergeben wird, denn er kann ja einerseits zu diesem Zeitpunkt noch nicht auf /dev zugreifen, um diese Nummern auszulesen, andererseits muss aber ja /dev/root das "richtige" Medium bedeuten. Es müsste also eine solche Liste im Kernel schon fest "verdrahtet" sein - zusätzlich zu der analogen "Verdrahtung" in udev. Klingt irgendwie redundant und vor allem auch fehlerträchtig.

Habe ich das wirklich richtig verstanden?

Wenn ich beispielsweise zwei Festplatten in meinem Rechner habe und udev so konfiguriere, dass /dev/hda eine bestimmte Platte (etwa mit einer bestimmten Seriennummer) ist, dann bedeutet der Kernel-Parameter root=/dev/hda1 nicht unbedingt, dass auch tatsächlich von der ersten Partition dieser Platte gebootet wird, sondern vielmehr von der Platte, die der Kernel (im Gegensatz zu udev) für die erste hält? (Mit initramfs und real_root=/dev/hda1 hätte ich aber natürlich in jedem Fall die richtige Platte erwischt)

----------

## ModellbahnerTT

Folgendes Problem besteht noch immer  :Sad:  und ich hoffe das ihr mir weiterhelfen könnt  :Wink: .

```
network interface eth0 does not exist 

Please verify hardware or kernel module (driver) 

ERROR: Problem starting needed service net.eth0 

netmount was not started. 

```

ModellbahnerTT

----------

## musv

 *ModellbahnerTT wrote:*   

> 
> 
> 0000:05:08.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller[/code]
> 
> 

 

```

Device Drivers  --->

Network device support  --->

Ethernet (10 or 100Mbit)  --->  

[*] Ethernet (10 or 100Mbit)  

[*] EISA, VLB, PCI and on board controllers 

<*>   National Semiconductor DP8381x series PCI Ethernet support 

```

Kannste natürlich auch als Modul bauen.

----------

## ModellbahnerTT

@musv Diese Option habe ich bereits eingestellt und es funktioniert trotzdem leider noch nicht.

ModellbahnerTT

----------

## musv

Hmm, nur mal so 'ne dumme Frage:

Du hast, nachdem du den Kernel neu übersetzt hast, das neue Kernelimage auch nach /boot kopiert?

Falls du den Treiber als Modul compiliert hast, hast du auch:

make modules_install 

gemacht? Und das Modul ist dann auch geladen (lsmod) ?

----------

## franzf

Und *hust* /boot war gemountet, als du es kopiert hast?

----------

## ModellbahnerTT

@musv Kernel habe ich nach boot kopiert und den Treiber habe ich fest mit einkompiliert. Also sollte er geladen werden.

@franzf /boot war gemountet.

ModellbahnerTT

----------

## STiGMaTa_ch

@ModellbahnerTT

- Lass die Option 

```
<*>   National Semiconductor DP8381x series PCI Ethernet support 
```

 mal drinn. Denn das wäre der korrekte Treiber

- Ein ifconfig -a nach dem booten zeigt dir also nur lo an?? Poste doch bitte mal diesen output.

- Poste doch bitte auch mal den Output von 

```
grep -v "#" /etc/conf.d/net
```

@mv

 *Quote:*   

> [...]Das würde aber bedeuten, dass der Kernel bereits alle für root=xxx möglichen Devices kennen müsste? Er müsste also beispielsweise wissen, welche major/minor device nodes /dev/hdc11 oder /dev/sda[...]

 

Naja, wenn der Kernel die nicht kennt, WER DANN??   :Shocked: 

Im Ernst, natürlich kennt er die alle! /dev/hdc11 ist IMMER ein Blockdevice mit der Major Nummer 22 und der Minor Nummer 11. Welche Major/Minor Kombination welches Device anspricht ist in /usr/src/linux/Documentation/devices.txt reglemeniert. Aus diesem Grund muss auch jeder, der irgend ein neues Device gebastelt hat und dieses im Kernel drinn haben möchte bei Torben Mathiasen (Autor dieser devices.txt Datei) einen Antrag um Aufnahme stellen. Er koordiniert das ganze uns achtet z.B. darauf, dass nicht zwei Personen/Firmen die selbe Major/Minor Nummer erhalten für Ihr Device.

 *Quote:*   

> [...]müsste also eine solche Liste im Kernel schon fest "verdrahtet" sein - zusätzlich zu der analogen "Verdrahtung" in udev. Klingt irgendwie redundant und vor allem auch fehlerträchtig. [...]

 

Wie gesagt, wenn der Kernel nicht weiss, dass der Zugriff aug Major 22 Minor 11 an den IDE Treiber übergeben werden muss, dann würde in deinem System gar nichts gehen. Ausserdem darfst du nicht den Fehler machen wie ein Mensch zu denken sondern musst wie ein Computer denken. Namen sind für Ihn nur Schall und Rauch die Nummern sind wichtig. Und da jede Major/Minor Nummer gerade mal von 0 - 255 (also 256 Möglichkeiten) reicht, muss der Kernel eine Liste von maximal 65536 Einträgen kennen. Diese 64KB fressen nicht viel Platz  :Wink: 

Und was udev betrifft... udev "verdrahtet" nichts. Udev geht wie bereits gesagt nur hin und schaut, welche devices der Kernel denn nun zur Verfügung stellt. Und für diese erzeugt udev dann jeweils ein Device im /dev Verzeichnis. Prizipiell bräuchte es das /dev Verzeichnis aber gar nicht. Jedes Programm könnte einfach so programmiert werden, dass es bei entsprechendem Zugriff einfach auf die entsprechende major/minor Nummer zugreift. Der Nachteil wäre aber, dass bei einer Änderung in der Device Struktur (z.B. hdc ist per sofort major 33 und nicht mehr 22) jedes einzelne Programm welches irgendwie direkt auf eine Harddisk zugreifen würde neu geschrieben und kompiliert werden müsste. Ausserdem würde jedes Programm plötzlich andere Bezeichnungen für diese Devices verwenden. Bei Programm A würdest du [Primary Master: Partition 3] auswählen müssen, ein anderes würde dir vielleicht [primap3] zur Auswahl geben etc. Chaos pur also.

Mit dem /dev System beugst du diesem vor, weil z.b. /dev/hdc11 immer /dev/hdc11 ist. Ob nun die Major plötzlich von 22 auf 33 ändert kann dir egal sein, da in dem Moment das Device bereits auf die korrekte Major Nummer zeigt.

 *Quote:*   

> Wenn ich beispielsweise zwei Festplatten in meinem Rechner habe und udev so konfiguriere, dass /dev/hda eine bestimmte Platte (etwa mit einer bestimmten Seriennummer) ist, dann bedeutet der Kernel-Parameter root=/dev/hda1 nicht unbedingt, dass auch tatsächlich von der ersten Partition dieser Platte gebootet wird,

 

Genau! Aber das wird niemand machen, weil dann nichts mehr funktionieren würde. Das wäre dann in etwa so wie mit dem Typen der eines Tages bestimmt alle Gegenstände anders zu benennen. Der Tisch wird zum Stuhl, der Stuhl zum Tisch usw. Wenn er nun sagt:"Bring mit den Stuhl" meint er eigentlich du sollst ihm den Tisch bringen.

Aber da wie gesagt die devices.txt reglementiert, dass /dev/hdc11 nunmal immer major22/minor11 ist und da grub dies ebenfalls so handhabt wird bei root=/dev/hdc11 immer das Tupel 22:11 an den Kernel übergeben welcher dann wiederum /dev/root richtig mountet. Ob du dann die Udev Rules anpasst und /dev/hdcXX plötzlich in /dev/gentooXX umbenennst ist dann dein Bier. Du müsstest dann halt jedem Tool das auf /dev/hdcXX zugreiffen wollte begreiflich machen, dass es nun halt /dev/gentooXX verwenden soll. Dem Kernel ist das aber egal, denn ob das Ding nun /dev/hdc11 oder /dev/gentoo11 heisst ist wurscht, sofern major/minor stimmen.

Du kannst das als root ja mal selber austesten. Mach im Homeverzeichnis ein Bastel Verzeichnis und darin ein tomount Verzeichnis. Dann erstellst du mit mknod ein device das die selben major/minor Nummern trägt wie z.b. deine /home Partition. Nun kannst du das Ding einfach nach "tomount" mounten:

 *Quote:*   

> 
> 
> Welches Device ist meine /home Partition?
> 
> fil1 bastel # mount|grep home
> ...

 

Lieber Gruss

STiGMaTa

----------

## Erich

 *ModellbahnerTT wrote:*   

> @musv Kernel habe ich nach boot kopiert und den Treiber habe ich fest mit einkompiliert. Also sollte er geladen werden.
> 
> ModellbahnerTT

 

Gib mal folgendes ein:

 *Quote:*   

> # find /lib/modules/<kernel>/ -type f -iname '*.o' -or -iname '*.ko'

 

Dort siehst du alle Module die geladen wurden.Das Modul "8139too" Interesiert dich.Sollte es nicht dort auftauchen,musst es händisch laden.

 *Quote:*   

> modprobe 8139too

 

Mach mal dieses und melde dich wieder.

----------

## ModellbahnerTT

@Erich Modul wird geladen als 8139too.ko.

@STiGMaTa_ch 

```
ifconfig -a
```

 bringt wirklich nur lo als Device.

```
grep -v "#" /etc/conf.d/net
```

 gibt mir die folgenden zwei Zeilen 

```
config_eth0=( "192.168.0.2" )

routes_eth0=( "default via 192.168.0.1" )
```

Was mir gerade aufgefallen ist das die Tastatur noch auf englisch eingestellt ist. Wie kann das auf deutsche Tastaturlayout umstellen?

ModellbahnerTT

----------

## Erich

 *ModellbahnerTT wrote:*   

> 
> 
> Was mir gerade aufgefallen ist das die Tastatur noch auf englisch eingestellt ist. Wie kann das auf deutsche Tastaturlayout umstellen?

 

```
#loadkeys de-latin1
```

----------

## Erich

 *ModellbahnerTT wrote:*   

> 
> 
> ```
> grep -v "#" /etc/conf.d/net
> ```
> ...

 

Also,da liegt schon mal der Hund begraben.

config_eth0=(  ">Netzwerkkarte in deinem Pc> netmask 255.255.255.0 brd  192.168.0.255"  )

routes_eth0=(  "default gw  >hier die IP-Adresse vom Router>" )

EDIT

Netzwrkkarte im Pc,meine ich,die IP-Adresse.Last edited by Erich on Sun Oct 22, 2006 12:30 pm; edited 1 time in total

----------

## ModellbahnerTT

@Erich Das umstellen des Tastaturlayouts hat geklappt  :Very Happy: .

Aber die Änderung in der /etc/conf.d/net hat leider nicht funktioniert.  :Sad:  Die Fehlermeldung:

```
network interface eth0 does not exist 

Please verify hardware or kernel module (driver) 

ERROR: Problem starting needed service net.eth0 

netmount was not started. 
```

 bleibt leider weiter bestehen.  :Shocked: 

ModellbahnerTT

----------

## Erich

 *ModellbahnerTT wrote:*   

> @Erich Das umstellen des Tastaturlayouts hat geklappt .
> 
> Aber die Änderung in der /etc/conf.d/net hat leider nicht funktioniert.  Die Fehlermeldung:
> 
> ```
> ...

 

Das Netzwerk beim Systemstart haste aktiviert?

```
# rc-update add net.eth0 default
```

----------

## mv

 *STiGMaTa_ch wrote:*   

>  *Quote:*   [...]Das würde aber bedeuten, dass der Kernel bereits alle für root=xxx möglichen Devices kennen müsste? Er müsste also beispielsweise wissen, welche major/minor device nodes /dev/hdc11 oder /dev/sda[...] 
> 
> Naja, wenn der Kernel die nicht kennt, WER DANN??  
> 
> Im Ernst, natürlich kennt er die alle! /dev/hdc11 ist IMMER ein Blockdevice mit der Major Nummer 22 und der Minor Nummer 11. Welche Major/Minor Kombination welches Device anspricht ist in /usr/src/linux/Documentation/devices.txt reglemeniert.

 

Da gab es wohl ein Missverständnis: Dass der Kernel anhand der Major/Minor-Device-Nummern (und nur anhand dieser) das physikalische Device ermittelt, daran hatte ich keinen Zweifel. Nur, dass auch eine Tabelle der Art "/dev/hdcxx = Major 22, Minor xx" im Kernel enthalten ist - für die es ja außer zum richtigen Interpretieren der Kommandozeile beim Booten keinen Bedarf gibt, weil das ja später von udev erledigt wird - das ist das, was mich erstaunt hat.

 *Quote:*   

> Namen sind für Ihn nur Schall und Rauch die Nummern sind wichtig. Und da jede Major/Minor Nummer gerade mal von 0 - 255 (also 256 Möglichkeiten) reicht, muss der Kernel eine Liste von maximal 65536 Einträgen kennen. Diese 64KB fressen nicht viel Platz 

 

Aber an diese Nummern muss der Kernel eben alleine durch die Information der Kommandozeile "root=/dev/hdc11" kommen: Er braucht also nicht nur eine Tabelle von 64KB, sondern auch eine bestehend aus 65536 Strings (auch wenn sicher nicht alle belegt sind und sich ggf. einiges "logisch" zusammensetzen lässt [wie etwa, dass in vielen Fällen die Minor-Number im Namen enthalten ist]) - auf diese (Devicename -> major/minor) Tabelle, und deren anscheinend doppeltes Enthaltensein in udev und Kernel bezog sich mein Erstaunen. Aber wenn ich Dich richtig verstehe ist das tatsächlich so. Der ganze Speicherbedarf nur, damit man beim Booten kein initramfs braucht...

----------

## musv

 *ModellbahnerTT wrote:*   

> @musv Kernel habe ich nach boot kopiert und den Treiber habe ich fest mit einkompiliert. Also sollte er geladen werden.

 

 *ModellbahnerTT wrote:*   

> @Erich Modul wird geladen als 8139too.ko

 

Hä? Haste den Treiber jetzt nun fest reincompiliert (also mit *) oder als Modul (M)??? Wenn du das in den Kernel festreincompiliert hast, dann wird das am Anfang beim Booten angezeigt. Gibt einfach mal ein:

```
dmesg | less
```

Und such dann, ob da Deine Netzwerkkarte auftaucht. Falls du das als Modul compiliert hast, dann kannst du das Teil mit "modprobe 8139too" laden.

Und wenn du modprobe 8139too eingibst und das Modul geladen wird (was du ja eigentlich fest reincompiliert hast), wie lauten dann die letzten Zeilen von dmesg?Last edited by musv on Sun Oct 22, 2006 12:41 pm; edited 2 times in total

----------

## ModellbahnerTT

@Erich Ja das Netzwerk läuft. Die gepostet Fehlermeldung kommt ja auch beim Startvorgang. Ein 

```
ping 192.168.0.2
```

 bringt die Fehlermeldung: 

```
connect: Network is unreachable
```

Weitere Frage wo muss ich

```
loadkeys de-latin1
```

in die Scripte eintragen damit ich beim booten immer gleich deutsches Tastaturlayout habe?

ModellbahnerTT

----------

## musv

http://www.gentoo.org/doc/de/guide-localization.xml

http://de.gentoo-wiki.com/Deutsche_Lokalisierung

D.h. entscheide Dich, ob du UTF-8 oder ISO haben willst.

Eigentlich solltest du aber die Sachen schon kennen. Schließlich wurde die Installation nicht zum Spaß geschrieben.

Also RTFM!!!

----------

## ModellbahnerTT

@musv Da hast du recht. Ich werde mir jetzt nochmal die deutschen Anleitungen durchlesen. Ich habe gedacht wenn man sich die englischen durchgelesen reicht das und irgendwo habe ich hier mal gelesen das die englischen Anleitungen aktueller sein sollen.

ModellbahnerTT

----------

## Erich

 *ModellbahnerTT wrote:*   

> 
> 
> Weitere Frage wo muss ich
> 
> ```
> ...

 

Solange bei dir der X-Server noch nicht läuft,musst du die immer am Anfang händisch Eintragen.Wenn der mal läuft,dann kannste nach dem oberen Link gehen.

Edit

Was sagt der Befehl:

```
netstat -nr
```

----------

## nikaya

 *ModellbahnerTT wrote:*   

> 
> 
> Weitere Frage wo muss ich
> 
> ```
> ...

 

In die /etc/conf.d/keymaps:

```
# /etc/conf.d/keymaps

# Use KEYMAP to specify the default console keymap.  There is a complete tree

# of keymaps in /usr/share/keymaps to choose from.

KEYMAP="de-latin1-nodeadkeys"
```

----------

## ModellbahnerTT

@Erich 

```
netstat -nr
```

gibt mir folgende Meldung aus:

```
Destination: 127.0.0.0

Gateway: 0.0.0.0

Genmask: 255.0.0.0

Flags: U

MSS: 0

Window: 0

irtt: 0

lface: lo

```

ModellbahnerTT

----------

## Erich

[quote="ModellbahnerTT"]@Erich 

```
netstat -nr
```

gibt mir folgende Meldung aus:

```
Destination: 127.0.0.0

Gateway: 0.0.0.0

Genmask: 255.0.0.0

Flags: U

MSS: 0

Window: 0

irtt: 0

lface: lo

```

Hmmm,da fehlt ne menge zeugs.Bei mir gibt es folgendes:

```
pingu erichgentoo # netstat -nr

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo

0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0

```

Solange es bei dir nicht so aussieht,geht nichts.

Also ich bin mit meinem Latein am ende.Was du noch versuchen kannst,den Genkernel zu Installieren.Aber du schreibst ja weiter oben,dass es nicht geht.

Versuch noch mal im Kernel:

Network device support -->

<*> Dummy net driver support

----------

## mv

 *Erich wrote:*   

> Also ich bin mit meinem Latein am ende.

 

Dass die ganzen Routing-Tabellen fehlen, ist nicht erstaunlich, weil die ganzen Skripte, die sie erstellen sollten, schon abbrechen (müssen), wenn es das interface eth0 nicht gibt. Die Schlüsselfrage ist: Warum richtet der Kernel kein eth0-interface ein, also warum erkennt er die Ethernet-Hardware nicht? Sagt dazu "dmesg |grep -3 eth0" oder "dmesg| grep -3 natsemi" unmittelbar nach dem Booten etwas?

Es ist jetzt nicht ganz klar geworden, ob der Ethernet-Treiber als Modul oder direkt in den Kernel einkompiliert wurde. Falls als Modul, hast Du dann auch wirklich "modprobe natsemi" ausgeführt (bzw. natsemi in /etc/modules.autoload.d/kernel-2.6 eingetragen)? Kommt nach "modprobe natsemi" vielleicht eine Fehlermeldung (ev. in den logfiles oder in dmesg)?

----------

## STiGMaTa_ch

@ModellbahnerTT

Sorry, aber langsam wird das sehr wirr hier. Wie kommt Ihr Leute darauf, dass 8139too der Treiber für die National Semiconductor Netzwerkkarte sei? Wenn schon, dann muss ein modprobe natsemi gemacht werden. Denn für die angegebene Karte ist DAS der Treiber.

Wenn das nicht klappt, dann muss halt die Holzhammer Methode herhalten. Boote dein Gentoo mit dem Genkernel. Führe dann folgendes Script aus:

```
for a in `find /lib/modules/\`uname -r\`/kernel/drivers/net -name "*.ko"`;do modprobe `basename $a|cut -d "." -f1`;done
```

Dies macht nichts anderes als alle Treiber die im net Verzeichnis zu finden sind zu laden. Schau dann mit 

```
ifconfig -a
```

 nach ob nun immer noch nur lo vorhanden ist. Wenn nein, dann musst du nur noch herausfinden, welcher der geladenen Module für deine Karte zuständig ist.

Entlade einfach ein Modul nach dem anderen und überprüfe dann jeweils mit ifconfig -a ob eth0 noch vorhanden ist. Wenn es verschwunden ist, dann war das eben entladene Modul dein gesuchter Treiber.

Falls jedoch auch nach dem laden aller Module kein eth0 vorhanden ist, dann hast du pech gehabt. Entweder wird deine Netzwerkkarte nicht unterstützt oder das Ding ist so neu, dass der entsprechende Treiber (z.B. natsemi) dieses Modell einfach nicht kennt. Wenn die Karte nicht unterstützt wird musst du halt eine neue Netzwerkkarte kaufen und diese nutzen. Im anderen Fall kann es sein, dass der Hersteller einen Kernelpatch anbietet welchen du einfach nach dessen Anleitung installieren musst.

Diesen gepatchten Kernel kannst du dann auch in genkernel verwenden.

@mv

 *mv wrote:*   

> [...]Nur, dass auch eine Tabelle der Art "/dev/hdcxx = Major 22, Minor xx" im Kernel enthalten ist[...]

 

Im Kernel ist auch keine solche Tabelle enthalten, weil sich der Kernel nicht für den Devicenamen interessiert. Er muss nur wissen, dass bei Aufruf eine Blockdevices mit der Major Nummer 22 sein MFM/RLL/IDE Subsystem angesprochen ist. Das bedeutet, Er verwaltet eher eine Liste in der steht: Bei Major 3 sende Anfragen ans Subsystem IDE, bei Major 22 sende Anfragen ans Subsystem IDE etc.

 *Quote:*   

> [...]für die es ja außer zum richtigen Interpretieren der Kommandozeile beim Booten keinen Bedarf gibt, weil das ja später von udev erledigt wird - das ist das, was mich erstaunt hat.

 

Es geht hier doch nicht nur im die Interpretation von /dec/hdc12 beim booten. Der Kernel MUSS eine Liste aller Major/Minor Nummern kennen um Zugriffe an das richtige Subsystem im Kernel weiterleiten zu können. Diese Subsysteme haben mit udev herzlich wenig zu tun. Denn udev sorgt nur dafür, dass wir Menschen für Devices einen Namen haben. Wie dieser Name nun lautet ist völlig irrelevant und nur für uns Menschen wichtig. Der Kernel muss aber immer und zu jedem Zeitpunkt wissen welches Subsystem nun gerade gemeint ist.

Von daher gibt es keine "doppelte Liste" sondern es gibt einfach nur eine. Und zwar die im Kernel. Und diese würde auch ausreichen. Da wir Menschen aber schon Probleme damit haben sowas wie http://209.85.129.104 (http://www.google.com) zu merken und ganz bestimmt auch unsere liebe Müh und Not mit "Mein Device Major 22 Minor 12 wird nich gemountet" hätten, gibt es halt die Devicenamen. Diese "Redunzanz" wie du es nennst findest du in der Informatik aber an allen Ecken und Enden. (z.b. bei jede Programmiersprache (auch Assembler), DNS etc.).

Also nochmals kurz zusammengefasst.

- Der Kernel verwaltet einfach gesagt nur eine Liste. Nämlich diejenige welches Subsystem bei entsprechender Major/Minor Kombination angesprochen werden muss.

- Udev macht nichts weiter als diese Major/Minor Kombinationen für uns verständlich abzubilden. Da nun aber Programme ebenfalls von Menschen konfiguriert werden und diese halt /dev/hdc11 verwenden muss /dev/hdc11 einem Block Device mit Major 22 Minor 11 entsprechen. Aber wer ein Schelm ist könnte /dev/hdc11 auch einfach die Major 3 Minor 11 geben. Nur dann wird damit im Kernel effektiv auf die elfte Partition der ersten Harddisk des ersten IDE Interfaces zugegriffen (für Menschen verständlicher hda11) und nicht auf die elfte Partition der ersten Harddisk des zweiten Interfaces (hdc11).

Lieber Gruss

STiGMaTa

----------

## mv

 *STiGMaTa_ch wrote:*   

> modprobe natsemi

 

Davon sprach ich doch in meinem letzten Posting!? (Vermutlich eine zeitliche Überkreuzung unserer Postings - Du hast Deines vermutlich gerade getippt, als ich meines abgesendet habe).

 *STiGMaTa_ch wrote:*   

> Im Kernel ist auch keine solche Tabelle enthalten, weil sich der Kernel nicht für den Devicenamen interessiert. [...] Es geht hier doch nicht nur im die Interpretation von /dec/hdc12 beim booten.

 

Aber gerade diese Interpretation ist es, wegen der eine solche Liste im Kernel selbst existieren muss: Der Kernel bekommt ja vom loader nur die Information "root=/dev/hdc12" (keine Major/Minor-Nummern dieses Devices!) - und muss daraufhin (wenn ich Deine Aussage richtig verstanden habe), ohne dazu auf ein Skript oder udev rückgreifen zu können, das tatsächliche /dev/root aus dieser Information ermitteln, um von dort init laden zu können. Also müssen sowohl der Kernel als auch udev in der Lage sein, selbständig die Zurdnung "device-name <-> (major,minor)" zu kennen: Der Kernel (beim Booten) in die Richtung "->", um den ascii-Text "root=/dev/hdc12" richtig interpretieren zu können, und udev (zu einem späteren Zeitpunkt) i.W. in die Richtung "<-", um /dev/ vernünftig zu füllen. Also muss es doch zwei Listen geben!?

----------

## STiGMaTa_ch

 *mv wrote:*   

>  *STiGMaTa_ch wrote:*   Im Kernel ist auch keine solche Tabelle enthalten, weil sich der Kernel nicht für den Devicenamen interessiert. [...] Es geht hier doch nicht nur im die Interpretation von /dec/hdc12 beim booten. 
> 
> Aber gerade diese Interpretation ist es, wegen der eine solche Liste im Kernel selbst existieren muss:

 

Schon mal daran gedacht, dass Grub/Lilo etc. diese Transformation selbständig vornehmen könnten und dem Kernel nur noch major/minor mitteilen müssen ? Wie gesagt, denke nicht wie ein Mensch sondern wie ein Computer. /dev/hdc11 ist viel zu viel Information (10 Byte um genau zu sein) da ist man mit 22 11 (2 byte) doch viel schneller und muss erst noch nichts umwandeln  :Wink: 

Lieber Gruss

STiGMaTa

----------

## mv

 *STiGMaTa_ch wrote:*   

> Schon mal daran gedacht, dass Grub/Lilo etc. diese Transformation selbständig vornehmen könnten und dem Kernel nur noch major/minor mitteilen müssen?

 

Natürlich. Aber ich habe das sofort wieder ausgeschlossen, weil ich in Erinnerung habe, dass an irgendeiner Stelle der Grub-Dokumentation ausdrücklich stand, dass Grub anders als andere Bootloader die Kernel-Kommando-Zeile uninterpretiert an den Kernel übergibt. Bei kurzem Überfliegen des Grub-Sourcecodes sticht mir jetzt auch nichts ins Auge, was nach einer Interpretation von "root=" aussehen könnte: zumindest ein

```
grep  -R '\"root' *
```

 liefert nichts, was damit zusammenhängt.

----------

## STiGMaTa_ch

Lass es jetzt gut sein mv...

Das hier sollte keine Diskussion darüber werden wie der Kernel nun im Detail jedes einzelne Bit dreht sondern sollte dir klarmachen, dass man keine initramfs benötigt um die root Partition booten zu können.

Wenn du wirklich wissen willst, wie jedes Bit gedreht wird, dann lies den Kernel Source Code. Was ich bisher geschrieben habe ist nur vereinfacht ausgedrückt um das Prinzip verständlich zu machen. 

Lies dir halt mal /usr/src/linux/init/do_mounts.c durch. Besonders ab hier siehst du, was dich interessiert:

 *Quote:*   

> *
> 
>  *      Convert a name into device number.  We accept the following variants:
> 
>  *
> ...

 

Lieber Gruss

STiGMaTa

----------

## mv

 *STiGMaTa_ch wrote:*   

> Lies dir halt mal /usr/src/linux/init/do_mounts.c durch.

 

Danke sehr! Nach dieser Stelle hätte ich lange gesucht. Jetzt wird Etliches klarer.

Vielen Dank für Deine geduldigen Erklärungen!

----------

## Bithammer

Wow das war sehr einleuchtend erklärt Stigmata - das nenne ich mal kompetente Hilfe   :Exclamation: 

Zusätzlich noch mit dem netten trick die module für das Netzwerk interface zu laden ist ne super idee und sehr hilfreich.

----------

## smog_at

Hey @all,

würde mich gerne diesem Thread anschließen. Ich habe einen 2.6er kernel installiert und will auf einen 2.4er zurücksteigen (wegen Raid) Hier wird mir dann gesagt das das kompilieren eines 2.4er kernels nicht mit einem gcc >= 4.0 geht.

Nun wollte ich eine ältere Version parallel laufen haben und habe bisher alle gcc <4.0 versucht zu kompilieren, jedoch geht kein einziger in Ordnung. Ich bekomme nur Fehler. Mache ich Grundsätzlich was falsch oder hat das mit der Kompatibilität zu tun?

Lg smog_at

----------

