Verbindung zu Partitionen des Originalservers

[stebue]

Ich musste meinen (Web)Server vom Rescuesystem aus starten und habe nun
Probleme auf die Partition des Servers zuzugreifen. Im Wiki des Anbieters (Hetzner) habe ich gefunden:
cd /mnt> mkdir rescue
mount -o ro /dev/sda2 /mnt/rescue

Bei der Ausführung des Befehls erhalte ich die Fehlermeldung, dass ich das
Filesystem angeben muss. Ich finde jedoch weder ein sda2 noch ein hda2

Der Support des Anbieters hat mir dann mitgeteilt, dass meine Laufwerke wohl unter md1 (bzw. unter md0) anzusprechen seien. Ich habe dann folgende Befehle versucht:
mount /dev/md1 /mnt/rescue
mount /dev/md0 /mnt/rescue

Es kommt dann immer die Fehlermeldung, ich ich das Filesystem angeben müsse. Ich habe die Option -t mit ext3, ext2, ext und nfs versucht. Es klappt jedoch nicht. Entweder kennt er das Dateisystem nicht, erkennt es als falsches oder führt den Befehl zwar aus, aber unter /mnt/rescue finde ich dann doch nichts. Ich sollte Lese- und Schreibzugriff auf die Platte haben.

Was mache ich falsch? (Beim Googeln habe ich immer wieder Hinweise gefunden, welche die Option -t gar nicht benötigen. Erschwerend ist auch noch, dass ich das verwendete Filesystem nicht kenne.


Zur Information: Unter /dev finde ich:
> agpgart md2 ptyp3 stdout tty38 ttyp2
> console md20 ptyp4 tty tty39 ttyp3
> core md21 ptyp5 tty0 tty4 ttyp4
> cpu_dma_latency md22 ptyp6 tty1 tty40 ttyp5
> fb0 md23 ptyp7 tty10 tty41 ttyp6
> fd md24 ptyp8 tty11 tty42 ttyp7
> full md25 ptyp9 tty12 tty43 ttyp8
> hpet md26 ptypa tty13 tty44 ttyp9
> initctl md27 ptypb tty14 tty45 ttypa
> input md28 ptypc tty15 tty46 ttypb
> kmem md29 ptypd tty16 tty47 ttypc
> kmsg md3 ptype tty17 tty48 ttypd
> loop0 md30 ptypf tty18 tty49 ttype
> loop1 md31 ram0 tty19 tty5 ttypf
> loop2 md32 ram1 tty2 tty50 ttyS0
> loop3 md4 ram10 tty20 tty51 ttyS1
> loop4 md5 ram11 tty21 tty52 ttyS2
> loop5 md6 ram12 tty22 tty53 ttyS3
> loop6 md7 ram13 tty23 tty54 urandom
> loop7 md8 ram14 tty24 tty55 vcs
> MAKEDEV md9 ram15 tty25 tty56 vcs2
> md mem ram2 tty26 tty57 vcs3
> md0 net ram3 tty27 tty58 vcs4
> md1 network_latency ram4 tty28 tty59 vcs5
> md10 network_throughput ram5 tty29 tty6 vcs6
> md11 null ram6 tty3 tty60 vcsa
> md12 port ram7 tty30 tty61 vcsa2
> md13 ppp ram8 tty31 tty62 vcsa3
> md14 psaux ram9 tty32 tty63 vcsa4
> md15 ptmx random tty33 tty7 vcsa5
> md16 pts rtc tty34 tty8 vcsa6
> md17 ptyp0 shm tty35 tty9 zero
> md18 ptyp1 stderr tty36 ttyp0
> md19 ptyp2 stdin tty37 ttyp1

[Baer]

Fdisk -l /dev/xy sollte dir was übers Filesystem erzählen.
Die -t Option ist tätsächlich meistens nicht erforderlich, weil das FS normalerweise automatisch erkannt wird.
Wesshalb brauchst du denn das rescue system? Bei defektem FS kann das FS nicht mehr erkannt werden, dann kommt diese Fehlermeldung auch.
Dan mal fsck anschauen.

Wenn du eine Ausgabe wie die von /dev postest dann schau, dass das der Reihe nach geschieht, so wie du das postest ist es quasi unleserlich.
(code in codetags und lange ausgaben nach nopaste)
Was man erkennen kann ist das kein sdx und kein hdx vorhanden ist also wird es wahrscheinlich eines der md devices sein
LG Urs

[armin]

Kann es sein, dass du es mit einem Raid-System zu tun hast und das ganze erstmal mit mdadm zusammen basteln musst?
Mehr kann ich dir leider zu Raid nicht sagen, aber vielleicht hilft es ja beim googlen.

[stebue]

Nun habe ich den Fehler gefunden. Mein Anbieter hat mir geschrieben, dass aus irgendeinem unerfindlichen Grund, die beiden Festplatten nicht ansprechbar waren. Nach einem Neustart ins Rescue System haben die Befehle mount /dev/md3 /mnt/rescue etc. einwandfrei funktioniert (es handelt sich um ein Raid System).

Allerdings: chroot /mnt lilo hat nicht den gewünschten Erfolg gebracht...