HD-Probleme nach Board- bzw. Chipsatzwechsel
Hallo Liste, ich habe einen kleinen SBC, an dem eine Platte hängt, auf der wiederum 3 verschiedene Linux-Varianten installiert sind. Die Platte ist die erste im System und wie folgt organisiert: hda1 -> 15 GB primär, ext3 -> Ubuntu 5.0x mit Kernel 2.6.8 hda2 -> 256 MB primär, ext3 -> ohne System hda3 -> 256 MB primär, ext3 -> DamnSmallLinux hda5 -> 512 MB swap hda6 -> 12 GB, ext3 -> SuSE 9.0 mit Kernel 2.4.21 Das eigentliche System ist DamnSmallLinux (DSL), und die ganze Platte ist nur "Entwicklungsplatte", da das DSL, wenn es fertig ist, auch z.B. von einer CF-Karte laufen soll, die dann als hdc eingebunden ist. Bisher hatte ich einen SBC mit VIA Epia Chip, aber diese Boards werden demnächst abgekündigt. Ich habe jetzt ein Board mit ULV Celeron bekommen und soll die Systeme da drauf bringen. Ich hab also (gottseidank) erstmal ein komplettes Image der Platte gezogen und weit weggestellt ;) Denn nach der ersten Euphorie, daß _alle_ Systeme quasi offthebox sofort wieder gelaufen sind, stellte sich schnell Ernüchterung ein: Jedesmal, wenn eins der Systeme irgendwas auf die Platte schreibt, kann ich den nächsten Bootvorgang vergessen, weil mindestens die Hälfte der Daten auf der entsprechenden Partition verschwunden ist. Das sieht dann z.B. bei SuSE 9 so aus, daß der Kernel selber noch geladen wird und anstartet, aber irgendwann beim Mounten des FS kommen dann Meldungen wie: VFS: Mounted root (ext3 filesystem) readonly Trying to move old root to initrd ... failed Unmounting old root [...] INIT: cannot execute "/etc/init.d/boot" INIT: Entering runlevel: 3 INIT: cannot execute "/etc/init.d/rc" INIT: cannot execute "/sbin/mingetty" INIT: cannot execute "/sbin/mingetty" INIT: cannot execute "/sbin/mingetty" INIT: cannot execute "/sbin/mingetty" INIT: ld "2" respawning too fast: disabled for 5 minutes INIT: no more processes left in this runlevel INIT: cannot execute "/sbin/mingetty" INIT: cannot execute "/sbin/mingetty" INIT: ld "1" respawning too fast: disabled for 5 minutes INIT: ld "2" respawning too fast: disabled for 5 minutes INIT: ld "3" respawning too fast: disabled for 5 minutes INIT: ld "4" respawning too fast: disabled for 5 minutes INIT: ld "5" respawning too fast: disabled for 5 minutes INIT: ld "6" respawning too fast: disabled for 5 minutes Das Ganze wiederholt sich natürlich dauernd. Die anderen beiden Systeme verhalten sich ähnlich. Bei einem Versuch, die SuSE-Installation von einem anderen System aus per fsck zu reparieren, gibt es unglaublich viele Fehler wie: Inode xyz1 war Teil der orphaned Inode-Liste Inode xyz2 hat unzulässige Blocks Inode xyz3, i_size ist 19316, sollte sein 0 und so weiter. Danach werden noch die ganzen Dateien neu zugeordnet und zum Schluss habe ich in lost&found 45 neue Verzeichnisse mit knapp 1000 Dateien. Woran kann das denn jetzt liegen? Zumindest bei den 2.4.x-Kernels sollte doch der neue Chipsatz (Intel statt Via) erkannt und eingesetzt werden? Und beim ersten Booten funktioniert auch alles, die Systeme laufen bis zum Shutdown problemlos. Erst wenn sie zum zweiten Mal gestartet werden sollen, geht nix mehr. Die Bios-Einstellungen, wie die Platte angesprochen wird (CHS, Large, LBA oder Auto) sollten doch Linux egal sein, oder nicht? Vielen Dank für alle Hinweise, mfG, Jens
Nachtrag: Der Chipsatz selber ist bei beiden Boards (alt und neu) eine Via Twister Chipsatz mit integr. S3 Grafik. Nur die Prozessoren, die NIC und die Soundchips sind unterschiedlich. mfG, Jens
Hallo, Am Thu, 22 Dec 2005, Jens Nixdorf schrieb:
Jedesmal, wenn eins der Systeme irgendwas auf die Platte schreibt, kann ich den nächsten Bootvorgang vergessen, weil mindestens die Hälfte der Daten auf der entsprechenden Partition verschwunden ist. [..] Die Bios-Einstellungen, wie die Platte angesprochen wird (CHS, Large, LBA oder Auto) sollten doch Linux egal sein, oder nicht?
Aber nicht zum Booten. Und es kann sein, dass einer der Kernel wg. dem anderen BIOS eine andere Platten-Geometrie raet als vorher. Und genau dann kann es weil die Partitionierung anders ist zu solchen Problemen kommen. => Im BIOS die korrekte Einstellung vornehmen wie du Partitioniert hast => Das bekommst du AFAIK mit fdisk -l raus, zur Not aber in dem du die Partitionstabelle im MBR selber ausliest und interpretierst: dd if=/dev/hda bs=1 count=64 skip=446 | od -t x1 Das gibt eine Ausgabe wie: 0000000 00 01 01 00 83 fe 3f 0c 3f 00 00 00 8e 2f 03 00 ^^ Sektoren 0000020 00 00 01 0d 82 fe 3f 4e cd 2f 03 00 c2 2d 10 00 0000040 00 00 01 4f 0f fe ff ff 8f 5d 13 00 32 2d 8e 12 0000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^^ ^^ ^^- untere 6bit: Sektoren [*] FS ^^- Koepfe [*] Falls groesser 3F dann perl -e 'print 0xYY & 0x3F;' mit YY die Ausgabe aus der gekennzeichneten Spalte. Bei mir sind es also 0xFE == 255 Koepfe und 0x3F == 63 Sektoren. Die Hexzahlen kannst du uebrigens mit echo 'ibase=16; FE' | bc nach dezimal umrechnen. => Allen Kernels die Einstellung ggfs. per Kernelparameter mitteilen: hda=<Zylinder>,<Koepfe>,<Sektoren> Zum booten, damit du die Grub menu.lst bzw. die lilo.conf anpassen kannst, ggfs. eben per Hand bei der Grub-Eingabe dazuschreiben. Bei LILO reicht's IIRC wenn du den Parameter einfach hinter dem Imagenamen angibtst ("boot> linux hda=..."). HTH, -dnh -- Typographisch ist das ja eh ein Griff in die Sanitäranlage... -- Malte Rosenau in dctt
Am Donnerstag, 22. Dezember 2005 23:28 schrieb David Haller:
dd if=/dev/hda bs=1 count=64 skip=446 | od -t x1
Das gibt eine Ausgabe wie:
0000000 00 01 01 00 83 fe 3f 0c 3f 00 00 00 8e 2f 03 00 ^^ Sektoren 0000020 00 00 01 0d 82 fe 3f 4e cd 2f 03 00 c2 2d 10 00 0000040 00 00 01 4f 0f fe ff ff 8f 5d 13 00 32 2d 8e 12 0000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^^ ^^ ^^- untere 6bit: Sektoren [*] FS ^^- Koepfe
Erstmal danke. Zum Thema: Köpfe und Sektoren habe ich halbwegs verstanden, aber wo holst Du die Anzahl der Zylinder her? Und was sind die "anderen Sektoren" in den unteren 6bit? Meine Partitionstabelle sieht wie folgt aus: 0000000 00 01 01 00 83 fe ff ff 3f 00 00 00 e7 f7 df 01 0000020 80 00 c1 ff 83 fe ff ff 26 f8 df 01 5f 99 07 00 0000040 00 00 c1 ff 83 fe ff ff 85 91 e7 01 63 94 08 00 0000060 00 00 c1 ff 05 fe ff ff e8 25 f0 01 58 18 8e 01 Ich gehe jetzt in meiner laienhaften Vorstellung davon aus, daß jede Zeile eine Partition darstellt, die ersten 3 sind die 3 primären Partitionen mit Linux (Typ 83) und die vierte ist die erweiterte Partition (Typ 05), danach in jeder Zeile die Köpfe (0xFE => 254), die Sektoren (0x3F => 63) aber nur in der ersten Zeile. Ganz nebenbei zur Befriedigung meiner Neugierde: Wieso sind eigentlich die Köpfe in jeder Zeile zu sehen, aber nicht die Sektoren? fdisk sagt, die Platte habe 9726 Zylinder, wenn ich das mal glaube, dann wären das in Hexadezimal 25FE, und das finde ich nirgends. Und fdisk sagt, die Platte hat 255 Köpfe, nicht 254 wie in der Partitionstabelle zu sehen ist.
=> Allen Kernels die Einstellung ggfs. per Kernelparameter mitteilen:
hda=<Zylinder>,<Koepfe>,<Sektoren>
Danke, ich werde das jetzt mal mit den Werten von fdisk versuchen, nachdem ich mein Backup zurückgespielt habe. Die Platte kommt per USB an meinen Arbeitsrechner, da kann ich schön die menu.lst bearbeiten... mfG, Jens
Am Freitag, 23. Dezember 2005 13:41 schrieb ich:
Danke, ich werde das jetzt mal mit den Werten von fdisk versuchen, nachdem ich mein Backup zurückgespielt habe.
Das wars leider nicht, das Problem besteht immer noch. Habe diesmal DamnSmallLinux gestartet und nach dem Booten genau 3 Dateien kopiert und 3 symlinks erstellt, und zwar im Verzeichnis /lib, aber beim nächsten Booten fehlt wieder die Hälfte aus /etc/init.d und /sbin mfG, Jens
Hallo Liste, das Problem ist (hoffentlich) gelöst, zumindest konnte ich heute auf die Platte schreiben lassen ohne Ende, und die Kiste bootet immer noch alle Systeme einwandfrei. Allerdings war das Ganze doch mit etwas Aufwand verbunden, ich musste von einem Live-System aus (Knoppix) eine zusätzliche Partition anlegen und dann alle Daten aus den einzelnen Partitionen dorthin schreiben (http://suse-linux-faq.koehntopp.de/q/q-filesystems-kopieren.html). Danach habe ich zuerst eins der Systeme (DamnSmallLinux) gebootet, die drei anderen Partitionen von da aus platt gemacht, neu formatiert und dann die Daten dieser drei Partitionen zurück geschrieben. Beim nächsten Booten blieb GRUB sofort nach Anzeige seiner vier Buchstaben stehen, obwohl seine Daten eigentlich wieder zurückgeschrieben waren (liegen in der SuSE-Partition). Also von der SuSE-CD gebootet, installiertes SuSE-System gestartet und GRUB neu in den MBR geschrieben. Danach funktionierte auch dieser wieder, obwohl mir schleierhaft ist, warum er das nicht vorher schon konnte. Wieder SuSE gebootet, nun das letzte System (DamnSmallLinux) plattgemacht und dann zurück geschrieben und den Rest des Tages mit Schreibübungen und Akkord-Booten verbracht. Bis jetzt läufts. Lange Rede, kurzer Sinn: Einfach Mainboard tauschen und HD unverändert lassen trotz fast gleichem Chipsatz muss nicht zwangsläufig eine gute Idee sein. Aber ein Backup ist definitiv eine gute Idee. mfG, Jens
participants (2)
-
David Haller
-
Jens Nixdorf