newfs auf USB Festplatte hängt

Hallo,
vielleicht kan mir jemand sagen was das ist (freeBSD 9.0 / PC Intel Pentium III (Copermine) 733Mhz / 256MB RAM ):

Ich habe eine externe USB Festplatte an den freeBSD-Rechner gehängt. Sie ist relativ neu mir USB 3.0 und hat 3 Partitionen für Backups:

Code:
# gpart show da0
=>        63  3907029104  da0  MBR  (1.8T)
          63  2727949392    1  ntfs  (1.3T)
  2727949455   630792225    2  ntfs  (300G)
  3358741680   548287487     3   !6  (261G)

Auf die 3. Partition soll eine BSD-Sicherung:

Habe die 3. P nochmal gelöscht (hatte ich mit Windows angelegt, nicht formatiert, geht aber trozdem nicht --> !6)
Code:
# gpart delete -i 3 /dev/da0
und wieder neu angelegt:
Code:
# gpart add -i 3 -s 261G -t freebsd /dev/da0    
da0s3 added
dann möchte ich die Partition formatieren:
Code:
# newfs /dev/da0s3
/dev/da0s3: 267264.0MB (547356656 sectors) block size 32768, fragment size 4096
        using 362 cylinder groups of 740.00MB, 23680 blks, 47360 inodes.
super-block backups (for fsck -b #) at:
 192, 1515712, 3031232, 4546752, 6062272, 7577792, 9093312, 10608832, 12124352, 13639872, 15155392, 16670912, 18186432, 19701952, 21217472, 22732992,
 24248512, 25764032, 27279552, 28795072, 30310592, 31826112, 33341632, 34857152, 36372672, 37888192, 39403712, 40919232, 42434752, 43950272, 45465792,
 46981312, 48496832, 50012352, 51527872, 53043392, 54558912, 56074432, 57589952, 59105472, 60620992,
hier bleibt er immer wieder hängen :confused:

Fehlermeldung:
Code:
ugen0.2: <Seagate> at usbus0 (disconnected)
umass0: at uhub0, port1, addr2 (disconnected)
(da0:umass-sim0:0:0:0) lost device - 1 outstanding)
(da0:umass-sim0:0:0:0) outstanding 0)
yeah - outstanding! :)

Ich habe schon mal eine ältere USB-HDD mit dem Rechner auf freebsd formatiert -
ich verstehe nicht was da jetzt los ist bzw warum?

Kann man mir helfen - Und was könnte man machen?
 
Gibt es einen Grund newfs auf zu rufen ohne zu sagen welches fs auf der Partition sein soll?

Edit: Sorry, habe das mit mkfs verwechselt :( aber evtl solltest du statt

gpart add -i 3 -s 261G -t freebsd /dev/da0

lieber

gpart add -i 3 -s 261G -t freebsd-ufs /dev/da0

nutzen, da die gpart man zu -t freebsd sagt

freebsd A FreeBSD partition that uses the BSD disklabel to sub-
divide the partition into file systems. This is a legacy
partition type and should not be used for the APM or GPT
schemes. The scheme-specific types are "!165" for MBR,
"!FreeBSD" for APM, and
"!516e7cb4-6ecf-11d6-8ff8-00022d09712b" for GPT.

hth
ath0
 
Zuletzt bearbeitet:
es ist schon eine Weile her, dass ich da mit gpart rumgespielt habe und so viel ich mich erinnere, sind die Namen, die man da beim Anlegen einer Partition vergibt, relativ egal gewesen. Ich konnte auf eine als freebsd-ufs angekündigte Partition ebenso ein ext2fs drauf lassen und das funktionierte vollkommen Problemlos.

Weil dein newfs anfängt zu laufen, kann das eigentlich nur alles soweit in Ordnung sein und ich tippe auf ein HW-Problem.
Du kannst natürlich alternativ auch bsdlabel einsetzen.
Das wird nicht viel ändern.
Mit gpart hast du einige Möglichkeiten, das Alignement zu beeinflussen und ich würde vielleicht gar nicht die Größe angeben, sondern den vollen Rest der Platte benutzen.

Worin ich nun unsicher bin, was aber vielleicht noch ein Hinweis für dich sein könnte: gpart kann GPT und ich hatte es damals speziell dafür genutzt, mit GPT anstatt MBR zu spielen. Du hast offenbar einen MBR und vielleicht gibt es dafür eine eigene Synthax, wenn gpart auf MBR benutzt werden soll. Ich weiß es nicht und sehe nun nicht nach, doch ich könnte mir das vorstellen.

Trotzdem, wenn er anfängt newfs einzurichten und dann abbricht, wie das bei dir zu sehen ist, mit Verlust des Devices, dann wackelt da was an der HW, würde ich sagen.
 
Hallo,
und erst mal vielen Dank für die umfangreichen Antworten.

Also: ich hatte früher immer sysinstall benutzt aber mit freeBSD 9.0 ist das absolete - und ich hatte auch ein paar Probleme mit dem neuen bsdinstall. Daher habe ich die Platten des Systems mit der Kommandozeile eingerichtet und da hat mir das für mich
neue gpart besser gefallen. Das hat auch gut funktioniert.
Da die externe USB-HDD auch für Windows Sicherung genutzt wird hat die USB-Platte eine MBR Partition.
Die Angabe ... -t freebsd-ufs ist bei GPT partitionierten Platten schon richtig. Aber bei der MBR erhalte ich nur eine Fehlermeldung. In einer Beschreibung "MBR -Platten mit gpart formatieren" habe ich gelesen das man dann "-t freebsd" nehmen soll - sicher würde auch "!165" gehen da das ja für "freebsd" UFS steht.
Weil dein newfs anfängt zu laufen, kann das eigentlich nur alles soweit in Ordnung sein und ich tippe auf ein HW-Problem.
Ja, das habe ich auch schon vermutet. Die externe Platte (seagate desktop storage) ist aber neu.
Ist vielleicht 161GB zu groß für den alten Rechner?
Ich habe inzwischen noch eine etwas andere Fehlermeldung gesehen, mit sbus oder so - die poste ich, wenn ich heute Abend wieder am Rechner bin.
Die Frage ist auch, wie spüre ich den Hardwarefehler auf wenn newfs ja erst am los läuft? Es wird anscheinend sporadisch irgendwie mittendrin bei newfs die externe HDD rausgeschmissen :confused:
Grüße Harald
 
Hing das an der CPU?
ich glaube doch, das es dabei um ältere Betriebssysteme ging, die das nicht implementiert hatten.

In meinem Behufe (das hört sich doch irgendwie schräg an, oder?) habe ich nun keine wirklich großen externen USB-Platten, aber immerhin doch mehrere mit 1TB. Die funktionieren mit FreeBSD und diversen Dateisystemen gut, manchmal gibt es das ein oder andere Problem, hauptsächlich bei ext2fs.
P3 habe ich derzeit keinen im Einsatz, aber ein P4 kann das.
Nebenbei: busybox/Linux kann es auch (natürlich nicht mit FreeBSD-Dateisystemen, aber mit ext2 oder reiserfs) und zwar auf einer CPU (RISC) mit, ähm, lass mich nachsehen:
Code:
root@dreambox:~> cat proc/cpuinfo 
processor       : 0
cpu             : STB04xxx
clock           : 252MHz
revision        : 9.82 (pvr 4181 0952)
bogomips        : 250.88
machine         : Dream Multimedia TV Dreambox
plb bus clock   : 63MHz
und dazu gibt es auch nur wenig Speicher. Die ssh-Verbindung habe ich nun voreilig wieder geschlossen und warte daher nicht mit konkreten Zahlen auf. Aber das könnte immerhin ein Beleg dafür sein, dass auch schwache CPUs mit wenig Speicher durchaus große Platten und Partitionen meistern können.

Im aktuellen Fall würde sich das Verhalten natürlich sehr genau durch solch einen Bug erklären lassen.

Meine Vermutung bleibt aber, das sogenannte Bauchgefühl, dass es ein HW-Problem ist.
Nun ist natürlich die Frage berechtigt, wie du so etwas finden kannst. Der Fehler kann auf der Platte, dem zugehörigen Kontroller, am verwendeten Kabel oder der Anschlussbuchse und schließlich am Board, bzw dem integrierten Kontroller auf dieser Seite liegen (so es ein HW-Fehler ist). Die Regel sagt: tausche Reihum und beobachte, ob der Fehler mit wandert.
Es gibt diese Geschichte, wo man sich über jene Strategie oder besser gesagt ihre Protagonisten lustig macht und fragt, wie denn ein Computertechniker herausfindet, wenn er einen Platten hat und die Antwort ist dann, dass er einen Reifen nach dem anderen tauscht... Was dabei im Gelächter verloren geht, ist die Tatsache, dass die Methode auch da erfolgreich angewendet werden kann! Zur Fehlersuche ist dies eine der besten und einfachsten Möglichkeiten, ohne großen Messaufwand einen Verdächtigen zu finden.

Ein anderer Punkt könnte das externe Netzteil der Platte sein, oder ein eingebauter Befehl zum Standby, der ausgerechnet nun Chaos verursacht.

Was würde ich machen?
(Das hört sich unerhört großspurig an, soll es aber nicht). Wie beschrieben würde ich versuchen, dem Fehler auf den Leib zu rücken und sinnvoll Komponenten zu tauschen und sehen, was sich dabei ergibt.
Dazu würde ich auf einer der Windows-Maschinen, wo die Platte gut läuft, eine Live-CD (oder -Stick) starten und sehen, was dabei zu finden ist. Ich würde mit einem GNU/Linux starten (Knoppix als erste Wahl, weil das eine GUI zu (g)parted bietet, die wirklich einfach zu bedienen ist und Umfassende Möglichkeiten bietet). Danach, wenn ich also die Freie Partition hier problemlos nutzen konnte, würde ich selbiges unter der FreeBSD-Maschine probieren. Das kann dann schon wirklich gute Hinwiese liefern.
Danach nähme ich die gleiche Prozedur mit einer FreeBSD-Live auf den unterschiedlichen PCs vor. Dann sollte ich wirklich wissen, woran ich bin.

Wenn sich der Zustand nicht ändern lässt und es auf deinem FreeBSD-Rechner einfach nicht geht, würde ich versuchen, die Platte als Netzwerkfreigabe zu nutzen und von einem Microsoft-System aus hosten zu lassen. Dabei ist das Dateisystem nahezu egal. Windows muss es halt beherrschen.
 
Hi HaraldLanger,

unabhänig von der HW könntest du noch was probieren. Beim anlegen der 3.Partition schadet es nicht, wenn du die 'Größe' weglässt. Somit wird der restliche Verfügbare Platz berechnet und genutzt, evtl bleibt ein kleiner Rest 'frei'. Könnte vielleich was ausmachen, bin mir nicht sicher.

# gpart add -t freebsd -i 3 da0

Eigentlich ist der Partitionstyp 'freebsd' ein Container der Sub-Partitioniert wird, so wie mit dem 'bsdlabel' eben. Ich gehe davon aus dass dein 'Fehler' nicht daran liegt. Im folgenden Beispiel hab ich meinen 512er-USB-Stick benutzt, eine fat32 und eine freebsd partition angelegt und diese Unterteilt.

Code:
[root@callisto ~]# gpart show da0
gpart: No such geom: da0.
[root@callisto ~]# gpart create -s mbr da0
da0 created
[root@callisto ~]# gpart add -t \!11 -s 128m da0
da0s1 added
[root@callisto ~]# gpart add -t freebsd da0
da0s2 added
[root@callisto ~]# gpart show da0
=>    32  964576  da0  MBR  (471M)
      32  262144    1  fat32  (128M)
  262176  702432    2  freebsd  (343M)

[root@callisto ~]# gpart create -s bsd da0s2
da0s2 created
[root@callisto ~]# gpart show da0           
=>    32  964576  da0  MBR  (471M)
      32  262144    1  fat32  (128M)
  262176  702432    2  freebsd  (343M)

[root@callisto ~]# gpart show da0s2
=>     0  702432  da0s2  BSD  (343M)
       0  702432         - free -  (343M)

[root@callisto ~]# gpart add -t freebsd-ufs -s 128m da0s2
da0s2a added
[root@callisto ~]# gpart add -t freebsd-swap -s 128m da0s2
da0s2b added
[root@callisto ~]# gpart add -t freebsd-ufs da0s2         
da0s2d added
[root@callisto ~]# gpart show da0s2                       
=>     0  702432  da0s2  BSD  (343M)
       0  262144      1  freebsd-ufs  (128M)
  262144  262144      2  freebsd-swap  (128M)
  524288  178144      4  freebsd-ufs  (87M)

[root@callisto ~]# newfs -U -j da0s2a
/dev/da0s2a: 128.0MB (262144 sectors) block size 32768, fragment size 4096
        using 4 cylinder groups of 32.03MB, 1025 blks, 4224 inodes.
        with soft updates
super-block backups (for fsck_ffs -b #) at:
 192, 65792, 131392, 196992
Using inode 4 in cg 0 for 4194304 byte journal
newfs: soft updates journaling set
[root@callisto ~]# newfs -U da0s2d   
/dev/da0s2d: 87.0MB (178144 sectors) block size 32768, fragment size 4096
        using 4 cylinder groups of 21.75MB, 696 blks, 2816 inodes.
        with soft updates
super-block backups (for fsck_ffs -b #) at:
 192, 44736, 89280, 133824
[root@callisto ~]#
 
Zurück
Oben