Das Problem ist folgendes: die Rootpartition lässt sich nicht mehr per 'mount -n -o remount,rw' remounten. Da kommt die Fehlermeldung:
/mnt/hdb3 already not mounted or bad option. Das passiert mit kernel 2.4.20 und 2.4.18. Per knoppix lässt sich aber die Partition mounten und auch schreiben und fschecken (ext3), das bootbit ist gesetzt.
(für Voreilige: an der fstab liegt es definitiv nicht)
Weiss jemand rat?
weedy.
Das Problem ist gelöst. Es lag doch an der fstab aber nicht dort, wo man vermuten würde. Ich hatte am Ende der fstab folgende Zeile stehen:
/ /mnt/hdb3 none bind,defaults 0 0
d.h.
/ wird auf /mnt/hdb3 gemappt. Nun ist es so, dass der Kernel das
Rootfilesystem per default erstmal readonly mountet. In dem Script
/etc/init.d/checkroot.sh wird fas rootfilesystem auf fehler gecheckt und im Anschluss per 'mount -n -o remount,rw' auf readwrite gesetzt.
Nun hat aber mount die Eigenart sowohl device als auch dir zu behandeln (siehe manpage: mount [-fnrsvw] [-o options [,...]] device | dir) und errät praktisch, was das richtige sein soll. /dev/hdb3 ist eindeutig ein Device, /mnt/hdb3 ein Directory, aber / ist aus der einen Sicht (/dev/hdb3 / ext3 defaults 0 1) ein Directory und aus der anderen Sicht( / /mnt/hdb3 none bind,defaults 0 0) das Device. Da mount sich im vorliegenden Fall für das Device entscheidet schlägt das remount fehl und es kommt zu der merkwürdigen Fehlermeldung: '/mnt/hdb3 already not mounted or bad option' oder '/mnt/hdb3 is busy'.
Also liegt der Fehler wieder in einem Rate-Automatismus.
Soweit ich mich erinnern kann, haben Automatismen schon
immer eine beträchtige Rolle bei der Fehlersuche gespielt.
Nagut, bisher konnte ja ein Directory nie als Device herhalten, aber
mit der einführung von 'mount --bind' schon. Also gilt für die Zukunft:
keine Automatismen.
weedy.