wiedermal UFS fsck Probleme

[SWirth]

Hallo BSD Freunde,

Nach ein paar Jahren FreeBSD Abstinenz möchte ich wieder einsteigen und bin über ein altes Problem gestolpert, dass mir schon einmal zum Verhängnis geworden ist. Leider habe ich noch keine Lösung gefunden. Für euch sicherlich ein Leichtes.

Ich hatte eine Festplatte mit FreeNAS erstellt (UFS) und beim Einbinden in mein neues Nas4Free System kann ich diese Platte nicht mehr mounten. Ich denke es gab zwischenzeitlich mal ein Systemabsturz (keine Ahnung mehr).
Schon ein fsck ist nicht erfolgreich:

nas4free: ~# fsck -t ufs /dev/ada2
** /dev/ada2
Cannot find file system superberlock
ioctl (GCINFO): Inappropriate ioctl for device
fsck_ufs: /dev/ada2: can‘t read disk label


nas4free: ~# fdisk /dev/ada2
******* Working on device /dev/ada2 *******
parameters extracted from in—core diskiabel are:
cylinders=969021 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cglinders=969021 heads=16 sectors/track=63 (1000 blks/cyl)

Media sector size is 512
Warning= BIOS sector numbering starts with sector 1
Information fron DOS bootblock is:
The data for partition 1 is
sysid 238 (0xee).(EFI GPT)
start 1, size 976773167 (476940 Meg), flag 80 (active)
beg: cyl 0/ head 0/ sector2;
end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>


nas4free: ~# bsdlabel /dev/ada2
# /dev/ada2:
8 partitions:
# size offset fstupe [fsizs bslze bps/spa]
a: 976773152 16 unused 0 0
c: 976773168 0 unused 0 0 # "raw" part, don't edit


nas4free: ~# dmesg |grep ada2
ada2 at ata5 bus 0 scbus5 target 0 lun 0
ada2: <ST3500418AS CC37> ATA-8 SATA 2.x device
ada2: Serial Nunber ...
ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
ada2: Previous known as ad14


Danke für eure Hilfe!

 

[KobRheTilla]

Du musst das fsck auf der Partition, nicht auf dem "disk device" ausführen.
Bsp.:
# fsck /dev/ada2p1
oder
# fsck /dev/ada2s1a

EDIT:
Alternativ einfach alle bekannten FS prüfen:

# fsck

Rob

 

[SWirth]

# fdisk /dev/ada2a
******* Working on device /dev/ada2a *******
parameters extracted from in—core diskiabel are:
cylinders=969020 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cglinders=969020 heads=16 sectors/track=63 (1008 blks/cyl)

fdisk: invalid fdisk partition table found
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
sysid 165 (0xa5),(FreeBDS/NetBSD/386BSD)
start 63, size 976772097 (476939 Meg), flag 80 (active)
beg: cyl 0/head 1/ sector 1;
end: cyl 315/ head 15/ sector 63
...

 

[auge]

Hi SWirth,

um welche FreeBSD Version handelt es sich bei deinem NAS??
Bei aktuellen Versionen von FreeBSD sind nicht mehr 'fdisk' und 'bsdlabel' die erste Wahl um Festplatten einzurichten. Diesen Platz hat 'gpart' übernommen.

Was sagt denn ein:

# gpart show ada2

 

[SWirth]

Hi auge,

Interessant, das wusste ich noch nicht.
Meine NAS nutzt FreeBSD 10.1, ist also aktuell.

gpart sagt folgendes:

# gpart show ada2
=> 0 976773168 ada2 BSD (466G)
0 16 - free - (0.0K)
16 976773152 1 !0 (466G)

Danke
Grüße
SW

 

[Yamagi]

Also, diese Festplatte ist "Dangerously Dedicated" partitioniert. Sie hat die klassische BSD-Partitionstabelle (das bsdlabel / disklabel), ohne eine DOS/MBR-Partition außen herum zu haben. Das war schon immer sehr wackelig, da man fast zwangsläufig in Probleme mit der Festplattengeometrie läuft und viele x86-BIOSe Festplatten ohne MBR nicht booten wollen. Seit FreeBSD 8.0 ist es für Neuinstallationen nicht mehr unterstützt, auf vorhandenen Systemen müsste / sollte der Kernel laut schreien. Mein Tipp wäre: Von einer Live-CD oder einem USB-Stick booten, die Daten mit dump(8) runter und dann einmal sauber neu partitionieren.

 

[SWirth]

Danke für die 'tolle' Nachricht Yamagi.
Ich werds in Angriff nehmen wenn ich die Zeit finde.

 

[Tronar]

Daß die BIOSe evtl. Ärger machen, sehe ich ja ein, aber warum läuft man in Probleme mit der Festplattengeometrie, wenn man sich eine eigentlich überflüssige Schachtelung von Partitionen erspart? Hat das etwas mit der Sonderstellung von Spur 0 zu tun, also daß die Partitionen ab Spur 1 beginnen sollten? (Ich habe dangerously dedicated noch nie probiert.)

 

[Crest]

Nein. Es gibt nur Warnungen. Das alte BSD Label kommt aus einer Zeit als Platten noch sehr dumm (dafür aber ehrlich) waren. Deswegen enthält es Daten über die Platte, die heute nicht mehr sinnvoll sind wie halt die (gefälschte) Festplattengeometrie und Drehzahl. Partitionen sollten halt früher an Zylindergrenzen anfangen und iirc enthält FreeBSD noch immer ne Warnung falls das nicht der Fall ist, weil es früher ansonsten Performanceprobleme gab. Auf PCs stellt sich gerne das BIOS auch mal quer, wenn es keinen MBR findet sondern nur Bootcode im ersten Block steht. Außerdem schlussfolgern diverse Partitionierungsprogramme aus einem "fehlenden" MBR, die Platte sei nicht formatiert und bieten hilfreich wie sie sind an die Platte zu "initialisieren".

 

[Yamagi]

Crest sagt es. Dazu kommt, dass FreeBSD seit 8.0 eine Konsistenzprüfung durchführt. Er schaut, ob die Partitionstabelle konsistent und logisch ist. Ist sie das nicht, weil sie beispielsweise nicht auf die von der Festplatte gemeldeten Daten passt oder Partitionen sich überschneiden würden, wird sie zurückgewiesen und die von ihr definierten Partitionen sind nicht verfügbar. Es gibt ein Tuneable, was den Kernel zwingt, die Partitionen dennoch bereitzustellen. Aber das alles ist nicht das Problem in diesem Thread, denn die Partition wird ja korrekt erkannt.

 

[SWirth]

Hi,

Mein Tipp wäre: Von einer Live-CD oder einem USB-Stick booten, die Daten mit dump(8) runter und dann einmal sauber neu partitionieren.

Manchmal komm ich mir so unwissend vor wenn ich an den Grundlagen scheitere.

Mein Problem ist ja, daß ich die Platte / Slice nicht mounten kann.
# mount /dev/ ada2a /mnt
invalid argument /dev/ada2a

Für ein dump/restore muss ich aber die Platte mounten um dann die Sicherung zu erstellen wenn ich das richtig verstehe.
/sbin/dump /dev/target /source

Danke.

 

[pit234a]

soviel ich weiß, muss ein filesystem für dump nicht gemountet sein. Es muss vor dem restore ein gültiges Fielsystem bestehen und gemountet sein, wohin dann die Daten des Dumps restauriert werden.

Weil du aber von Grundlagen redest, sollten wir vielleicht damit mal beginnen, um sicher zu sein, worüber wir überhaupt reden und womit wir es zu tun haben.

Du hast also ein funktionierendes BSD (Version?) und hängst dort eine Platte rein. Ich zeige das mal für ein FreeBSD 8.4 mit einem Stick:

 o-box@senyo ~:-> dmesg
...
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <SanDisk Cruzer 1.10> Removable Direct Access SCSI-2 device 
da0: 40.000MB/s transfers
da0: 15267MB (31266816 512 byte sectors: 255H 63S/T 1946C)

o-box@senyo ~:-> ls /dev | grep da
da0
da0s1

o-box@senyo ~:-> file -s /dev/da0
/dev/da0: x86 boot sector; partition 1: ID=0xc, active, starthead 0, startsector 32, 31266784 sectors, code offset 0x31

o-box@senyo ~:-> file -s /dev/da0s1
/dev/da0s1: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 16, Media descriptor 0xf8, heads 64, sectors 31266784 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 15264, serial number 0x81801aaf, label: "           "
o-box@senyo ~:->

Dieser Stick enthält ein KNOPPIX und ist FAT (32 bit) formatiert.
Mit dieser Information kann ich nun meinen mount oder fsck bestimmen.
Du brauchst diese Information, sie muss von deinem System kommen. Du kannst nicht raten und kannst nichts vorgeben, was dann vom System nicht oder anders erkannt wird.
Dass du glaubst, die Historie der Platte mehr oder weniger lückenlos zu kennen, sollte nicht zu voreiligen Schlüssen verleiten. Nachsehen ist besser. Mittels gpart show hattest du das Partitionskonzept schon mal nachgesehen. Ich würde nun weiter schauen, was denn da überhaupt auf der Platte ist und wie das genau aussieht.

 

[SWirth]

Hallo pit234a,

Danke für die Nachhilfe. Bei dem Regenwetter jetzt bin ich endlich wieder mal vor die Kiste gekommen.

Ich habe mal ein paar interessante Ausgaben herausbekommen:

root@ :/ # fsck_ufs /dev/ada1
** /dev/ada1
Cannot find file system superblock
ioctl (GCINFO) : Inappropriate ioctl for device
fsck_ufs: /dev/ada1: can 't read disk label

root@ :/ # file -s /dev/ada1
/dev/ada1: DOS/MBR boot sector

root@ :/ # file -s /dev/ada1a
/dev/ada1a: data

root@ :/ # dd if=/dev/ada1 of=/tmp/ada1.mbr bs=512 count=1

root@:/ # hexdunp —Cv /tmp/ada1.mbr

Es steht auf der rechten Seite der Ausgabe geschrieben: "This is a NAS data disk and can not boot system. System halted."

root@:/ # newfs -N /dev/ada1
/dev/ada1: 381554.1MB (781422768 sectors) block size 32768, fragment size 4096
using 610 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
super-block backups (for fsck_ffs -b #) at:
192, 1282432, 2564672, ....

Jetzt kann ich auch den "Dangerously Dedicated" nachvollziehen.

Wie bekomme ich einen funktionierenden fsck hin um dann weiter zu verfahren?

Danke.

 

[Tronar]

fsck_ufs /dev/ada1 ist wohl falsch, denn damit sprichst Du ja die "rohe" Platte an und nicht eine FreeBSD-Partition auf der Platte. Gleiches gilt für das newfs.
Der Partitionsname müßte z. B. /dev/ada1a sein, evtl. auch ...d, ...e usw.

 

[pit234a]

das geht mir alles immer noch ein wenig schnell. Dafür bin ich aber auch bekannt, dass ich schnell nicht kann und langsam auch nicht gut.

Also, bitte nochmal die Ausgangslage.

Du hast eine (!, also keine zweite) Platte an einem FreeBSD hängen?
Diese Platte war eine alleinige (!, also nicht eine von mehreren und nicht Teil eines Raids) in einem NAS mit nas4free und sie war UFS formatiert und enthielt Daten, nicht das System?
Du nimmst diese Platte nun und hängst sie in ein FreeBSD (Live?, Version?) und dort wird sie erkannt. Als was? Wie hängst du ein, im laufenden System oder ist sie zur Bootzeit schon vorhanden?
Kannst du sie eindeutig zuordnen? Was sagt denn atacontrol list dazu? Wenn du im laufenden System einhängst, kannst du mit cat /var/run/devd.pipe ansehen, was aktuell erkannt wird (also Befehl absetzen, Platte einstöpseln und zusehen). Dann ist auch dmesg gut, weil es der letzte, neue Eintrag werden wird. Ansonsten, wenn mehrere Platten vorhanden sind, muss zunächst die richtige gefunden werden und das sollte dann eine aus atacontrol list sein. Wenn das sicher ist und alle anderen Fragen oben auch, dann mal mit ls /dev | grep xy nachsehen (wobei xy die ersten Buchstaben des Gerätes sind).
Bitte diese Fragen nochmal genau klären.

Weiter will ich nicht blind einfach vorgreifen und ich bin auch nicht der Ansicht, dass ich dir überhaupt helfen kann. Aber es sind mir alleine zu meinem Verständnis der Ausgangslage noch zu viele Fragen offen und deshalb das Gesamtbild überhaupt zu vage. Da gibt es noch beinahe endlose Möglichkeiten etwas falsch zu machen, bevor man überhaupt ans Eingemachte kommt. Nehmen wir nur mal an, die Platte war Teil eines Raids. Dann sehen wir aber hier alle schön alt aus mit unseren bisherigen Vorschlägen und Aussagen.

 

[SWirth]

Ich hatte am Anfang 2 SATA Platten im System hängen, eine 400GB eine 500GB die beide die selben Symptome aufweisen. Es gibt kein RAID.
Die Meldungen am Anfang bezogen sich auf die 500GB Platte.
Meine letzte Post bezog sich allerdings auf die 400GB Platte. Ich hatte die andere zwischenzeitlich abgeklemmt um da nix zu riskieren.
Beide Platten sind damals mit Freenas formatiert worden, UFS. Das Betriebssystem selbst befindet sich auf einer anderen Platte.
Die Rettungsversuche habe ich mit der FreeBSD 10.1 live CD gemacht.
Die Platten kann ich eindeutig zuordnen.
Entschuldigunge bitte die Verwirrung.

# ls /dev | grep ada
ada0
ada0s1
ada0s1a
ada0s2
ada0s2b
ada0s3
ada0s3a
ada1
ada1a

# fdisk /dev/ada1a
******* Working on device /dev/ada1a *******
parameters extracted from in—core diskiabel are:
cylinders=775220 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cglinders=775220 heads=16 sectors/track=63 (1000 blks/cyl)

fdisk: invalid disk partition found
Media sector size is 512
Warning= BIOS sector numbering starts with sector 1
Information fron DOS bootblock is:
The data for partition 1 is
sysid 165 (0xa5).(FreeBSD/NetBSD/386BSD)
start 63, size 781421697 (381553 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector1;
end: cyl 51/ head 15/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

# disklabel /dev/ada1
/dev/ada1::
8 partitions:
#    size           offset                fstype         [fsize bsize bps/cpg]
a:   781422752      16                unused         0       0
c: 781422760          0                unused         0       0        #  "raw" part, don't edit

 

[pit234a]

OK. Lass uns mal bei Platte 2 bleiben, von der der letzte Ausdruck stammt. Dann ist die nicht partitioniert, sie hat kein "bsdlabel".

fdisk ist für mich schon immer mythisch gewesen und ich habe es niemals frei sondern immer nur konkret nach Vorgabe eingesetzt. Ich traue dem nicht und finde es im höchsten Maße suspekt, kann auch seine Ausgaben nicht lesen oder deuten.
Lass mich einfach mal einige Dinge aus meinem Rechner zeigen, auf dem ein FreeBSD 8.4 läuft und das war schon einige Zeit vorher als FreeBSD 6-irgendwas aufgesetzt und eingerichtet worden.
zunächst fdisk

o-box@senyo ~:-> fdisk /dev/ar0s1
******* Working on device /dev/ar0s1 *******
parameters extracted from in-core disklabel are:
cylinders=38913 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=38913 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 0, size 50000 (24 Meg), flag 80 (active)
	beg: cyl 0/ head 0/ sector 1;
	end: cyl 1023/ head 254/ sector 63

Das sagt einem nicht wirklich was. Mein Eindruck ist, dass fdisk nichts anderes tut, als Information aus dem MBR auslesen und wiedergeben. Darüber, wie BSD mit der Platte umgeht, gibt das kaum Auskunft.
Dazu sehen wir mal mit gpart nach, gucken aber zunächst mal noch, welche "Partitionen" das System beim Booten gefunden hatte:

o-box@senyo ~:-> ls /dev | grep ar0
ar0
ar0s1
ar0s1a
ar0s1b
ar0s1d
ar0s1e
ar0s1f

o-box@senyo ~:-> gpart show ar0
=>       63  625153985  ar0  MBR  (298G)
         63  625153347    1  freebsd  [active]  (298G)
  625153410        638       - free -  (319k)

o-box@senyo ~:-> gpart show ar0s1
=>        0  625153347  ar0s1  BSD  (298G)
          0   16777216      2  freebsd-ufs  (8.0G)
   16777216    1048576      1  freebsd-ufs  (512M)
   17825792   18690048      4  freebsd-ufs  (8.9G)
   36515840    1048576      5  freebsd-ufs  (512M)
   37564416  587588931      6  freebsd-ufs  (280G)

Um die Zuordnung noch deutlicher zu machen, schiebe ich mal noch ein mount und df nach und abschließend einen Vergleich zu disklabel:

o-box@senyo ~:-> mount | grep ar0
/dev/ar0s1a on / (ufs, local, noatime)
/dev/ar0s1b on /add_b (ufs, local, noatime)
/dev/ar0s1f on /usr (ufs, local, noatime, soft-updates)
/dev/ar0s1d on /var (ufs, local, noatime, soft-updates)

o-box@senyo ~:-> df | grep ar0
/dev/ar0s1a                         507630     389650     77370    83%    /
/dev/ar0s1b                        8122126     377126   7095230     5%    /add_b
/dev/ar0s1f                      284547318  125160610 136622924    48%    /usr
/dev/ar0s1d                        9048942    4073416   4251612    49%    /var

Und disklabel, vergleiche mit gpart, die gleiche Information, anders dargestellt.

o-box@senyo ~:-> disklabel /dev/ar0
disklabel: /dev/ar0: no valid label found
o-box@senyo ~:-> disklabel /dev/ar0s1
# /dev/ar0s1:
8 partitions:
#          size     offset    fstype   [fsize bsize bps/cpg]
  a:    1048576   16777216    4.2BSD     2048 16384     8
  b:   16777216          0    4.2BSD     2048 16384 28528
  c:  625153347          0    unused        0     0     # "raw" part, don't edit
  d:   18690048   17825792    4.2BSD     2048 16384 28528
  e:    1048576   36515840    4.2BSD     2048 16384     8
  f:  587588931   37564416    4.2BSD     2048 16384 28528

Also, ich denke, das zeigt ziemlich gut, wie das traditionell aussieht. Meine "Platte" (es sind mehrere in einem HW-Raid) wird als gerät ar erkannt. ar0 ist das erste dieser Geräte. Nun interpretiere ich etwas frei weiter. fdisk zeigt, dass da eine Partition belegt ist (Nr 4 und hier gebrauche ich Partition aus Sicht des MBR, das ist manchmal verwirrend, weil auch die Slizes von FreeBSD als Partitionen bezeichnet werden können und faktisch auch welche darstellen). Diese Partition (es werden keine weiteren benutzt) ist die erste und deshalb s1. Sie wird beschrieben durch ar0s1 und das steht quasi für den Eintrag "c:" im disklabel, der diese komplette Partition beschreibt. Im disklabel sind auch die anderen "FreeBSD-Partitionen" zu erkennen (die Ausgabe von disklabel nennt das auch partitions, doch das sind nicht die Partitionen, die fdisk angezeigt hatte). Die Ausgabe von gpart demonstriert das und zeigt die gleichen Informationen.

Bei deiner Platte 2 ist ein derartiges Gerüst gar nicht vorhanden. Die Platte 1 müssten wir uns nochmal ansehen, ich habe das nun nicht mehr im Kopf, aber ich glaube, die hatte mehrere Partitionen aus dem MBR heraus angelegt auf denen dann jeweils FreeBSD-Partitionen eingerichtet waren.

Es wäre vielleicht interessant zu sehen, wie nas4free damit umgegangen ist. Wenn das dort so gemacht wird, wie das "üblicherweise" funktioniert, dann sollten Einträge in der /etc/fstab des Systems existieren, die für das automatische Einbinden der Dateisysteme beim Booten sorgten. Das kann vielleicht einen weiteren Aufschluss geben. fsck wirkt auf Dateisysteme und Dateisysteme befinden sich in "FreeBSD-Partitionen".

Also "FreeBSD-Partitionen" ist keine offizielle Bezeichnung, ich habe mir das eben so ausgedacht um Unterschiede zu zeigen und nicht durch weitere Namen noch mehr zu verwirren. Vielleicht werde ich dafür nochmal geohrfeigt werden, vielleicht stifte ich in Wirklichkeit erst recht Verwirrung. Das ist mir noch nicht ganz klar.
Was ich mit all dem nun bezwecke ist, die unterschiedlichen Aussagen von oben besser zu erklären. Wie gesagt, fsck wirkt auf ein Dateisystem und dazu muss der Ort genau angegeben werden, wo dieses Dateisystem sich befindet. Dann kann fsck dort auslesen. welche speziellen Eigenheiten das Dateisystem hat und entsprechende Prüfungen durchführen. Findet es diese Information nicht, dann gibt es Fehlermeldungen.
Dazu mal ein Beispiel, wenn ich es auf eine Partition anwende, die kein UFS enthält, anschließend auf eine passende "FreeBSD-Partition" und abschließend auf eine "unpassende":

senyo# fsck /dev/da0s1
fsck: Could not determine filesystem type

senyo# fsck /dev/ar0s1b
** /dev/ar0s1b (NO WRITE)
** Last Mounted on /add_b
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
1908 files, 188563 used, 3872500 free (260 frags, 484030 blocks, 0.0% fragmentation)

senyo# fsck /dev/ar0s1
fsck: Could not determine filesystem type

Nun kann man aus allem zusammen vielleicht Schlüsse auf das Verhalten bei dir ziehen. Ich kann das nun gerade nicht, weil ich es bereits vergessen habe und erst wieder nachschauen kann, wenn ich diesen Post abgeschickt habe. Ich bin mir nicht mal sicher, ob ich noch direkt an deinem Thema dran bin, aber ich glaube, dass ich schon die Probleme beleuchte, die in vorherigen Beiträgen angeklungen sind. Du musst als Ort für die fsck-Prüfung genau den Ort angeben, auf dem dein Dateisystem angelegt worden ist. Das kann sogar vollkommen ohne Partitionen direkt auf einer Platte geschehen. Aber, wenn du den falschen Ort angibst, wird es niemals funktionieren und es wird auch nicht funktionieren, wenn die wesentliche Information bereits verschwunden ist (durch irgendein Missgeschick vielleicht überschrieben wurde).
fsck prüft nur ein Dateisystem, es erfindet es nicht neu.

 

[pit234a]

Ah, kaum hochgeladen springt mir direkt ins Auge, dass ich die allererste Ausgabe von fdisk vermurkst habe und mich dann auch noch darauf bezog. Lass mich die korrekte Ausgabe nachreichen und ich denke, der Rest ergibt sich daraus von selbst und ich brauche das nicht alles oben zu korrigieren:

o-box@senyo ~:-> fdisk /dev/ar0
******* Working on device /dev/ar0 *******
parameters extracted from in-core disklabel are:
cylinders=38914 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=38914 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 625153347 (305250 Meg), flag 80 (active)
	beg: cyl 0/ head 1/ sector 1;
	end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

Das Gute an meinem Fehler ist vielleicht, dass man weiter oben eben eine Ausgabe von fdisk erhält, die gar nicht sinnvoll ist. Es wird der "Startsektor" der "(DOS)-Partition" ausgewertet und das verwirrt eher, als das es hilft. fdisk wird (wenn ich nicht irre und wenn überhaupt sinnvoll) auf Platten angewendet, nicht auf "Partitionen".

 

[SWirth]

Hier habe ich mal die Ausgaben der zweiten Platte.

# fdisk /dev/ada1
******* Working on device /dev/ada1 *******
parameters extracted from in—core diskiabel are:
cylinders=775221 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cglinders=775221 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning= BIOS sector numbering starts with sector 1
Information fron DOS bootblock is:
The data for partition 1 is
sysid 238 (0xee).(EFI GPT)
start 1, size 781422767 (381554 Meg), flag 80 (active)
beg: cyl 0/ head 0/ sector2;
end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

# gpart show ada1
=> 0    781422768   ada1    BSD    (373G)
     0                   16 - free - (0.0K)
    16   781422752  1  !0 (373G)

# gpart show ada1a
gpart: No such geom: ada1a

 

[SWirth]

Das fdisk auf /dev/ada1 gibt mir keine UFS Partition aus, die Anwendung auf die Platte, wie du sagst, schien mir aber auch am logischsten.
Dafür liefert die Ausgabe von dfisk /dev/ada1a etwas brauchbares wie gestern geschrieben.

 

[pit234a]

Wie immer hoffe ich, dass jemand das besser weiß. Mir ist das ein wenig unheimlich und nicht alles klar. Trotzdem möchte ich mal einen Verdacht äußern, quasi einen Schuss ins Blaue:
Deine zweite Platte (ada1 aus dem letzten Post) hat kein UFS-Dateisystem und wahrscheinlich auch kein anderes unterstütztes oder bekanntes und wohl auch überhaupt gar keins.
Deshalb funktioniert fsck in keinem Fall, alle Dateisystem (UFS) bezogenen Befehle (etwa mount) müssen versagen.


Wie komme ich zu dieser Aussage?

-Die Ausgabe von gpart show ada1 zeigt keine "Partionen". Der einzige vorhandene Eintrag zeigt keinen Dateisystem-Typ, sondern !0 und das kenne ich nicht, aber es sollte hier etwas stehen, das dem Dateisystem-Typ entspricht. http://www.win.tue.nl/~aeb/partitions/partition_types-1.html habe ich mal auf die Schnelle gefunden und das ist wohl komplett. Da werden die Typen in Hex gezeigt. !0 ist nicht dabei oder ich übersehe es. Für UFS sollte da in der gpart-Ausgabe 165 stehen, für HFS 175, für Fat(32) 12 und so weiter. Das Ausrufezeichen kann vielleicht eine "aktive" Partition bezeichnen, sicher bin ich da nicht. Aber dann steht immer noch "0" und das ist jedenfalls nicht UFS.

-Die Ausgabe von gpart show ada1a zeigt "No such geom: ada1a", das spricht auch dagegen, dass hier überhaupt ein Dateisystem angelegt wurde.

-Die Ausgabe von fdisk /dev/ada1 zeigt "The data for partition 1 is sysid 238 (0xee).(EFI GPT)". Das ist insofern merkwürdig, weil die erste Platte offenbar kein GPT-Schema zeigt. Wenn beide Platten im gleichen System aufgesetzt wurden, dann sollte das gleiche Schema verwendet werden (vorausgesetzt, es wurde über ein entsprechendes Tool durchgeführt, wie dies wohl bei nas4free über ein WebIf benutzt wird). Setzt man dies voraus, muss ein GPT-Schema an dieser Stelle wundern, kann vielleicht ein Hinweis auf eine unsachgemäße Änderung oder einen unerklärlichen Defekt sein.

-Die Ausgabe von file -s /dev/ada1a zeigt "/dev/ada1a: data" und das bedeutet, da ist nichts "Vernünftiges" zu finden. Das bedeutet nicht, keine Daten, sondern keine Angaben zum Dateisystem. Das Dateisystem kann vielleicht unbekannt sein, also nicht vom OS unterstützt. Wenn es kein (erkennbares) Dateisystem gibt, erwarte ich diese Ausgabe auch, habe aber damit keine Erfahrung.

In deinem Post hat die Platte mal gewechselt und war mal ada1 und mal ada2. Aber ich glaube, wenn ich das alles richtig deute, dann liege ich wahrscheinlich nicht ganz daneben mit meiner Vermutung. Und so ein Fehler lässt sich nicht durch Abstürze, Stromausfälle oder HW-Fehler eher nicht erklären. Viel wahrscheinlicher ist, dass da etwas falsch gemacht wurde. Inwieweit nun auf der Platte noch Daten vorhanden sind (sein könnten) und was da noch zu retten ist, das ist nicht zu sagen. Solche Analysen sind nicht einfach und "meine Augen sind nicht mehr gut genug, so genau hinzusehen", wie es dazu nötig wäre. Also, wenn ich so einen Fall hätte, dann würde ich die Daten abschreiben, die Platte neu aufsetzen und testen, ob sie zuverlässig läuft und dann je nach Ergebnis wieder benutzen. Ich habe da aber gut reden, denn ich folge der Einstellung, dass das, was wichtig ist, nicht auf einen Computer gehört. So kann ich nicht so schnell wichtige Daten verlieren.
Um meine Vermutung weiter zu stärken, könnten die Einträge der /etc/fstab aus dem System dienen, die diese Platte automatisch eingebunden hatte (falls es über die fstab realisiert war). Die Ausgabe von mmls aus dem sysutils/sleuthkit ist ebenfalls schön und gut lesbar, sie bringt aber keine weiteren wesentlichen Informationen.
Um eine weitergehende Analyse der Festplatte zu betreiben, gab es eben vor kurzem erst einen Thread in dem entsprechende Tools genannt werden.


Anders sieht das bei der ersten Platte aus, die du oben so dargestellt hast:
ada0
ada0s1
ada0s1a
ada0s2
ada0s2b
ada0s3
ada0s3a
Alleine daraus kann man schließen, dass kein GPT-Schema verwendet wurde, denn dann würden die "Partitionen" ein "p" im Namen haben, also etwa ada0p3a. Das "s" wird bei MBR-Schema benutzt. Bei MBR-Schema sollte disklabel (bsdlabel) auch zuverlässig funktionieren, also in der Ausgabe der angelegten Partitionen. Wahrscheinlich wurde diese ja auch damit gelabelt. gpart show und gpart list sollten aber ebenfalls funktionieren und ausreichende Information liefern. Wenn dann auf ada0sxa mit x von 1 bis 3 tatsächlich UFS-Dateisysteme liegen, dann würde fsck darauf angesetzt werden können, um diese zu reparieren. Dann, wenn sie fehlerfrei sind, sollten sie auch gemountet werden können. Doch, ich glaube, von dieser Platte haben wir bislang noch keine genaueren Angaben erhalten, außer eben das oben zitierte Partitions-Schema, das beim Booten erkannt und wofür dann Einträge in /dev vorgenommen wurden. Danach gibt es also drei "DOS-Partitionen" auf der Platte (die fdisk entsprechend zeigen würde, die also vom MBR aus adressiert sind) und in jeder dieser Partitionen gibt es eine "FreeBSD-Partition", die ein Dateisystem enthalten kann. Das sollte dann auch file -s anzeigen, aber im Grunde auch schon bei gpart show oder gpart list entsprechend auftauchen.
Es führt aber zu weit, alle möglichen Möglichkeiten nun durchzuspielen. Nachsehen und auf den konkreten Fall hin testen ist doch einfacher.

 

[SWirth]

Also UFS war mit Sicherheit drauf, ich hatte die Platten in regem Gebrauch. Die Platten sind mit massig Daten gefüllt.
Ja, auf ada0 ist das Betriebssystem installiert, das hatte ich neu eingerichtet. Beim mounten der Datenplatten bin ich dann gescheitert.
Ich hab mal im alten FreeNAS Handbuch gesucht, aber über die genauen Vorgänge beim Platten einbinden lässt man sich nicht aus. Klar, ein einfaches UI soll es übersichtlich machen.
Ein dump wie von Yamagi vorgeschlagen hab ich auch probiert um die Daten zu retten, der bricht aber immer mit einer Fehlermeldung ab. Die kann ich später mal nachreichen.
Egal wie die Aufteilung der Platte ist und wie diese Beschreibung (MBR) hingerichtet wurde, die Daten sollten noch drauf sein.

 

[KobRheTilla]

Alleine daraus kann man schließen, dass kein GPT-Schema verwendet wurde, denn dann würden die "Partitionen" ein "p" im Namen haben, also etwa ada0p3a. Das "s" wird bei MBR-Schema benutzt.

Nein, es heißt dann z.B. ada0p1, p2, p3, p4, pN. Das sN bezieht sich bei der BSD-Partitionierung auf den Slice, in dem Slice sind dann die Partitionen a, b, c, usw.

Rob

 

[pit234a]

Nein, es heißt dann z.B. ada0p1, p2, p3, p4, pN. Das sN bezieht sich bei der BSD-Partitionierung auf den Slice, in dem Slice sind dann die Partitionen a, b, c, usw.

Rob

ja. Wollte ich auch so darstellen. Hatte ada0s3a per doppelklick kopiert und dann eingesetzt, anschließend nur "s" durch "p" ersetzt und vergessen das "a" zu löschen.
Danke.

 

[pit234a]

Also UFS war mit Sicherheit drauf, ich hatte die Platten in regem Gebrauch. Die Platten sind mit massig Daten gefüllt.
Ja, auf ada0 ist das Betriebssystem installiert, das hatte ich neu eingerichtet. Beim mounten der Datenplatten bin ich dann gescheitert.
Ich hab mal im alten FreeNAS Handbuch gesucht, aber über die genauen Vorgänge beim Platten einbinden lässt man sich nicht aus. Klar, ein einfaches UI soll es übersichtlich machen.
Ein dump wie von Yamagi vorgeschlagen hab ich auch probiert um die Daten zu retten, der bricht aber immer mit einer Fehlermeldung ab. Die kann ich später mal nachreichen.
Egal wie die Aufteilung der Platte ist und wie diese Beschreibung (MBR) hingerichtet wurde, die Daten sollten noch drauf sein.

http://www.cgsecurity.org beschreibt sysutils/testdisk. Vielleicht hilft das. Es gibt auch gpt recover, aber ich glaube nicht, dass dies in deinem Fall helfen wird.
Alle diese Änderungen sollte man immer auf ein Image vornehmen oder umgekehrt, erst ein Image erstellen, das den momentanen Stand der Platte sichert. dd langt dafür, es gibt aber auch dafür tools.
Das Problem ist ja, dass fast alle Werkzeuge sich auf die Einträge verlassen, die sie da vorfinden und wenn in deinem GPT-Header oder in deinem MBR etwas falsch drin steht, können die das nicht auflösen. Da wird gar nicht erst nachgesehen, ob es Daten oder Partitionen irgendwo auf der Platte gibt.
Man kann, wenn man masochistisch genug veranlagt ist, zum Beispiel mit Hexdump die komplette Platte durchlesen und dann den Beginn einer Partition oder sogar von einzelnen Dateien finden. Das habe ich in meiner Jugend vielleicht ein oder zweimal gemacht. Nicht mehr wieder! Dafür hat man ja Tools, wie eben testdisk und es gibt noch einige weitere, die hilfreich sein können. Das meiste davon habe ich inzwischen vergessen, aber ich meine, manche Dinge aus dem sleuthkit waren auch hilfreich gewesen.

Alle Befehle, die du nun anwendest, lesen die Information aus dem GPT oder aus dessen PMBR und damit sind sie dann aufgeschmissen, denn diese Information zeigt nur, dass irgendwo eine Partition ohne Dateisystem liegt. Ich denke, das wird auch dump zum Fehler bringen. Dump würde auch nichts reparieren, es würde dir nur ein gutes Dateisystem sichern, damit du es nachher wieder zurück spielen kannst.
Du musst nun erst mal deine Partitionen wieder finden, in denen dann Dateisysteme sein müssen.