libata (gelöst)

[guennid]

Wer oder was ist das?

Ich versuche gerade im Zuge des Upgradens auf squeeze auf alter hardware mit IDE-Platten von hda weg und zu sda hinzukommen und vermute, dass ich das im Betreff genannte bei einem angepassten eigenen Kern brauchen werde.
Das upgrade habe ich hinter mir, wie erfolgreich, muss sich noch zeigen.
Unter dem Standard-Kern 2.6.32-5-686 liefert mir lsmod:

Code: Alles auswählen

libata                115753  2 ata_generic,ata_piix

. In der config dieses Kerns finde ich aber kein libata.

Bauen will ich einen 2.6.36.2 er.

Grüße, Günther

[edit:]
lspci --nn:

Code: Alles auswählen

00:00.0 Host bridge [0600]: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub [8086:1130] (rev 11)
00:01.0 PCI bridge [0604]: Intel Corporation 82815 815 Chipset AGP Bridge [8086:1131] (rev 11)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 03)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801BAM ISA Bridge (LPC) [8086:244c] (rev 03)
00:1f.1 IDE interface [0101]: Intel Corporation 82801BAM IDE U100 Controller [8086:244a] (rev 03)
00:1f.2 USB Controller [0c03]: Intel Corporation 82801BA/BAM USB Controller #1 [8086:2442] (rev 03)
00:1f.4 USB Controller [0c03]: Intel Corporation 82801BA/BAM USB Controller #1 [8086:2444] (rev 03)
00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801BA/BAM AC'97 Audio Controller [8086:2445] (rev 03)
00:1f.6 Modem [0703]: Intel Corporation 82801BA/BAM AC'97 Modem Controller [8086:2446] (rev 03)
01:00.0 VGA compatible controller [0300]: Trident Microsystems CyberBlade/XP [1023:9910] (rev 63)
02:08.0 Ethernet controller [0200]: Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller [8086:2449] (rev 03)
02:0d.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to Cardbus Bridge with ZV Support [1179:0617] (rev 31)
02:0d.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to Cardbus Bridge with ZV Support [1179:0617] (rev 31)

Gehe ich recht in der Annahme, dass sich die 5. Zeile (Intel Corporation 82801BAM IDE U100 Controller) auf meine IDE-Platte bezieht? Und was bedeutet das für die Module, die ich kompilieren muss unter

Code: Alles auswählen

 <*> Serial ATA and Parallel ATA drivers  --->

[rendegast]

Code: Alles auswählen

CONFIG_ATA=m
...
CONFIG_ATA_PIIX=m
...
CONFIG_ATA_GENERIC=m

Du könntest auch selbst in den Kconfig greppen.

[guennid]

Danke für die Antwort.

Du könntest auch selbst in den Kconfig greppen.

Bin dazu leider nicht fähig.

Alle genannten Module sind fest im Kern (6.36.2). Der Kern bootet bis zum Prompt durch, trotzdem erscheint unter /dev weder hda* noch sda* und udevd läuft nicht. Ich verwende bei dem selbstgebauten keine initrd.

Grüße, Günther

[rendegast]

Die Transferleistung besteht aus
CONFIG_ATA_PIIX=m
zu
CONFIG_ATA_PIIX=y

trotzdem erscheint unter /dev weder hda* noch sda* und udevd läuft nicht.

udev ist von Dir deaktiviert / entfernt?
/dev sollte von der Installation mit einer Reihe Standardeinträgen gefüllt sein
(bei suse waren das einige Tausend),
die Du ohne udev gegebenenfalls selbst anlegen mußt -> makedev.
(Darüber mountet udev ein zuerst leeres tmpfs.)

block-devices aktiviert?

[guennid]

CONFIG_ATA_PIIX=y

War mir klar.

udev ist von Dir deaktiviert / entfernt?

von mir nicht. Mit dem Standard-Kern läuft's

/dev sollte von der Installation mit einer Reihe Standardeinträgen gefüllt sein

Ist mir auch klar. Nur leider fehlen die entscheidenden

die Du ohne udev gegebenenfalls selbst anlegen mußt -> makedev

Das habe ich nicht vor.

Was ist mit dm_uevent? Wozu ist das gut? Brauch ich das?

Grüße, Günther

[edit:] Ich bin mit meinem Latein am Ende. Ich stell die komplette config des letzten Versuchs mal nach nopaste. Vielleicht findet ja jemand was. Essentiell: keine initrd!

[guennid]

Kann es sein, dass dieser libata/ata-Kram nur mit initrd funktioniert?

Es stellt sich für mich langsam so dar, dass ich bei Verwendung von libata/ata entweder auf angepasste Kerne ohne initrd (das würde ich als mittlere Katastrophe empfinden) oder auf den squeeze-Standard-Kern (mit initrd) verzichten muss. Beides zusammen scheint nicht zu funktionieren. Ist das so?

Hat denn hier niemand mehr IDE-Platten für's System?

Grüße, Günther

[rendegast]

Warum gehst Du nicht vom Positiv aus,
nimm die funktionierende Konfig des debian-Standard- oder des vanilla-Kernels.
Dann deaktiviere initrd, und wenn das funktioniert
deaktiviere erst dann Stück für Stück weitere Einheiten.

CONFIG_LOG_BUF_SHIFT=14
das ist wohl etwas älter, denn der Standardwert dieser Option bei diesem Kernel ist 17.

ohne initrd (das würde ich als mittlere Katastrophe empfinden)

naja

oder auf den squeeze-Standard-Kern (mit initrd) verzichten muss.

auf meinem P3-Notebook sind gelaufen 2.6.8 - 2.6.37 (darunter auch der squeeze) mit initrd.
Und ata_piix.
Es ist noch nicht in Flammen aufgegangen.

[guennid]

auf meinem P3-Notebook sind gelaufen 2.6.8 - 2.6.37 (darunter auch der squeeze) mit initrd.
Und ata_piix

Die laufen hier auch, der Witz ist doch: Es läuft nicht ohne!

... nimm die funktionierende Konfig des debian-Standard- oder des vanilla-Kernels. Dann deaktiviere initrd, und wenn das funktioniert, deaktiviere erst dann Stück für Stück weitere Einheiten

Das hatten wir schon mal und ich meine nach wie vor, dass das so ziemlich die aufwendigste Methode ist, die ich mir vorstellen kann - aber es ist eine, das sei zugestanden. Die ziehe ich in Betracht, wenn nichts mehr geht. Meine eigenen Kerne sind auf der vorhandenen hardware bisher auch immer glaufen und tun es auch jetzt noch - allerdings mit CONFIG_IDE. Es ärgert mich schon, dass ich in dieser doch eigentlich nicht besonders komplizierten Sache schon tagelang mit sqeeze nicht weiterkomme.

Im Grunde ist mir sowohl dieses libata-Gewürge als auch der Standard-Kern ziemlich schnuppe. Ich könnte mit CONFIG_IDE ganz gut leben. Ich möchte nur nicht in die Situation kommen in der debian in seiner unnachahmlichen Ignoranz tatsächlich ernst macht, IDE kassiert und ich dumm aus der Wäsche gucke.

Weiß jemand, ob libata die initrd zwingend voraussetzt?

[KBDCALLS]

Funktioniert den das Booten mit UUIDs überhaupt bei dir. Wie sehen die /etc/fstab und menu.lst des Grubs aus ?

[guennid]

Funktioniert den das Booten mit UUIDs überhaupt

Das ist doch alles sekundär. Ich habe noch keine UUID. udev will doch auch nicht. Und selbst wenn ich die UUIDs anderweitig feststellen würde, würde das doch wohl nichts nutzen, Denn soweit ich das bisher verfolgt habe, sind das doch auch nichts weiter als udev-links auf eben vom kernel generierte sda*, hda* etc.

Hat jemand Erfahrung mit ide-Patten, libata und initrd, in dieser Kombination!

Grüße, Günther

[edit:] gebootet wird mit lilo. grub-legacy hab' ich aber ebenfalls schon ausprobiert: same procedure.

[KBDCALLS]

Wie soll das überhaupt funktionieren wenn von UUIDs weder die Ftab noch die Menu.lst etwas weis? Welcher Kernel funktioniert denn ? Welche sind denn installiert ?

[cosmac]

hi,

jetzt hab' ich mal deine config mit meiner 35286 verglichen und die Ähnlichkeit ist verblüffend. Das einzige, was mir aufällt ist CONFIG_SYSFS_DEPRECATED=y. Das könnte dazu führen, dass udev oder das init-Script abbricht. Ansonsten glaube ich, dass irgendwer ein kaputtes /dev über das devtmpfs-/dev mountet. Was halbwegs zum abgebrochenen init-Script passen würde.

Wenn du keine wichtigen Daten auf der Platte hast, könntest du mal alle Partitionen außer "/" umounten, vielleicht lässt sich "/" auch read-only mounten. Und dann:

Code: Alles auswählen

umount /dev
ls /dev
reboot

Hat jemand Erfahrung mit ide-Patten, libata und initrd, in dieser Kombination!

hier laufen mindestens 5 Rechner mit libata, ide und ohne initrd. Und einer mit mit sata/ide-Mischung.

[guennid]

Sieht so aus, als ob cosmac wieder mal das Richtige getroffen hätte.

Es gibt außer swap nur die Root-Partition (/).
/ read only mounten? Da weiß ich nicht, wie das geht.
umount /dev wurde verweigert, ein anschließendes ls /dev zeigte das Gleiche, was vorher auch zu sehen war, jedenfalls habe ich unter der Vielzahl der Einträge keine Veränderung gesehen.

Dann habe ich spaßeshalber mount /dev eingegeben und siehe da: alles leer unter /dev, außer einem einsamen

Code: Alles auswählen

| ioctl

Dann habe ich rebootet, und was soll ich sagen: sda* ist vorhanden. lilo lässt sich endlich auch unter dem 36er Eigenbaukernel ausführen.
CONFIG_SYSFS_DEPRECATED ist jetzt draußen. Kompilation läuft. Mal schauen, wie's dann aussieht.

Grüße, Günther

[TRex]

read-only mounten kannst du mit

Code: Alles auswählen

mount / -o remount,ro

[guennid]

Es scheint nicht nur so, es ist jetzt offensichtlich in Ordnung. Selbst /dev/disk enthält die gewohnten Einträge, insbsondere KBDCALLS so geschätzten UUIDs , welches Verzeichnis cosmac völlig unbkannt ist, aber das liegt wohl daran, dass der auch ohned udev kann .

Danke an alle, die mitgewirkt haben und insbesondere an cosmac .

Hast du dich jetzt mit umount /dev verschrieben oder lag's vielleicht nur an CONFIG_SYSFS_DEPRECATED?

Kann mir jemand dieses verblüffende leere /dev genauer erklären?

Grüße Günther

[cosmac]

Hast du dich jetzt mit umount /dev verschrieben oder lag's vielleicht nur an CONFIG_SYSFS_DEPRECATED?

verschrieben nicht, man hätte "nur" die meisten Prozesse stoppen müssen, damit das umount funktioniert. Also wird's wohl eher letzteres gewesen sein, hoffen wir, dass es das wirklich war. Was sagt denn jetzt "cat /proc/mounts" zu /dev?

Kann mir jemand dieses verblüffende leere /dev genauer erklären?

nö, eigentlich dürfte "mount /dev" überhaupt nicht funktionieren, schließlich steht /dev nicht in der fstab und damit fehlt entweder das Filesystems oder das Verzeichnis.

Selbst /dev/disk enthält die gewohnten Einträge, insbsondere KBDCALLS so geschätzten UUIDs , welches Verzeichnis cosmac völlig unbkannt ist, aber das liegt wohl daran, dass der auch ohned udev kann .

Man glaubt es kaum, aber ich hätte auch gern UUIDs (naja, eher LABEL), natürlich ohne /dev/disk und udev, aber mit initrd! Aber ich bekomme nicht mal eine hello-world-initrd zum Laufen, da fehlt's sooo weit, und hier kann ich ja auch keinen fragen

[guennid]

32:

Code: Alles auswählen

~$ cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs rw,relatime,size=252660k,nr_inodes=63165,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/root / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec,relatime,devgid=106,devmode=664 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0

36:

Code: Alles auswählen

~$ cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,relatime,errors=remount-ro,barrier=0,data=ordered 0 0
devtmpfs /dev devtmpfs rw,relatime,size=10240k,nr_inodes=64391,mode=755 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec,relatime,devgid=106,devmode=664 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0

Das zu interpretieren bin ich nicht fit genug.

Grüße, Günther

[cosmac]

naja, so viel steckt da auch nicht dahinter, die Zeilen sind so ähnlich aufgebaut wie die /etc/fstab (Device bzw. Name, Verzeichnis, Typ, Optionen). Bei /dev steht im 3. Feld jetzt endlich "devtmpfs" und nicht mehr "tmpfs" oder so. Damit dürfte es bei /dev/sda usw. nun keine Ungereimtheiten mehr geben.

Interessant ist, dass hier bei der root-Partition auch kein normales Device auftaucht. Das erklärt wohl, warum der Rechner auch ohne /dev/sda1 gelaufen ist. Die root-Partition wird dem Kernel ja beim booten mit root=/dev/sda1 übergeben und intern nur unter "8,1" (major und minor ID) geführt. "sda1" ist nur ein Name und nur per Konvention (fast) immer der gleiche.