Partitionstabelle stimmt nicht -> kernelpanic

Errorsmith

Errorsmith

Kompiliertier
Hi

Ich habe einen VServer bei netcup bei dem irgendwie die Partitionstabelle nicht stimmt. Eigentlich soll das Ding eine 120GB Festplatte haben. gpart zeigt das auch so an:
Code: 
=>       34  245366717  vtbd0  GPT  (117G)
         34        128      1  freebsd-boot  (64K)
        162  241172480      2  freebsd-ufs  (115G)
  241172642    4194109      3  freebsd-swap  (2.0G)

df allerdings sieht das etwas anders:
Code: 
Filesystem      Size    Used   Avail Capacity  Mounted on
/dev/vtbd0p2    7.7G    2.9G    4.1G    41%    /
devfs           1.0K    1.0K      0B   100%    /dev

Der Kernel quittiert das nun mit einer panic wenn versucht wird auf die Verzeichnisse zuzugreifen dir "hinter" den von 'df' erkannten 8 GB liegen:
vserver_panic.png


Wie kann ich das fixen, so dass ich mit der Maschine weiterarbeiten kann?

die obligatorischen Infos zum System:
FreeBSD 10.0-Release, Ports aktuell, Hardware läuft unter quemu (2 Kerne, 6GB RAM, 120GB HDD)

Grüße,
errorsmith
 
Weißt du, wie das passiert ist? Ich hoffe, du hast ein Backup. Denn es sieht auf den ersten Blick nach Totalschaden aus... Kommst du noch an die Ausgaben von "mount" und "dumpfs /dev/vtbd0p2 | head -n 18"? Damit könnte man vielleicht zumindest erkennen, wieso das Dateisystem angeblich so klein ist.
 
Ich vermute das das Systemimage das bei der Grundinstallation verwendet wird auf 8 GB limitiert ist. Oder so.
Als ich die Kiste aufgesetzt habe, habe ich das "FreeBSD" Image gewählt und installieren lassen. Ich bin nicht auf die Idee gekommen die Partitionierung zu prüfen (hätte ich vielleicht tun sollen, ist mir nun auch klar). Wenn dem so ist, dann läuft der seit 3 Monaten mit diesem Problem ohne das es aufgefallen ist: Das System fährt sauber hoch und läuft auch stabil. Ich kann dir also noch alles mögliche andere geben falls du noch mehr brauchst.

Zur Zeit ist nur Icecast2 installiert, die Konfiguration davon könnte ich ohne Probleme sichern. Ich würde wegen des Aufwands aber gern eine Reinstallation vermeiden. Aufgefallen ist mir das eigentlich nur weil ich heute postfix installieren wollte und "make config" zum reset geführt hat.

Mount sagt dies da:
Code: 
/dev/vtbd0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)

und dann "dumpfs /dev/vtbd0p2 | head -n 18":
Code: 
magic   19540119 (UFS2) time    Tue Sep  8 13:00:00 2015
superblock location     65536   id      [ 5447829d ad4b4354 ]
ncg     14      size    2085872 blocks  2015511
bsize   32768   shift   15      mask    0xffff8000
fsize   4096    shift   12      mask    0xfffff000
frag    8       shift   3       fsbtodb 3
minfree 8%      optim   time    symlinklen 120
maxbsize 32768  maxbpg  4096    maxcontig 4     contigsumsize 4
nbfree  151902  ndir    44134   nifree  874149  nffree  33143
bpg     20007   fpg     160056  ipg     80128   unrefs  0
nindir  4096    inopb   128     maxfilesize     2252349704110079
sbsize  4096    cgsize  32768   csaddr  5048    cssize  4096
sblkno  24      cblkno  32      iblkno  40      dblkno  5048
cgrotor 0       fmod    0       ronly   0       clean   0
metaspace 6400  avgfpdir 64     avgfilesize 16384
flags   soft-updates+journal 
fsmnt   /
volname         swuid   0       providersize    2085872
Damit kann ich allerdings nicht so viel anfangen.

Grüße,
errorsmith
 
Doch, das ist sehr hilfreich: 'blocks 2015511' sagt uns, dass das Dateisystem 2015511256 Byte Blöcke lang ist. Die 256 Byte sind historisch bedingt, in der Realität nutzt UFS wesentlich größere Blöcke. So kommen wir auf (2015511256 * 4) / 1024 / 1024 = 7,68 Gigabyte, von 'df' wahrscheinlich auf 7,7 Gigabyte aufgerundet. Daraus kann man schließen, dass das Dateisystem niemals größer als diese 7,7 Gigabyte war, denn schrumpfen kann es nicht. Folglich ist auch nichts hinter diesen 7,7 Gigabyte verloren gegangen.

Ich würde vermuten, dass das Dateisystem einfach defekt ist. Weil es einen Crash bekommen hat, weil jemand in dein Image geschrieben hat, weil... In diesem Fall kannst du in den Single User Mode oder vom Stick booten und es mit fsck behandeln. Du solltest fsck solange aufrufen, bis du einen Lauf ohne gefundene Fehler bekommst. Üble Probleme können nämlich mehrere Läuft brauchen. Das Ganze hat natürlich ein gewisses Risiko, dass das Dateisystem schwer beschädigt ist und fsck es dir praktisch abräumt. Dann würden viele Dateien in 'lost&found' landen. Wenn du das Risiko nicht eingehen willst, wäre die sicherste Lösung zuerst ein Image mit dd zu ziehen, lokal einzuhängen und zu schauen, was passiert.

Nachdem du dann wieder gebootet hast, vergrößerst du das Rootdateisystem einfach: 'growfs /'. Danach kannst du deine 120 Gigabyte nutzen. :)
 
Danke Yamagi für deine wie immer ausführliche und sehr hilfreiche Antwort.
Einen Crash hatte ich meines Wissens nicht - bis heute als ich die Panic bekommen habe. Das System schickt bei Neustart eine Mail. Das jemand in meinem Image rumschreibt kann ich nicht ausschließen. Wie wahrscheinlich sowas ist kann ich auch nicht beurteilen. Da du aus den Daten herausliest das die Partition nie eine andere Größe als diese ~8GB hatte, vermute ich eher das das Standardimage eben 8GB groß ist und relativ "unsanft" auf die 120GB Platte gebügelt wird wenn man den Server neu aufsetzt. Evtl ist es wirklich nur ein Script âla "dd image -> virtal-harddrive" das keine Rücksicht auf das FS nimmt.

Das Image durch meine Leitung zu nuckeln dauert zu lang: Ich lasse nun fsck -fy laufen und schaue ob es funktioniert. Bisher hat er auch durchaus Fehler gefunden...

Grüße,
errorsmith
 
update: Soweit erfolgreich verlaufen. Allerdings ist mein lost+found nun voll mit Datenschnipseln. Bisher läuft die Maschine aber ich werde das intensiv beobachten.

Danke nochmals für die Hilfe

Grüße,
errorsmith
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben