Strato Root - Raid entfernt | Problem: /proc/mounts

R

reduX

Grünschnabel
Tag zusammen,

Soweit, also ich besitze einen Server bei Strato wo ich für Freunde eigene Videos, Bilder, Webseiten oder private Teamspeak Server hoste.

Setze Debian Sarge ein.

Nun musste die Festplatte ausgetauscht weren und ich habe dann das System neu aufgesetzt. Jetzt war da ein Soft-Raid drauf, gibt bei Strato nach eigenen Angaben zurzeit nur Raid-Images. Ich also schnell mal angefragt deswegen und dann aber direkt ne Anleitung dazu bekommen. Habe sie dann auch befolgt und am Ende kam ich zum gleichen Ergebniss. Das Raid war draußen...

Code:
umount: Cannot open /proc/mounts
cramfs: wrong magic
EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem as ext2

pivot_root: No sKernel panic: Attempted to kill init!
uch file or dire ctory
/sbin/init: 432: cannot open dev/console: No such file

Hier das Problem. Ich kann es mir gar nicht erklären, habe die Sache nun viermal wiederholt. Scheint die einzigste komische Meldung zu sein beim Bootvorgang. Ich habe das ganze schon einmal erfolgreich gemacht, allerdings ist das einige Monate her und ich wei nicht mehr wie ich es früher gemacht hatte.


Gruß reduX
 
Zuletzt bearbeitet:
Waere schon interessant zu wissen, was du alles gemacht hast. Normalerweise reicht es alle md-Dienste zu stoppen, die Partitionen der zweiten Platte unmounten und die zweite Platte neu zu partitionieren. Dann noch die notwendigen Anpassungen in der fstab und der grub-Konfiguration.
 
Klar, okay. Habe euch mal weitere zusammengefasst.

STRATO-ANLEITUNG

Ich bin nachdem ich die Anleitung hatte genau dannach vorgegangen und es gab keinerlei Probleme mis zum reboot. Vorher habe ich das Spiel ähnlich durchgeführt, aber ich kam zum gleichen Ergebnis!

/boot/menu.lst
Code:
-

Code:
-

/etc/fstab
Code:
-
 
Zuletzt bearbeitet:
Die Anleitung von Strato ist nicht nur fuer SuSE gedacht, sondern auch nur fuer ein Software-RAID und kein Hardware-RAID, wie es dein Server offenbar hat. Was geben dir denn die Dateien /var/log/messages und /var/log/kern.log sowie /var/log/syslog aus? Finden sich dort Fehler zu sda und/oder sdb?
 
Nein, wie oben geschrieben handelt es sich nur um ein Soft-Raid. Mir ist auch klar, dass es keine Abweichungen gibt zwischen SuSe und Debian im Falle der Raidentfernung.

Wie auch gesagt bin ich davon überzeugt das die Entfernung des Raids funktioniert hat, allerdings bekomme ich einen error beim booten wie oben zu sehen ist, kann man daraus nichts lesen aus der Meldung? Ich kann jetzt nicht viel damit anfangen. Ich bin Einstellungen durchgegangen und konnte keinen Fehler entdecken im Vergleich mit den Backups etc.

Zitat Strato Angebot: Habe den MR3 Root!
Alle Server sind mit 2 Highspeed-Markenfestplatten ausgestattet und sind dadurch "RAID-ready". Die Platten bieten genügend Speicherplatz auch für riesige Datenmengen.

Die HighEnd-Server SR3 und MR3 bieten Software-RAID1.
Ihre Daten liegen mit RAID1 in einem gespiegelten Zustand vor und sind somit wesentlich besser gegen einen Verlust geschützt, als in einem System mit nur einer einzigen Festplatte.

Zu den Logfiles. Letzten Einträge:

kern.log

syslog -> Ähnlich der kern.log. Es wird halt noch der reboot von mir angezeigt. Reboot zum Recovery System.

Ja, und auch sonst, ich hatte ja schon einmal die Logfiles durchgesehen, war so ziemlich das erste was ich tat, da war nichts weiter zu finden. Den error habe ich auch erst bemerkt, als ich dannach nochmal per remoteconsole drauf geschaut habe.

Gruß
 
Zuletzt bearbeitet:
Naja, an der kern.log sieht man doch aber, dass das RAID ganz offensichtlich noch nicht entfernt ist. Ausserdem zeigt das Problem, dass er /dev/console nicht oeffnen kann an, dass offenbar die root-Partition nicht korrekt ist, was damit zu tun haben koennte, dass du du boot-Partition bei 'root=' als Kernel-Parameter uebergibst.
 
Vielleicht habe ich mich etwas komisch ausgedrückt. Die Logeinträge stammen aus der Zeit wo das Raid noch aktiv war, ja. Es existieren keine weitren Logs nach der Entfernung, beim booten bekomme ich die oben erwähnte Meldung und sonst existiert kein Log zu dem Fall.

Das Raid ist zu 100 % entfernt.


Ich nehme stark an das er die "/dev/console" nicht finden kann, weil vorher die /proc/mounts gar nicht auffindbar ist. Da liegt der Hund begraben, warum ist das so?


Die menu.lst, mehr oder weniger der Standardeintrag von Strato, lief alles schon einmal so.
 
Da du jetzt schon mehr Zeit vergeudest, als gewinnst:

1.) https://config.strato.de/ <-- hier einloggen
2.) Nutze das Menu links, um das Debian Image neu aufspielen zu lassen
3.) installiere deine benötigten Dienste
4.) schieb deine Backups vom FTP wieder zurück

Ist ja schon toll, dass man für das Geld ein 100% FTP-Backup bekommt :-), sofern man es dann auch nutzt.

M.f.G. slasher.
 
Es existiert kein Backup auf dem extra verfügbaren Backup FTP Server. Das war aus verschiedensten Gründen keine so tolle Idee und deswegen bleibt der Dienst deaktiviert. Das hilft mir so nicht weiter.

Ist ja schon toll, dass man für das Geld ein 100% FTP-Backup bekommt :-), sofern man es dann auch nutzt.

Es wäre aber wirklich mal ganz gut wenn ich nachdem das System wieder läuft ohne Raid kurz mal ein Backup machen lasse. Das wäre bei mir drin. :) Aber nun brauche ich erst mal eine Problemlösung.

KANN CLOSED!
 
Zuletzt bearbeitet:

Ähnliche Themen

Root mount failed

Ubuntu X / dbus problem

apt-get, kernel panic und der ganze Rest

FC5 & Raid 0

Suse Linux 10.1 bootet nicht mehr...

Zurück
Oben