Probleme mit kaputter Partitionen, oder so ähnlich ...

konstantin

Well-Known Member
Hallo!

Ich habe auf einem Rechner per SSH einer (Linux-)Boot-CD ein FreeBSD-Image auf die Festplatte kopiert. Ich glaube aber, dass das Image ein wenig zu groß war. Das Programm fdisk von Linux hatte mit beim Anzeigen des BSD-Labels einen Fehler gesagt. Leider weiß ich den Fehlertext nicht mehr genau und das booten der CD geht im Moment leider nicht. Es ging irgendwie darum, dass Blocks (oder heißt das Blöcke?) fehlen, glaub ich. Ich hoffe, dass ihr mir auch so helfen könnt.

Die letzte Slice auf der Disk ist /usr. Die wird auch gemountet. Ein fsck -v /usr sagt:
Code:
start /usr wait fsck_ufs /dev/ad0s1e
** /dev/ad0s1e (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes

CANNOT READ BLK: 376576
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? [yn] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 376609,

CANNOT READ BLK: 376704
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? [yn] y

THE FOLLOWING DISK SECTORS COULD NOT BE READ:

CANNOT READ BLK: 1129248
UNEXPECTED SOFT UPDATE INCONSISTENCY

CONTINUE? [yn]

usw ...


Ich blick durch die Partitionen und Slices leider immer noch nicht so richtig durch. Kann das nun sein, dass das Image zu groß war und in der Tabelle über die Partitionen drinsteht, dass die /usr-Partition größer ist, als sie wirklich ist und es deshalb zu Problemen beim Lesen kommt?

Wie kann ich das Problem beheben? Hat das Auswirkungen auf die Konsistenz des OS?

Bin um jeden Rat dankbar,

Konstantin
 
konstantin said:
Ich glaube aber, dass das Image ein wenig zu groß war.

"Glauben" ist gut. Überprüf das und spiele das Image in eine mindestens gleichgroße Partition ein.

Was Du gemacht hast (wenn das so ist), ist in etwa eine CD zu brennen, dann den Rand davon anknabbern und dann zu erwarten, dass die Daten, die am Rand waren, noch lesbar sind.
 
Du musst schon ein Image passender Größe verwenden. Du kannst ja auch von einem Auto nicht das hintere Viertel absägen und erwarten das es dann noch funktioniert.
 
Na ja ... das ist mir schon klar.

Die Sache ist aber, dass das System (bisher ?) problemlos läuft. Ich denke mal, dass da keine Daten fehlen. Kann man dem jetzt nicht sagen, dass die Partition halt einfach ein bisschen kleiner ist? (Wir reden hier ja höchsten von ein paar Blöcken oder so ...)

"und erwarten das es dann noch funktioniert." --> Es funktioniert ja bisher. Ich hatte noch keine Probleme.

"dass die Daten, die am Rand waren, noch lesbar sind." Ich vermisse ja bisher noch keine Daten.

Bis auf die Meldungen bei fsck hatte ich noch keine Auffälligkeiten.

Gibt es eine Möglichkeit das so reparieren?
 
Die angeknabberte CD wird ja auch funktionieren, wenn Du auf die Daten nicht zugreifst, die außen liegen.

Das Blöde ist, man macht aus diesem Grund keinen Backup mit dd. dd ist kein Backup-Tool. Dafür nimmt man dump(8). Das ist einfacher zu bedienen und ist partitionsunabhängig. D.h. Du kannst eine gesicherte Partition sogar auf mehrere restaurieren (es muss nur alles passen).

Mounte das alte FS per mdconfig, wenn Du es hast und mach ein dump(8) mit anschließendem restore(8), vor dem restore musst Du aber das Dateisystem mit newfs nochmal neu/richtig erstellen.

Wenn Du es nicht mehr parat hast, was total blöd wäre, dann kannst Du mit viel Glück cp/tar benutzen, um es irgendwo hinzukopieren. Dann newfs und wieder zurück.
 
Mein Plan sieht jetzt so aus:

Auf dem Remote-System:
Code:
umount /usr
newfs /dev/ad0s1e
mount /usr

Auf dem Deskop-System:
Code:
mdconfig -a -t vnode -f bsd.img
dump -0af - /dev/md0s1e | bzip2 -cvv9 | ssh root@<meine ip> "cd /usr && bzip2 -cvvd | restore -rf -"

Geht das so? Reicht das aus, wenn ich das fs neu mache (newfs)? Sind die Partitionen in Ordnung?

Läuft SSH und restore ohne /usr? (Müsste ja eigentlich. Liegt ja alles unter /bin ...)

Bitte bestätigt noch mal, dass das so gehen sollte oder sagt, was nicht geht.

Danke.
 
Back
Top