Mein selbstkompilierter Kernel macht /dev/sda zu /dev/hda

[HardHat]

Hi,

habe jetzt mal Etch installiert und bin aboslut begeistert. Nun wollte ich einen eigenen Kernel bauen. Ich habe den aktuellen von kernel.org gezogen, dann die /boot/config vom installierten Debian-Standardkernel mit oldconfig übernommen und habe ohne weitere Änderungen den neuen Kernel gebaut und installiert (nach /boot kopiert, in grub eingetragen usw.).

Wenn ich nun versuche den zu starten, lande ich im Systemverwaltungsmodus, weil fsck die Partitionen nicht checken kann. Der Grund, warum das nicht klappt, liegt darin, dass udev im /dev Verzeichnis für meine SATA-Platten nun aufeinmal die Gerätedateien /dev/hda statt wie mit dem Debian-Standardkernel /dev/sda angelegt hat.

Ist das irgendein neues Kernelfeature, was von 2.6.18 bis 2.6.21 dazu gekommen ist? Wenn ja, würd' ich das dringend abschalten wollen. Wenn nein - ??? was dann?

Danke für eure Tipps..
Hardhat

[Django]

ab 2.6.19 wird SATA nicht mehr über scsi sprich sda eingebunden sondern hda

[KBDCALLS]

Das das überhaupt so funktioniert hat , da hast du Glück gehabt, Denn im Kernel 2.6.19 hat es massive Änderungen gegeben die allerdings noch nicht ganz abgeschlossen sind. IDE und SATA sind von ihren alten Plätzen in eine neues Verzeichnis ata Umgezogen. Sata ist schon komplett aus dem SCSI Baum verschwunden, PATA exitiert im neuen Verzeichnis und noch an der alten Stelle. Einige Pata Treiber sind noch als experimetal gekennzeichnet.

[KBDCALLS]

ab 2.6.19 wird SATA nicht mehr über scsi sprich sda eingebunden sondern hda

Wer sagt das denn ?

Code: Alles auswählen

uname -a 

Linux biljana 2.6.20-1-k7 #1 SMP Wed Apr 25 10:55:45 UTC 2007 i686 GNU/Linux

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         608     4883728+  83  Linux


Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          61      489951   83  Linux

Disk /dev/sdc: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       19457   156288321   83  Linux

Disk /dev/hdc: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes      

   Device Boot      Start         End      Blocks   Id  System
/dev/hdd1               1       19457   156288321   83  Linux
  

Im Gegenteil es ist genau andersrum.

Der Kernel von Ubuntu nutzt die Libata Treiber und macht aus /dev/hd** > /dev/sd**

Und die CD/DVD Laufwerke wechseln von /dev/hd* nach /dev/sr* bzw /dev/scd* /dev/sg*

[HardHat]

Oha.. das bedeutet in diesem Fall also, dass ich den Standard Debian Kernel und meinen selbstkompilierten Kernel nicht wahlfrei booten kann, ohne jedes mal vorher die /etc/fstab anzupassen

[Teddybear]

Also ich würde mir an deiner Stelle die Config mal genauer betrachten.
Vielleicht ist irgendwas Aktiviert worden was die SATA Platten als IDE emulierte einrichtet.
Zumindest gibt es da auch irgend ne Funktion/Modul im Kernel der sowas handelt, und daran denke ich mal wird es liegen.

Eventuell könnte es

Code: Alles auswählen

CONFIG_BLK_DEV_IDE_SATA

sein

greetz Sascha

[HardHat]

Hmm.. also CONFIG_BLK_DEV_IDE_SATA habe ich mir angesehen und das ist sowohl in meinem Kernel als auch im Debian-Stanardkernel "NOT SET", also wohl nicht aktiviert.

[KBDCALLS]

Oha.. das bedeutet in diesem Fall also, dass ich den Standard Debian Kernel und meinen selbstkompilierten Kernel nicht wahlfrei booten kann, ohne jedes mal vorher die /etc/fstab anzupassen

Nicht ganz.

Ändere die fstab und den Grub so ab das nach /dev/disc/by-uuid gebootet wird.

Die /etc/fstab sieht dann so aus

Code: Alles auswählen

/dev/disk/by-uuid/f7ecbf76-a8f9-45e8-bef4-77b46b9c29f6 /               ext3            defaults,errors=remount-ro 0

usw.

Und Grub die die #kopt Zeile sieht dann so aus.

Code: Alles auswählen

# kopt=root=/dev/disk/by-uuid/f7ecbf76-a8f9-45e8-bef4-77b46b9c29f6 vga=7 ro

Dann update-grub nicht vergessen und fertig biste mit der menu.lst

Dann brauchst du dir um die wirklichen Devices keine Kopp mehr machen.

Man muß sich nur einmal die Arbeit dann machen.

PS: Damit das funktioniert wird mindestens Udev 101-3 Vorausgesetzt. Bei Etch ist das ja gegeben.

Und hier ist ein Link aus dem Archlinuxwiki.

http://wiki.archlinux.org/index.php/Per ... ice_naming

[HardHat]

Klasse, das habe ich gemacht und es funktioniert auch. Scheint aber für meine Swap Partition nicht zu funktionieren, da es diese UUID wohl nur bei ext2/3 Dateisystemen gibt, aber nicht auf Swap Partitionen. -> schade eigentlich, jetzt kann ich zwar beide Kernelversionen abwechselnd booten, ohne Änderungen an der fstab machen zu müssen, aber eine von beiden ist dann immer ohne swap.

Da gibt's nicht zufällig auch noch so einen netten Trick für??

[KBDCALLS]

Eigentlich müßte es auch bei swap gehen. Wenn ich mit mkswap ne Swappartion anlegen dann wird der Partiton auch ne UUID verpasst. Ich seh mir das gerade mal an.

[KBDCALLS]

Geht auch mit Swap. Gibt zwar momentan dabei noch ne Fehlermeldung, prinzipiel gehts aber.

[HardHat]

Ich habe bei meiner Swap Partition allerdings das Problem, dass die nicht /dev/disk/by-uuid/ auftaucht. Das heisst ich kenne die UUID gar nicht. Das gleiche ist mir übrigens auch bei der FAT Partition von meinem USB Stick aufgefallen. Die wird dort auch nicht angezeigt. In dem von dir verlinkten Artikel hab ich gesehen, dass es für FAT und NTFS auch UUIDs geben soll (wenn auch kürzer). Gibt's noch eine andere Möglichkeit, die UUID einer Partition auszulesen? Also irgendein Userspace Tool vielleicht?

[KBDCALLS]

Wenn man ne neue Swappartiton initialiesiert mit mkswap dann kriegt sie automatisch eine. Nen Label ist auch möglich. Das muß aber extra angegeben werden.

Kann man blkid überprüfen

http://nopaste.debianforum.de/5834