Rootserver startet nicht mehr.
Hallo.
erstmal - danke für alle Hilfen und sorry für den doppelpost.
Habe den Fehler gefunden. Da war noch der ovh-kernel drin und der kann kein crypted.
Habe ihn gewechselt und musste trotzdem die platte formatieren, aber jetzt funktioniert alles auch nach reboot kann ich dann die platte wieder einhängen. Nun sind zwar die daten weg, aber das wichtigste habe ich auf dem ftp backup gehabt.
Danke nochmal an alle - erledigt.
ja die war ca 20% voll
meiner meinung nach war es ext3, aber:
mount -t ext3 /dev/mapper/crypto /home
mount: wrong fs type, bad option, bad superblock on /dev/mapper/crypto,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Edit: Das spuckt dmesg bezüglich md5 aus, aber ich denke wenn die eh crypted ist ist das normal das der nichts lesen kann?!
Code:
dmesg | grep md5
md: created md5
md5: setting max_sectors to 128, segment boundary to 32767
EXT3-fs error (device md5): ext3_check_descriptors: Block bitmap for group 0 not in group (block 2356166009)!
EXT3-fs error (device md5): ext3_check_descriptors: Block bitmap for group 0 not in group (block 2356166009)!
EXT3-fs error (device md5): ext3_check_descriptors: Block bitmap for group 0 not in group (block 2356166009)!
Ist es dann überhaupt ext4?
Hast du die /home Partition schonmal benutzt bzw. überhaupt formatiert?
Hi
Also es ist schon die md5, aber wenn ich das nach men lukopen mounten will kommt das:
mount -t ext4 /dev/mapper/crypto /home
mount: unknown filesystem type 'ext4'
Nein, sie ist nicht "ausgeschaltet". Die letzte Spalte ist lediglich für die fsck Überprüfung beim Boot.
Schau mal mit "fdisk -l" welche Partition von der Größe her die richtige sein sollte.
Wenn es tatsächlich die md5 sein sollte, versuch mal "mount -t ext4 /dev/mapper/crypto /home".
Mal am Rande: Crypten aufm Root ist mehr oder weniger sinnfrei und bringt nur Arbeit wie du siehst
Hallo.
Also das mit dem /etc/fstab war eine Goldrichtige Lösung!
Der Server ist wieder an.
Nun versuch ich die Platte wieder zu mounten.
Damals war es unter /dev/md5 und so steht es ja auch noch in der fstab:
Code:
#
/dev/md2 / ext3 errors=remount-ro 0 1
/dev/md1 /boot ext3 errors=remount-ro 0 1
/dev/md5 /home ext3 defaults 1 0
/dev/sda3 swap swap defaults 0 0
/dev/sdb3 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
Die Markierte 0 dort stand vorher eine 2.
Einbinden der /dev/md5 (1000MB)
Code:
cryptsetup luksOpen /dev/md5 crypto
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
mount /dev/mapper/crypto /home
mount: unknown filesystem type 'ext4'
Aber so hatte ich das damals auch gemounted nachdem ich die Platte installiert hatte.
Oder ist die wirkliche md4 (1000MB) wegen dem fstab-Eintrag komplett ausgeschaltet?
Hehe, sieht nach meinem beschriebenem Problem aus
Lösung: /etc/fstab den letzten Wert in der /home Partition's Reihe auf 0 setzen.
Beim Start kommt fsck mit Fehler...daher bootet der Techniker den Server in den Rescue Modus, damit du dies prüfen kannst.
Stefan
vKVM ist auch dort, wo du Rescue-Pro ausgewählt hast.
Du sagst, du hast die /home Partition verschlüsselt, wie hast du das gemacht?
Es könnte sein, das beim booten (sofern du es in der fstab nicht editiert hast) die Partition (mit fsck) gecheckt wird. Da fsck das verschlüsselte Dateisystem nicht kennt, bleibt er beim booten stehen und fährt nicht mehr hoch, wie von dir beschrieben.
ich sagte auch vkvm, was für deinen fall völlig ausreichend ist, und das ist kostenlos
Oh man - hab eben bestellen wollen und da meint der das das doch nicht kostenlos ist.
"KVM IP Miete - 1 Monat 35.69 €
KVM IP Kosten Installation 58.31 €
Summe (inkl. MwSt) 94.00 € "
Das ist ganz schön heftig und will ich eigentlich nicht ausgeben.
Zitat von
stefan29
evtl mal im kvm schauen wo er hängen bleibt wenn die logs dir nix sagen was sie eigentlich sollten...
Laut OVH Manager muss man das bestellen - ist das kostenlos? hab das noch nie genutzt.
Ich werd aus den logs nicht schlau weil nichts drin steht.
evtl mal im kvm schauen wo er hängen bleibt wenn die logs dir nix sagen was sie eigentlich sollten...
Hallo.
Ich habe einen Rootserver gemietet und nach 1,5 Tagen betrieb reagierte gar nichts mehr und laut Real Time Monitoring war die swap-partition auf 99%.
Anpingen konnte ich den Server noch aber http und ssh gingen nicht mehr.
Nun hab ich den Server Hardrebootet. Dann kam wieder ein Ping aber ich konnte mich nicht auf ssh einloggen und http lief auch nicht. Also nochmal Hardreboot. Dann kam kein Ping mehr. Also hab ich auf Netboot und rescue_pro gestellt. Der boot hat geklappt und Hardwaretest hat ergeben dass alles in Ordnung ist. In den einstellungen von SSH habe ich auch nichts geändert, außer dass er auf einem anderen Port lauscht, aber das war gleich das erste was ich gemacht hatte und damit lief er ja auch mehr als einen Tag.
Dann hab ich nochmal zum Test auf Festplattenboot gestellt um zu prüfen, aber es ging immernoch nicht. Danach hab ich jetzt mal in den logs geschaut aber auch nichts ungewöhnliches gefunden. Ich weiß halt nich an welcher stelle der beim booten hängenbleibt, bzw warum er nicht ssh startet so dass ich mich einloggen kann. Wegen mir soll er auch nur ssh starten und ich starte dann die anderen Services per Hand, aber atm kann ich den Server ja nicht nutzen.
Also weiß einer Rat wie ich den wieder anbekomme ohne das System neu installieren zu müssen?
Das System: SuperPlan Mini - Debian Lenny
/boot - 100MB - Raid1
/ - 5000MB - Raid0
swap - 1000MB
/home - restMB - Raid0 (hab dieses Volume verschlüsselt, da debian diese Funktion von Hause aus mitbringt)
Bitte um Hilfe.