Festplatte defekt? Netzwerkkarte ne macke?

Sadakazu

Well-Known Member
Moin moin...
Ich hab hier grad nen frisches FreeBSD installiert....

Soweit war mit der Installation auch alles gut....
Jetzt logge ich mich grad am system an und will via pkg etwas an software installieren....
jetzt fängt pkg zwar an zu rödeln und sucht nach den entsprechenden Packeten und Abhängigkeiten....
Aber allein das heraussuchen von sudo hat geschlagene 10 minuten gedauert....

Da dachte ich mir... na dann scheint mit pkg ja was nicht in ordnung zu sein installierst mal nano lieber über die ports...
da aber das gleiche... jeweils wenn der Download eines quellpackets angestoßen wird, bleibt die kiste für einige minuten hängen....
Läd dann aber mit voller bandbreite (oder was der portserver hergibt) herunter....
Fängt dann auch an zu entpacken und kompilieren... bleibt zwischendurch kurz "hängen" aber setzt dann die arbeit fort...

Jetzt ist die frage, was da im argen liegt...
Entweder hat die Festplatte einen weg oder aber die Netzwerkkarte macht mucken....

Leider bin ich was S.M.A.R.T angeht nicht sonderlich versiert... aber in einigen Punkten hat die Systemplatte doch recht hohe werte...
Code:
Raw Read Error Rate 20074250 (Normalisiert: 072)
Seek Error Rate 496398414 (Normalisiert: 087)
Hardware ECC Recovered 20074250 (Normalisiert: 012)

Verwendete Platte ist eine Seagate ST33000650NS

Auf ssh anfragen oder auch Webanfragen reagiert die kiste allerdings sehr fix... also normal... wo mein verdacht dann doch ehr richtung Platte geht.....

Daher die Frage... wie bekomme ich heraus, woran es genau liegt?
 
@Kamikaze hast du die Antwort von dir wieder gelöscht? oder Spackt mein Browser grad rum?
Sei's drum... Antwort bezüglich des hostnamen....

Ja, ich kann den Rechner sowohl über die IP als auch über den hostnamen ansprechen....
Also gehe ich davon aus, das der Hostname "richtig" gesetzt wurde ;)

@KobRheTilla
Eigentlich ne ganze Menge ;) nur nichts hilfreiches im bezug auf die Festplatte selber...
Wobei...
Also ich hatte versucht nen RAID 1 aufzusetzen...
Da aber das Spiegeln schon 20 Stunden (bei "nur" 3TB) gedauert hat, hab ich den Verbund gar nicht erst gestartet...
Dort kommt aber für beide platten die Meldung das die GPT Table corrupt ist....
gpart recover ada0 und ada1 haben da leider keine abhilfe bei geschaffen....

Das spiegeln hatte ich auf nem anderen System nochmal versucht "nachzustellen" (nachdem 5 stunden vergangen waren und grad mal 25% gespiegelt waren) da allerdings mit 2x 2TB da hat das spiegeln etwa 4 stunden gedauert....

Wie gesagt... Festplatte läuft nicht im Verbund...

Ansonsten sagt dmesg das hier zu der Festplatte:
Code:
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <ST33000650NS 0004> ATA8-ACS SATA 3.x device
ada0: Serial Number Z292WD37
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 2861588MB (5860533168 512 byte sectors)
ada0: Previously was known as ad4
[...]
GEOM: ada0: the secondary GPT table is corrupt or invalid.
GEOM: ada0: using the primary only -- recovery suggested.
 
Das ist eventuell wieder einmal ein Problem mit spinnenden Timecountern. Dann "verliert" das System Zeit, es wirkt als würde es einfrieren. Bitte einmal die Ausgabe von:
Code:
sysctl -a | grep eventtimer
 
so, erstmal die Partitionstabelle:
Code:
=>        34  5860533101  ada1  GPT  (2.7T)
          34        1024     1  freebsd-boot  (512K)
        1058  5792332800     2  freebsd-ufs  (2.7T)
  5792333858    68199276     3  freebsd-ufs  (33G)
  5860533134           1        - free -  (512B)

1 Boot ist klar... 2 ist das FS selber und 3 ist swap... wobei ich mich grad ernsthaft frag was mich geritten hat 33gb swap anzulegen :O

Und dhier jetzt die ausgabe von sysctl
Code:
kern.eventtimer.periodic: 0
kern.eventtimer.timer: LAPIC
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2
kern.eventtimer.choice: LAPIC(600) HPET(550) i8254(100) RTC(0)
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.HPET.quality: 550
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.flags: 7
kern.eventtimer.et.LAPIC.quality: 600
kern.eventtimer.et.LAPIC.frequency: 50001429
kern.eventtimer.et.LAPIC.flags: 7

Es scheint aber tatsächlich am Netzwerk zu liegen.
grad versucht portupgrade über die ports zu installieren.....
cd /usr/ports/ports-mgmt/portupgrade && sudo make install clean
Code:
===>  License BSD3CLAUSE accepted by the user
===>  Found saved configuration for portupgrade-2.4.14,2
===>   portupgrade-2.4.14,2 depends on file: /usr/local/sbin/pkg - found
=> pkgtools-2.4.14_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/portupgrade.
=> Attempting to fetch http://distcache.FreeBSD.org/local-distfiles/bdrewery/pkgtools/pkgtools-2.4.14_GH0.tar.gz
fetch: http://distcache.FreeBSD.org/local-distfiles/bdrewery/pkgtools/pkgtools-2.4.14_GH0.tar.gz: Not Found
=> Attempting to fetch http://distcache.us-east.FreeBSD.org/local-distfiles/bdrewery/pkgtools/pkgtools-2.4.14_GH0.tar.gz
fetch: http://distcache.us-east.FreeBSD.org/local-distfiles/bdrewery/pkgtools/pkgtools-2.4.14_GH0.tar.gz: Not Found
=> Attempting to fetch http://distcache.eu.FreeBSD.org/local-distfiles/bdrewery/pkgtools/pkgtools-2.4.14_GH0.tar.gz

oder es war grad ein beschissenes beispiel :D
Nachdem er dann irgendwo das packet nach 8 Minuten suche gefunden hat gings dann auch recht flott weiter, auch mit dem dl der restlichen pakete... bis jetzt
Aber beim Kompilieren hängt er stellenweise kurz ^^
 
Und dann gleich das nächste ding...
Ist das normal das von der CPU alle 8 Threads unter vollast beim Kompilieren laufen?
Sowas kenn ich ehr von Virtuellen 2 Kern Maschienen....

CPU ist nen Intel Xenon E-31245 4 Kern 8 Threads mit 3,3Ghz....

htop.png
 
Hm alles klar... fehler gefunden... Lag tagsächlich am Netzwerk.... ipv6 war nicht korrekt konfiguriert....
 
Witzigerweise... jetzt nachdem ich erstmal ipv6 aus der rc.conf geschmissen habe geht auch das bauen selber schneller o0
klar... kurze hänger sind ja normal... aber nicht beim durchrasseln der config und abhängigkeitsprüfung für 2 minuten ^^ das ist wie gesagt jetzt nachdem ich ipv6 rausgenommen hab weg....
 
ist doch logisch: jede Netzverbindung versucht erstmal IPv6, wartet einen Timeout ab und versucht erst dann IPv4.
 
wenn das Netzwerk nicht richtig eingerichtet ist, gibt es manchmal ganz seltsame Phänomene. Das kann die ganze Maschine richtig lahm werden lassen - ich frage mich da auch warum, aber das ist meine Erfahrung.
 
Zurück
Oben