FreeBSD 12.1 Installer bleibt stehen beim Schreiben von src.txz, dann Reboot

lupo

Member
Ich versuche, FreeBSD 12.1 auf einem GIGABYTE BRIX mit 16GB RAM und 120GB SSD von SanDisk zu installieren.
Reproduzierbar bleibt das Schreiben von src.txz bei ca. 1-3 Prozent stehen, und nach etwa 15-20 Sekunden startet das System neu.

Das Installationsmedium, ein USB-Stick, habe ich geprüft; die Prüfsumme passt. Auch mit einem anderen Stick passiert das oben beschriebene.
Die SSD lässt sich ohne Auffälligkeiten aus /dev/zero komplett füllen.

Wenn ich src.txz nicht auswähle, läuft die Installation durch und das System lässt sich ohne Auffälligkeiten nutzen; einschließlich Xorg und Xfce.
Ich wüsste allerdings schon gerne, ob ich dem System "vertrauen" kann.

Hat jemand eine Idee?
 
Wird /var/log/bsdinstall_log auch geschrieben, wenn wie hier ein ungeplanter Reboot erfolgt?
Diese Datei habe ich weder auf dem Installationsmedium noch auf dem Zielsystem gefunden.
Letzteres war auch nicht "clean" und wollte ein fsck haben.
 
Sehen die Smart-Werte deiner SSD gut aus? Ein src.txz entpacken hat andere Zugriffsmuster als ein sequenzelles vollschreiben aus /dev/zero.
Was passiert wenn du auf dem (ohne src.txz) installiertem System händisch die src.txz entpackst? Was passiert wenn du den Portstree entpackst?
 
Ist im BIOS Zugriff per AHCI eingestellt? Ist das aktuellste BIOS drauf? Hast du zum Gegentest noch eine andere SSD oder gar Festplatte parat?
 
Hatte mit einer Transcend ein ähnliches Problem . Hab dann Windos auf die Transcend verschoben und FreeBSD auf die Intel installiert . Verdacht meinerseits nach durchlesen mehrerer Beiträge in div. Foren - es gibt Unterschiede wie Win und FreeBSD die gemeldete Blocksize interpretieren. Für einige SSDs gibt's quirks im Kernel. Bei 30 Euro für ne SSD so es nicht ein seltener Formfaktor ist würde ich da nichts riskieren
 
Für einige SSDs gibt's quirks
Gutes Stichwort. Das hatte ich heute morgen erst getippt, aber dann wieder verworfen.
Hatte vor kurzem mit diversen Billich-Samsungs in einem anderen Zusammenhang mit TRIM rumgefriemelt und noch auf keinen grünen Zweig gekommen. Die eine z.B. im anderen Rechner am SATA-Anschluss meldet: -> ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
Damit geht TRIM zumindest korrekt, SSD und Controller arbeiten harmonisch und hängen sich nicht gegenseitig auf.

Wenn ich src.txz nicht auswähle, läuft die Installation durch
Bei der Methode wäre die Ausgabe von sysctl -a | grep trim interessant.
 
Erst einmal danke an Euch alle für die Hinweise.

Sehen die Smart-Werte deiner SSD gut aus?

Die SSD hab ich vor ein paar Tagen neu gekauft; ich gehe bis auf Weiteres davon aus, dass sie keinen Defekt hat. In die Interpretation von SMART-Werten müsste ich mich auch erstmal einarbeiten.

Was passiert wenn du auf dem (ohne src.txz) installiertem System händisch die src.txz entpackst?

Während des Entpackens nach einer Weile ein ungeplanter Reboot, wie beim Installieren.

Ist im BIOS Zugriff per AHCI eingestellt?

Eine entsprechende Option hat das BIOS dieses BRIX nicht -- oder ich habe sie nicht gefunden?

Ist das aktuellste BIOS drauf?

Hab ich gerade gemacht. Ändert nichts; außer vielleicht, dass der Counter jetzt bis ca. 50 Prozent kommt.

Bei der Methode wäre die Ausgabe von sysctl -a | grep trim interessant.

Code:
kern.cam.nda.max_trim: 256
vfs.ffs.dotrimcons: 1

Kannst Du daraus etwas verwertbares entnehmen?

Hatte mit einer Transcend ein ähnliches Problem .

Hast du zum Gegentest noch eine andere SSD oder gar Festplatte parat?

Noch nicht; ich werde mir aber eine andere SSD besorgen. Diese erst einmal beiseite zu legen und es mit einer anderen zu probieren scheint mir im Moment das Vernünftigste zu sein.

Was meint ihr dazu?
 
Erst einmal danke an Euch alle für die Hinweise.



Die SSD hab ich vor ein paar Tagen neu gekauft; ich gehe bis auf Weiteres davon aus, dass sie keinen Defekt hat. In die Interpretation von SMART-Werten müsste ich mich auch erstmal einarbeiten.



Während des Entpackens nach einer Weile ein ungeplanter Reboot, wie beim Installieren.



Was meint ihr dazu?

Smart Werte kannst ja gerne mal hier reinposten, aber bitte als Code-Block wenn möglich.
Für mich ist da entweder ein Bug im Treiber oder ein HW defekt in Controller oder SSD.
 
Diese erst einmal beiseite zu legen und es mit einer anderen zu probieren
Ja, sehe ich auch so.

Eine entsprechende Option hat das BIOS dieses BRIX nicht -- oder ich habe sie nicht gefunden?
Versteckt sich auch gern bei 'native', 'IDE', 'RAID' usw., wobei ich aber glaube, dass man das zumindest für jetzt eher mal auf die Seite legen kann.

Kannst Du daraus etwas verwertbares entnehmen?
Nur dass du kein ZFS einsetzt. ;)

In die Interpretation von SMART-Werten müsste ich mich auch erstmal einarbeiten.
In der Zwischenzeit kann man ja nochmal weitergucken -> smartctl -a /dev/ada0 und camcontrol identify ada0 sowie dmesg | grep ada0
Da hiermit viel Textausgabe kommt, wärs ganz praktisch, wenn du das in spoiler-tags kippen könntest. Von mir aus auch gern in einen einzigen. :)
 
In der Zwischenzeit kann man ja nochmal weitergucken -> smartctl -a /dev/ada0 und camcontrol identify ada0 sowie dmesg | grep ada0
Da hiermit viel Textausgabe kommt, wärs ganz praktisch, wenn du das in spoiler-tags kippen könntest. Von mir aus auch gern in einen einzigen. :)

"spoiler-tags" sagt mir noch nichts. Mit *BSD beschäftige ich mich erst seit ein paar Tagen ...
Über eine kurze Erklärung würde ich mich freuen.

Die Ausgabe der drei Befehle habe ich ge-pastebin-ed; ich hoffe, das ist hier OK so.

https://pastebin.com/nsD4BSH0

Nebenbei: SanDisk bietet eine Software namens "SSD Dashboard" an, die unter Anderem auch Firmware-Updates können soll; aber die läuft erwartungsgemäß nur unter Windows. Man findet beim Suchen auch Hinweise, dass es ISO-Dateien geben soll, die auf CD gebrannt beim Booten davon das Firmware-Update durchführen, aber diese Methode scheint veraltet zu sein und wird vermutlich von SanDisk nicht mehr angeboten.

Auch wenn ich auf den Stress mit dieser SSD gut verzichten könnte -- Dass es ein Problem dieser Art überhaupt gibt, finde ich trotzdem interessant ...
 
"spoiler-tags" sagt mir noch nichts.
[spoiler] statts [code] Das war aufs Forum hier bezogen. pastebin geht natürlich auch klar. ;)

Für den aha-Effekt:
camcontrol identify ada0
pass0: <SAMSUNG MZ7LN128HCHP-000L1 EMT05L0Q> ACS-2 ATA SATA 3.x device
pass0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

protocol ACS-2 ATA SATA 3.x
device model SAMSUNG MZ7LN128HCHP-000L1
firmware revision EMT05L0Q
serial number S1ZMNXBG820391
WWN 5002538d00000000
additional product id
cylinders 16383
heads 16
sectors/track 63
sector size logical 512, physical 512, offset 0
LBA supported 250069680 sectors
LBA48 supported 250069680 sectors
PIO supported PIO4
DMA supported WDMA2 UDMA6
media RPM non-rotating
Zoned-Device Commands no

Feature Support Enabled Value Vendor
read ahead yes yes
write cache yes yes
flush cache yes yes
Native Command Queuing (NCQ) yes 32 tags
NCQ Priority Information no
NCQ Non-Data Command no
NCQ Streaming no
Receive & Send FPDMA Queued yes
NCQ Autosense no
SMART yes yes
security yes no
power management yes yes
microcode download yes yes
advanced power management no no
automatic acoustic management no no
media status notification no no
power-up in Standby no no
write-read-verify yes no 0/0x0
unload no no
general purpose logging yes yes
free-fall no no
sense data reporting no no
extended power conditions no no
device statistics notification no no
Data Set Management (DSM/TRIM) yes
DSM - max 512byte blocks yes 8
DSM - deterministic read no
Trusted Computing no
encrypts all user data no
Sanitize no
Host Protected Area (HPA) yes no 250069680/250069679
HPA - Security yes no
Accessible Max Address Config no

Ich habe da nun aber keine Auffälligkeiten gesehen, sieht alles i.O. aus.

Firmware-Update wäre natürlich ein Versuch. Ggf. kann ich dich dafür begeistern, denn win10 vom USB-Stick auf SSD ist in 15 mins schaffbar. Key braucht man ja nicht für einen 'Test' unter 30 Tagen. ;)

Dass es ein Problem dieser Art überhaupt gibt, finde ich trotzdem interessant
Willkommen im schmutzigen Tümpel der IT, das ist so lange interessant, bis es frustet. :p
Aber tröste dich, die SanDisk hat kein Vermögen gekostet.

Edit: Wenn es im BIOS was in Richtung SATA aggressive power management gibt, das mal deaktivieren.

Nun bin ich aber ideenlos.
 
Ich weiss nicht ob es irgendwo schon erwähnt wurde, aber ich würde auch den RAM mit Memtest checken.

Das hatte ich schon versucht, aber es ist mir nicht gelungen, memtest86+ auf dem installierten System zu starten.

Für den Befehl

Code:
N:ad(M,a)/boot/opt/memtest86+

weiß ich noch nicht, wo und wie ich ihn ausführen kann. Er ist für den "boot prompt" vorgesehen, aber wie erreiche ich den?

Und als Antwort auf den Befehl für den "loader prompt"

Code:
load boot/opt/memtest86+

bekomme ich

Code:
don't know how to load '/boot/opt/memtest86+'

Über sachdienliche Hinweise würde ich mich freuen.
 

Hatte ich schon mal gefunden und ausprobiert, jedoch ohne Erfolg:

Code:
OK boot /boot/opt/memtest86+
Loading kernel...
Failed to load kernel '/boot/opt/memtest86+'
can't load 'kernel'

Der Post ist knapp 8 Jahre alt; ich könnte mir vorstellen, dass sich zwischenzeitlich etwas verändert hat. Die Befehle, die ich oben zitiert hatte, bekommt man aktuell beim Installieren von memtest86+ mit pkg genannt.
 
Und bei memtest drauf achten, das aktuelle läuft nur mit UEFI, falls dies nicht vorhanden ist, die ältere Version herunterladen
 
Habe mal nach dieser spez. SATA SSD und FreeBSD im weltweiten Netz geschaut
Gibt 'nen Thread bei FreeNAS < https://www.ixsystems.com/community/threads/freenas-installer-sandisk-ssd-checksum-errors.64049/ >
Ich zitier mal daraus:
+- vfs.zfs.trim.enabled=0 ==> Fehler geht weg (das ist aber m.E. mehr zum Experimentieren, da TRIM ja automatisch gehen sollte, die Admins mögen mich korrigieren wenn's nicht stimmt)
+- Looks like at least some of the affected drives have firmware UE3600RL flashed, whereas my working unit has firmware UE3000RL.

Aber wie schon Leonardo da Vinci gesagt hat: "Man muß nicht alles glauben was im Internet steht" (Quelle: Internet)

2. Du kannst "Nomad-BSD" vom Stick laufen lassen damit du ein funkionierendes BSD incl. GUI hast und dann die SSD mounten und experimentieren, falls du willst. Aber eine SSD von deren Funktion man nicht 100% überzeugt ist, würde ich nicht für Produktiv Systeme verwenden (Fehler im falschen Moment, bei meiner Transcend gab's kein Gemecker, die Daten waren nur kaputt).
 
Reproduzierbar bleibt das Schreiben von src.txz bei ca. 1-3 Prozent stehen, und nach etwa 15-20 Sekunden startet das System neu.

Da ist natürlich was faul.
Aber, nur zum Verständnis, weil hier so vehement der Fehler beim lokalen Speichermedium vermutet wird: Wieso installierst du denn überhaupt die Sources sofort schon mal? Hast du es mal ohne versucht? Die können ja später noch gezogen werden.

Ich meine, wenn genau da irgendein Bug liegt oder sogar im Zusammenhang mit einem einzigen Server auftritt, sollte man das doch ermitteln und ausschließen?

Der Tip mit nomad-bsd ist alleine schon deshalb gut.

Allerdings kenne ich selbst keinen entsprechenden Fehler, der ein System zu einem nachvollziehbaren Restart zwingt. Da denke ich eher in Richtung HW, wie auch meine Vorredner.
 
Allerdings kenne ich selbst keinen entsprechenden Fehler, der ein System zu einem nachvollziehbaren Restart zwingt. Da denke ich eher in Richtung HW, wie auch meine Vorredner.

Davon bin ich auch ausgegangen. Ich hoffe, dass nicht der Eindruck entstanden ist, ich würde FreeBSD / dem Installer einen Bug unterstellen. Ein Hardware-Defekt (oder ein PEBKAC) ist doch um Größenordnungen wahrscheinlicher :)
 
Zurück
Oben