Aus dem Museum: libata

[brgs]

Hi.


Ich habe (immer noch) ein altes 600x, das seit ewigen Zeiten mit einem
2.4er Kernel läuft. Das ist auch nicht verhandelbar, weil es da einen
Treiber gibt, der nur auf dem Kernel läuft. Zusätzlich würde ich gerne
einen 2.6.32 Kernel benutzen, habe dann aber das Problem, daß wegen des
libata Treibers /dev/hda auf einmal /dev/sda heißt. Natürlich kann ich
dem Kernel sagen root=/dev/sda1, nur der fstab kann ich das nicht sagen.

Meine Optionen wären nun:

* den selbstgehäkelten Treiber der mich auf 2.4 festnagelt neu schreiben (wollte ich eigentlich nicht) und 2.4 nach ungefähr zehn Jahren doch noch pensionieren.

* UUIDS statt devicenamen (ungerne)

* 2 fstab, je eine für 2.4 und eine für 2.6. Das ist nicht das wahre, weil ich die umkopieren müßte während root noch ro gemountet ist.

* Ein eigenes mountscript bauen, das mount -at nodieses,nojenes nachbildet und die Anpassung dabei vornimmt. Das hatte Debian glaube ich mal, und es war [Schimpfwort] und konnte prima auf den Bauch fallen.

* Dem Kernel sagen er soll die alten ide Treiber benutzen. Das gefällt mir am besten, ich finde aber nicht raus, wie man das macht.


Vieleicht kann sich ja noch jemand erinnern, wie das ging,


Brgs

 

[blafoo]

Was spricht gegen uuids?

Grüsse

 

[brgs]

Was spricht gegen uuids?

Grüsse

Schlimme Erfahrungen! Ich kriege die Geschichte nicht
mehr auf die Reihe, obwohl sie bestimmt lustig war, auf
jeden Fall hatte ich mal eine ausgebaute Platte, Stress,
war eilig und mußte dann erst noch ausklamüsern welche
der halb kaputten Partitionen wohl /daten und welche /altedaten
gewesen war. Damals habe ich mich so aufgeregt, daß ich
seither immer brav die Device-Namen benutzt habe, auch wenn
das eigentliche Problem nicht unbedingt den UUIDs anzulasten
war.

Brgs

 

[SammysHP]

# blkid

Und du hast eine Zuordnung aller /dev/* und den IDs.

 

[jal2]

* Dem Kernel sagen er soll die alten ide Treiber benutzen. Das gefällt mir am besten, ich finde aber nicht raus, wie man das macht.

Bedeutet das nicht, dass Du nur selbstkompilierte Kernel benutzen kannst?

* den selbstgehäkelten Treiber der mich auf 2.4 festnagelt neu schreiben (wollte ich eigentlich nicht) und 2.4 nach ungefähr zehn Jahren doch noch pensionieren.

Was spricht dagegen? Welche Hardware bedient er? Kann er nicht nicht irgendwann mal in den offiziellen Kernel aufgenommen werden?

Gruss,
jal2

 

[brgs]

# blkid

Und du hast eine Zuordnung aller /dev/* und den IDs.

Nur dann, wenn das entsprechende Dateisystem das unterstützt und
die Superblöcke noch gesund sind. In meinem Fall waren dann auch
noch rohe Partitionen dabei. (Könnten CODA-Volumes gewesen sein)

Einen solchen Spezialfall habe ich heute noch:

# cat /proc/partitions 
major minor  #blocks  name

   3     0   78150744 hda
   3     1     987966 hda1
   3     2     987997 hda2
   3     3          1 hda3
   3     5   22121473 hda5
   3     6   16064968 hda6
   3     7   16064968 hda7
   3     8   21920661 hda8

# blkid
/dev/hda2: TYPE="swap" UUID="2efeb17d-920c-4631-bcad-42bf6dc78a27" 
/dev/hda5: UUID="815d93cb-34d2-45af-bf99-98cc7a0f77e7" SEC_TYPE="ext2" TYPE="ext3" 
/dev/hda6: UUID="99bdb1d1-5e2d-4ac1-95cc-13145ab70b96" TYPE="ext2" 
/dev/hda8: UUID="63aa3a3b-34c0-4e09-bc37-543c92ff6acb" SEC_TYPE="ext2" TYPE="ext3"

hda7 ist mein verschlüsseltes /home.


Brgs

 

[thorfdbg]

* Dem Kernel sagen er soll die alten ide Treiber benutzen. Das gefällt mir am besten, ich finde aber nicht raus, wie man das macht.

Kernel-Quellen von www.kernel.org herunterladen, und bei Debian (zumal) das kernel-package installieren. Dann den Kernel nach /usr/src entpacken, dort in die Kernel-Sourcen gehen und "make menuconfig" eintippen. Im Menü nach "Device Drivers" gehen, und in "Serial ATA and parallel ATA" die Treiber entfernen, die für das 600er nötig sind. Ich weiß nicht genau, welche das sind, lässt sich im 2.6er Kernel aber mit "lsmod" nachprüfen, was da geladen ist. Dann gibt es zwei Zeilen darüber "ATA/ATAPI/MFM/RLL Support", dies sind die alten Treiber, die sich mit hdX einhängen. Dort müsste der "Generic ATA disk support" und "generic/default IDE" eigentlich hinreichen. Vielleicht direkt hart in den Kernel eincompilieren, dann gibt's kein Geraffel mit der initrd. Ansonsten noch mal nach den Treibern direkt in der selben Kategorie gucken, ob etwas spezifisches für das Chipset des Lappies dabei ist.

Die Konfiguration dann abspeichern und einen neuen Kernel bauen:

make-kpkg linux-image --revision=<kernel-revision>-XXX --initrd

wobei die Version die Version des Kernels ist, und XXX eben Deine private Revisionsnummer. Fange bei 1 an und zähle hoch. Dabei heißt es dann warten, weil das Bauen auf antiker Hardware mal ganz schön dauert.

Als Resultat entsteht nach Stunden (no kidding!) ein ".deb" File eine Hierarchie höher. Das kann man dann als Superuser mit

dpkg --install kernel-image-XXXX.deb

installieren.

Hier sind ggf. mehrere Iterationen und ein Wochenende Arbeit notwendig, um alles herauszufinden, was man braucht. Ich würde auf alter Hardware dazu tendieren, in den Kernel nur handverlesene Module aufzunehmen und hier das Minimum von Komponenten zu nutzen, um das Gerät nicht unnötig zuzumüllen und um die Compilezeiten erträglich zu halten. Idealerweise kommt ein solcher Kernel dann ohne initrd aus und enthält die nötigsten Module fest im Kernel. Das sind üblicherweise der ATA-Treiber und das Dateisystem, sowie die Tastatur. Alles weitere kann als Modul vorliegen, das lädt der Kernel dann schon selbst.

 

[brgs]

Bedeutet das nicht, dass Du nur selbstkompilierte Kernel benutzen kannst?

Das will ich nicht hoffen, aber da beide Treiber im Kernel sind,
müßte es doch eine Auswahlmöglichkeit geben.

Was spricht dagegen? Welche Hardware bedient er? Kann er nicht nicht irgendwann mal in den offiziellen Kernel aufgenommen werden?

Gruss,
jal2

Der dient zur Anschaltung an ein Kommunikationsmodul. Den alten
Treiber hatte ich mal aus irgendeinem anderen Treiber gebastelt.
Inzwischen sind die Quellen verschollen und ich habe keine
Testhardware mehr.


Brgs

 

[linrunner]

Verstehe ich das richtig: nur weil dir einmal mit UUIDs ein Mißgeschick passiert ist, möchtest Du diese einfachste und zuverlässigste Lösung nicht nutzen? Cool .

ich habe keine Testhardware mehr.

Wenn Du die Hardware nicht mehr hast, wozu dann der Treiber?

 

[haarp]

Statt ner UUID kann man in der fstab auch mit LABEL=foo statt dem Devicenamen arbeiten. Vorrausgesetzt, das FS besitzt ein Label. Alternativ, je nachdem ob udev einigermaßen neu ist, Gibts unter /dev/disk/by-id/ auch Symlinks, mit denen man arbeiten kann.

 

[brgs]

(Kernel selbstbauen)

Danke für die Hinweise, darauf wird es wohl hinauslaufen, ich hatte ursprünglich
angenommen der Kernel könne beides, aber offenbar habe ich mich da getäuscht.

Ich habe schon den einen oder anderen Kernel selbst kompiliert, wollte aber
eigentlich anders vorgehen, nämlich mit einem fertigen Kernel anfangen, damit
das System ans Laufen bekommen und hinterher einen Kernel selbst bauen; sonst
weiß ich ja nie mit Sicherheit woran das liegt, wenn irgendwas nicht geht. Zu
2.1 Zeiten hatte ich z.B. plötzlich keine Maus mehr und habe nie rausgefunden
wieso.


Brgs

- - - Beitrag zusammengeführt - - -

Verstehe ich das richtig: nur weil dir einmal mit UUIDs ein Mißgeschick passiert ist, möchtest Du diese einfachste und zuverlässigste Lösung nicht nutzen? Cool .

Das ist weder einfach (Du guckst erst in die Partitionstabelle wo
eine Partition ist, dann guckst Du in die Partition wie sie heißt)
noch zuverlässig (Wenn Du einen fsck machen willst, aber der UUID
nicht lesbar ist hast Du ein Problem.) Weil das so ist, gibt es
ein cachefile, natürlich sowas wie XML, was das alles noch komplizierter
macht.

Wenn Du die Hardware nicht mehr hast, wozu dann der Treiber?

Die Hardware hatte ich noch nie, ich hatte mal Testhardware.


Brgs

 

[blafoo]

Ja aber wozu brauchst du dann den Treiber?!