superblock kaputt nach Update

M

marigold

Jungspund
Hallo zusammen,

ich habe mir einen Debian (2.4 kernel) aufgesetzt der mit zuhause als Firewall, Webserver, DHCP, Fileserver, etc. dienen soll.

In kürze:
Beim Update von ziemlichen vielen Sachen ist der Server abgeschmiert und hat sich ziemlich seltsam verhalten.Ich muss den Strom kappen und beim nächsten Hochfahren kam diese Fehlermeldung:

Code:
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a -C0 /dev/md0
fsck.ext3: Invalid argument while trying to open /dev/md0
/dev/md0:
The superblock could not be read or does not describe a correct ext2
 filesystem. If the device is valid and it really contains an ext2 filesystem
 (and not swap or ufs or something else), then the superblock is corrupt,
 and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

Ich habe dann auch fsck.ext3 8193 /dev/md0 ausgefüht, und noch mit einer reihe anderer blocknummern (32768*i+1, mit i=1...20) da kam aber nichts bei raus außer der selben fehlermeldung.

Ich habe ein Raid1 laufen, als LVM. Bringt mir das irgendetwas? :think:
Das dateisytem war mal ext3.

Wie kann ich das Ding wieder zum Laufen bekommen?

für die die mehr geduld haben noch etwas ausführlicher... : :-)

Da ich in der ganzen Materie eher neu bin, mache ich das also nach und nach, bisher hatte der DHCP gerade funktioniert, ebenso wie Fileserver (also Samba, da sonst nur Windows rechner im Haus). Mit Konfigurationsdateien hab ich bisher wenig bis keine Erfahrung, weil ich meistens Webmin verwendet habe.

Ok, nun wollte ich also heute nachmittag auch das Apache-modul für Webmin installieren um das so konfortabel verwalten zu können. Allerdings musste ich vorher webmin updaten und bei der Gelegenheit dachte ich mir, könnte ich den Rest des Systems ja gleich mit updaten. Bisher hat das mit der automatischen Installation von Paketen unter Debian ja auch immer perfekt geklappt (respekt an den der sihc das ausgedacht hat! echt klasse gelöst!).
Da ich noch nie updates installiert hatte, hatte sich doch eine Menge angesammelt und ich hab eben einfach alles ausgewählt und updaten lassen.
Er hat zwar noch angefangen das alles zu machen, aber irgendwann ist er einfach abgestürzt. Ich war nur über SSH verbunden, die letzte Ausgabe die ich bekommen habe ist:

Code:
Setting up hotplug (0.0.20040329-26) ...
Installing new version of config file /etc/hotplug/firmware.agent ...
Installing new version of config file /etc/hotplug/net.agent ...
Installing new version of config file /etc/hotplug/scsi.agent ...
Installing new version of config file /etc/hotplug/net.ifup ...
Installing new version of config file /etc/hotplug/ide.rc ...
Installing new version of config file /etc/hotplug/isapnp.rc ...
Installing new version of config file /etc/hotplug.d/default/default.hotplug ...

Configuration file `/etc/modprobe.d/isapnp'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : background this process to examine the situation
 The default action is to keep your current version.
*** isapnp (Y/I/N/O/D/Z) [default=N] ?

Danach hat er die Verbindung beendet und sich beständig gewehrt eine neue herzustellen. DHCP ist ebenso ausgestiegen, allerdings bin ich noch ins Internet gekommen wenn ich manuell auf einem der Windowsrechner eine IP und Gateway vergeben habe.
Da ich nicht mehr fernwarten konnte habe ich direkt tastatur und tft an den server angeschlossne, aber der hat nicht einmal mehr ein bild angezeigt (wobei wie gesagt das Internet noch mehr oder minder funktioniert hat)
 
Seit Ostermontag ist Etch stable, d.h. Du wirst wohl durch Dein "unbedarftes" Handeln mitten in ein Release-Upgrade gekommen sein. (daher auch die vielen Pakete).
Möglicher Grund ist, dass mit Etch kein 2.4er Kernel mehr unterstützt wird.
Frage: Fährt die Kiste überhaupt noch hoch? Ist das RAID1 nur für Daten oder liegt da auch das root-Filesystem drauf?
 
morgen!
Etch ist sowas wie das übernächste Sarge? dann wäre es ja wirklich kein Wunder das so viele Pakete nen Upgrade wollten...

Ich kann den Rechner anschalten, dann checkt er die Festplatte auf Fehler und bemerkt eben das /dev/md0 nicht so ganz in Ordnung ist. Ich kann ihm danach trotzdem anweisen einfach hochzufahren, allerdings funktioniert dann bei weitem nicht alles. Aber Internet zum Beispiel, wenn ich wie oben genannte wieder alles manuell einstelle.
Das RAID1 ist im Moment für alles zuständig, also inklusive root filesystem.

Noch eine Frage: was ist eigentlich /dev/md0? alles devices die im RAID1-Verbund enthalten sind?

danke für Deine Hilfe
 
Naja ... "Etch ist das nächste Sarge" triffts eher. Schau mal hier ... insbesondere DAS.
Damit solltest Du Dein System erstmal vollständig auf Etch heben (incl. 2.6er-Kernel). Dann schaun wir mal, ob das System noch muckt.

/dev/md0 ist das erste (daher 0) angelegte Software-RAID. Also Dein RAID1. Google mal nach "mdadm" ... ;)
 
also mit meinen beschränkten Mitteln glaube ich herausgefunden zu haben, dass irgendwie das (Software) RAID kaputt ist...
wie gesagt, ich hab zwei baugleiche ide hdds drin, die sind beide vollständig im RAID1, darauf gibt es zwei Partitionen: einmal 250MB für die Boot Partition und dann noch der Rest für LVM. Wenn ich nun versuche die boot partition der einzelnen platten zu mounten (also hda1 und hdc1), dann geht das ohne probleme - als RAID jedoch nicht... lauf "diff" sind die auch nicht gleich.
Ich hab dann mal als Test einfach die eine auf die andere kopiert - das bringt aber auch nicht den gewünschten erfolg.
Ich werde jetzt erstmal ein bisschen über RAID und mdadm rumlesen, über eine kleinen wink mit dem Zaunspfahl wäre ich aber auch nicht traurig :-)

danke soweit aber!
 
Hmm wenn die einzelnen Platten noch OK sind, dann fahr die Kiste mit einer Rettungscd o.ae. hoch und rebuilde das RAID von der Platte die du ffuer OK haeltst.

mdadm --query /dev/platte1 bzw. platte2
uuid merken/kopieren.

mdadm --assemble /dev/md0 /dev/guteplatte /dev/schlechteplatte --uuid=blafasel

Das ist aus dem Kopf geschrieben, kann also sein das du dran rumbasteln musst.
Du solltest das auch nicht tun ohne dich vorher mit mdadm beschaeftigt zu haben, da kann einiges bei kaputtgehen!
 
also ich verstehe das nicht.
a) warum kann ich überhaupt booten, wenn doch das RAID Gerät welches die boot-partition enthält nicht zu mounten ist bzw. nur die einzelnen PLatten aber nicht als RAID

und b)
wenn es nur an Superblocks liegt, dann sollte es doch ausreichen die Platten entsprechend wie es vorher war zu partionieren, bzw. das RAID einfach noch einmal neu einzurichten, oder?
genau das habe ich eben gemacht, aber es geht trotzdem nicht.

weiterhin etwas seltsam finde ich:
wenn ich mir /proc/mdstat anschaue, dann steht dort dass er gerade einen resync macht, aber nicht etwa von md0, sondern von md1 mit dem doch eigentlich alles in Ordnung ist - dachte ich zumindest... Das habe ich einmal durchlaufen lassen (Fehler war danach nicht behoben), aber jetzt, nach dem ich das RAID neu eingerichtet habe, macht er das schon wieder...

Könnte es etwas damit zu tun haben, dass ich keinen "echten Debian" habe sondern eine ct'distribution mit integriertem IpCop das in einer virtuellen Umgebung (UML) läuft?

edit: ein assemble habe ich auch probiert - ebenfalls ohne erfolg. Der Befehl slebst selbst läuft jedoch ohne probleme ab, soweit ich das beurteilen kann

danke für Eure Hilfe
 
also ich verstehe das nicht.
a) warum kann ich überhaupt booten, wenn doch das RAID Gerät welches die boot-partition enthält nicht zu mounten ist bzw. nur die einzelnen PLatten aber nicht als RAID

Denn sie wissen nicht was sie tun. Du kennst doch bestimmt den Zweck den ein RAID Level 1 erfüllen soll?
 
RAID1 ist meines wissens nach für zwei Dinge gut: 1. Datenredundanz, und 2. deutlich schnellerer Lesezugriff.
Ich dachte nun die Reihenfolge ist folgende:
1. Rechner anschalten
2. RAID wird aktiviert
3. es wird gebootet
...
falsch?
oder wird automatisch von einer einzelnen platte gebootet, wenn das RAID eben nicht funzt?
 
hallo,

letztlich habe ich jetzt einfach das system neu aufgespielt, aber diesmal ein "normales" debian. Anstatt einem virtuellen IpCop tuts jetzt wieder der alte hardware router.
Ist sicherheitstechnisch vielleicht wirklich besser.

nagut, auf jeden Fall danke für Eure Hilfe!

wobei... ich hab da grad wieder was angestellt :brav:
http://www.unixboard.de/vb3/showthread.php?p=226447#post226447
 

Ähnliche Themen

Nginx als Reverse Proxy für Nextcloud und Emby

Zugriff Ubuntu 16.04. auf Freigabe 18.04. LTS nicht möglich

X startet nichtmehr

./easy-wi_install.sh install Script

Ich mag Dovecot nicht ...

Zurück
Oben