So ne FF Karte macht aus ner ziemlich alten Gurke einen VDR.
Warum entsorgen?
Mein Noch-Produktiv-VDR ist so ne alte Gurke und wird auch, wenn die neue Maschine am Start ist, immer noch als Ersatzmann auf der Bank beiben - für seine "Arterhaltung" hat er immerhin 15 Jahre gedient 
HJS
Die 1.7.1 und buildscripts vom 18.3. sind online.
Dialog für spätere Addons-config ist dabei.
glib2 und slang für mc zicken etwas rum, warum, ist mir noch nicht wirklich klar, aber mit fixierten Scripten in der alten Dreisatzversion (configure,make,make install) wird auch mc gebaut.
So kommt nun ein Basissystem mit nano oder mcedit als Editor, mc als Filemanager, dhcpcd und wget sowie dialog für alles was da noch folgen wird zustande.
HJS
Alles anzeigenoldconfig war der Versuch, einen nervigen Nebeneffekt zu beseitigen: Nach ner Dreiviertelstunde bleibt die Kiste stehen, weil der Build ein reconfig startet und wissen will, ob er die gcc-plugins aktivieren soll.
Da mir keine andere Erklärung einfällt, liegts wohl an den unterschiedlichen gcc für die config im Vorfeld mit dem gcc des Hosts und den build mit dem gcc des gebauten LFS.
Werds rausfinden.
Mal sehen, wie ich ihn dazu bringe, den Durchlauf nicht zu torpedieren.
Der andere gcc war offensichtlich die Ursache, ein "echo n ¦ make oldconfig" vor dem make bereinigt das Problem
Die jetzt verfügbaren buildscripts (160319) enthalten bereits die Korrektur.
HJS
Sodele
Ganz rund läuft die Geschichte noch nicht, aber sofern man seinen Kernel richtig konfiguriert, gibts n bootfähiges Ergebnis.
Wems grad in den Fingern juckt
Da keine der alten CDs die Vorraussetzungen für den Build des aktuellen SVN LFS erfüllt, empfehle ich z.Zt. den Einsatz von Debian als Host.
Sinnvoll, da erfolgreich getestet, ist die Version 9.4.
Aktuell unterstützen die Scripte KEINEN 32Bit Build, sondern bauen ein X86_64 System.
Wer keinen 64Bit fähigen Rechner hat, darf leider noch nicht mitspielen 
Wer eine config des gewünschten Kernels laden will, sollte das im menuconfig des Kernels erledigen, der Eintrag in der Konfiguration wird zwar - wie früher - ins Sourcen-Verzeichnis des Kernels kopiert, allerdings fahre ich ne "dreifach-Konfig" , make {oldconfig,defconfig,menuconfig}
defconfig, um sicher ein bootfähiges Ergebnis zu erhalten, es sei denn im Menuconfig schraub ich die "Garantie" wieder raus 
oldconfig war der Versuch, einen nervigen Nebeneffekt zu beseitigen: Nach ner Dreiviertelstunde bleibt die Kiste stehen, weil der Build ein reconfig startet und wissen will, ob er die gcc-plugins aktivieren soll.
Da mir keine andere Erklärung einfällt, liegts wohl an den unterschiedlichen gcc für die config im Vorfeld mit dem gcc des Hosts und den build mit dem gcc des gebauten LFS.
Werds rausfinden.
Mal sehen, wie ich ihn dazu bringe, den Durchlauf nicht zu torpedieren.
Grub wird derzeit NICHT installiert, mein favorisierter Bootloader ist derzeit rEFInd, aber noch nicht dabei.
Da rEFInd, wie schon der Name sagt, nur auf UEFI Systemen läuft, werde ich grub zwangsläufig wieder mit reinnehmen.
Da der Debian-Host grub mitbringt, ist das aber ja kein Weltuntergang 
Debian-9.4 installation "extra-nackig" mit reboot und der apt-get Zeile unten, bringt alles mit, was ein Host so braucht und passt auf ne ziemlich kleine Partition (4GB ist mehr als ausreichend)
apt-get install mc bison flex texinfo autogen gcc libncurses-dev build-essential gawk flex diffutils patch gettext automake binutils-dev libelf-dev libc-dev make dialog python3
Die Buildscripte der Ergänzungen zum LFS wie dhcpcd nano lynx und mc und vor allem wget muss ich noch mal leicht korrigieren.
der Build von wget, dhcpcd und nano ist erfolgreich, man kann also sourcen ziehen falls gewünscht/nötig.
Warum Intels igb partout mit den Namen eth0,eth1 unzufrieden sind und sich zu enp4s bzw enp6s umbenennen müssen, ist mir zwar schleierhaft, aber die Lösung der passenden Config der startscripte ist in Arbeit.
HJS
Ähem, den Tarball gibts da : hjslfs.org/hjslfs/hjslfs-1.7.1.tar.bz2
Alle VDRler im Bereich des Sees ausgewandert ?
HJS
Schaut keiner mehr in den Thread oder hat keine eine Karte von den Jungs im Einsatz ?
HJS
Sodele, zweites Gigabyte Board auch wieder retour. Hatte jetzt zweimal ein Gigabyte vor der Nase, NIE wieder, kostet einfach zuviel Nerven und Zeit.
Man nehme ein ASRock, setze den kleinen Ripper ein, betätige den Einschalter und es löppt.
Will Euch die Leidensgeschichte ersparen, es sei denn, jemand interessiert sich dafür
Mittlerweile hab ich tatsächlich ein laufendes HJSLFS mit 4.20.10 auf Basis des lfs-book-SVN vom 14.2. mit Default Zutaten (dhcpcd nano mc nebst DEPs)
Noch ein paar Kinken beseitigen, die "Verwaltung" anpassen, dann isses endlich soweit.
Erfreulich ist, dass das automatische Generieren der neuen Buildscripte aus dem LFS-Book mittlerweile ziemlich verlässlich ist,
Auch die Buildscripte fürs BLFS sehne schon recht ordentlich aus - zumindest die "simplen" also Libs, Tools etc pp, nich gerade X Kde und Konsorten.
Da die alten CDs nicht die Vorraussetzungen für den Build aus aktuellen Sourcen mitbringen, setze ich bis zum nächsten CD/DVD/USB Image Debian-9.4 als Host ein.
Die 9.6 und 9.8-testing, jetzt Stable, haben zu merkwürdigen Fehlern geführt, die allerdings auch auf meinen Spielereien mit der Vcore des Rippers oder auf Speicher, der seine Spezifikationen nicht einhält, basieren können.
Die Config eines X399 Boards mit "idealen" Werten ist eine Wissenschaft für sich, wenn man gerne die maximal mögliche Arbeits-Leistung mit möglichst geringer
Verlust-Leistung haben will.
Wens interessiert:
- Ripper unter 2GHz takten is nich
- Ripper auf 2GHz mit Vcore=850mV (865mV) löppt stable mit Tcpu um die 30° (lautlos) ca 40-45W
- Ripper auf 4 GHz mit Vcore=1181.25mV (1225.0 mV) löppt stable mit Tcpu bis 65° bei 100% Dauerlast (dezentes Rauschen der Lüfter) ca 160-165W
Alles, was nach 4GHz kommt, braucht deutlich mehr Spannung und fährt die TDP auf 220W und mehr und damit vermutlich auch die Tcpu über 68° (die Stelle, an der ich immer die Notbremse zieh), trotz Wasserkühlung.
Hier wäre wohl ein aktiver Wärmetauscher nötig, aber mit erheblichem Aufwand 10% mehr Leistung zu erreichen, ist nicht wirklich sinnig.
Falls der Speicher die Ursache für und-tschüss war, der erste Wert, falls nicht, der Wert in Klammern
ASRock gibt in den defaults 1225 mV bei 3.5GHz vor, und bietet im "OC" 3.75 GHz auf 4 Cores bei Vcore=1375mV an. Eher Zweckfrei
Genuch gesabbelt/tippelt
HJS
Alles anzeigenMan wird sehen ob das Konkurenz wird ...
In diesem Forum und diesem Post: https://forum.cesbo.com/topic/2034-tbs-6909/#entry28126, wird $400 kolportiert.
Danke Manfred ...
Regards
fnu
Aktuell 290 Stutz im Schwizer Ländli - hat jemand son Ding schon verbaut ?
Okta-Tuner ist vielleicht leicht übertrieben, aber bei ner Differenz von 30 gegenüber der Quad darfs auch etwas mehr sein ...
HJS
Ich würde erstmal ne fertige Distri nehmen, statt mich als Anfänger mit ner Softdecoder Lösung rum zu ärgern.
So erfährste auch, ob das Teil auch unter Linux im Betrieb abschmiert ohne einige vllt auch reichlich Nächte mit dem Teil bis zur Funktion zu verbringen.
HJS
Irgendwie ging das noch nicht so ab, nach ganzen 7 Tagen hat sich das Board verabschiedet,
Nu muss in der Wartezeit bis das Ersatzboard da ist, halt der QC wieder ran.
Werde wohl demnächst nen enen Thread eröffnen, mit der ersten 1.7er
HJS
Entweder hat (noch) keiner nen Threadripper im Einsatz oder falsches Forum
Da AMD so freundlich war, die Preise für die erste Generation der TR zu halbieren, befindet sich ein 1920x für weniger als 400 Stutz im Zulauf.
Mal gespannt, wie das abgeht ...
HJS
Bin immer noch da, abba die Feldfrüchte wollen geerntet werden, wenn sie reif sind, danach ist nicht so sinnig
Ich liebäugele gerade mit der Anschaffung eines neuen DEV Rechners, abba da brauch ich erst noch n paar Werte.
Bis vor 2 Monaten hab ich nen i7-8700K als Favoriten, durch den angekündigten i9-9900K und die Produktionsengpässe seitens Intel ist dessen Preis aber ja spürbar hochgegangen.
Gleichzeitig könnte man theoretisch den i9 für nen schlappen Hunni mehr kriegen, Dummerweise folgten den ersten vielversprechenden Berichten ja auch die Ernüchterung. Das Ding scheint die wieder verlötete Heatsink ja auch zwingend zu benötigen, um selbst bei regulärer Taktung nicht ständig kurz vor dem Grilltod bzw der Notabschaltung oder downstepping zu stehen.
Da hab ich mir dann mal den Mitbewerb angesehen. Von allen möglichen RyZen scheint mir der Threadripper 1920 als TwelveCore bei regulär 3.5/4.0G sehr interessant, zumal die Dinger 4Way Interleave auf ihren RAMs fahren (können).
Wäre nur sinnig, da keine Benchmarks für die Compilerarbeit zur Verfügung stehen ( zumindest finde ich keine, die sich auf C++ beziehen und Visual-irgendwas ist eher nicht relevant), jemanden zu finden, der son Ding ( und im Vergelich vielleicht n 8700K) im Einsatz hat und mal n Test fahren könnte ...
Gibbet da draussen jemand, der nen Threadripper im Einsatz hat ?
HJS
Eine SSD ist auch um Größenordnungen schneller. Und am PCIe habe ich bisher noch nie eine angeschlossen. Es ist nach wie vor durchaus gängig dafür SATA zu nehmen.
Und eine nvme ist wiederum um Grössenordnungen schneller als eine SSD via Sata.
Was gängig ist, ändert sich ja durchaus im Laufe der Zeit und wenn ich mir den Markt ansehe, gehen z.B. die "besseren" NB mehr und mehr in Richtung nvme oder nvme+HDD, wir sind also beim Ändern. Ob ich allerdings ne nvme im VDR einsetzen würde ... wohl eher nicht, wäre sinnfrei, es sei denn es kommt mir aud ein paar Sekunden Boot-Up-Time an, bzw bei Softdecodern mit X und pipapo sinds denn auch mal n paar Sekunden mehr, keine 5 Sekunden für "on" bis "Gui" natürlich WAF förderlich
Zurück zum Thema: Bei USB Sticks hab ich schon so unangenehme Erfahrungen gemacht, dass ich eher nen CF am Adapter nehmen würde
Generell würd ich eine wie auch immer angeschlossene SSD favorisieren mit Blick auf Preis/Leistung/Sicherheit .
HJS
Na ja, ehrlich gesagt ist auch bei mir alles semi-automatisch. Ich habe ein kleines tool in c geschrieben, was die jeweils aktuelle html Seiten der LFS-dev per wget holt, parsed und bash scripte erstellt.
Bin mittlerweile auf den tarball umgestiegen und bei mir machens halt die Herren sed, awk und die Dame grep
ZitatIch hab nochmal reingeschaut, auf dem server sollte ein komplettes LFS-dev vom Mai inklusive der build-scripte liegen (der Ordner 'bash_scripts'). Wenns bei irgendwo hakt, kannst du dort schmulen.
Immer sinnvoll. Thx
ZitatDie Scripte dort entpacken, patchen und bauen und räumen auf, so dass sich alles problemlos wiederholen lässt, wenn mal was schief läuft. Einige scripte sind von Hand editiert, wenn der Parser 'Mist' gebaut hat.
Leider stelle ich häufig fest, dass der Parser nur den Mist baut, den der Programmierer zulässt, bzw zwischen den Ohren hat
Abba weil sich das ja leider nicht immer vermeiden lässt, gedenke ich ja auch SVN-Tarballs weiterhin "im Sortiment" zu führen.
Mal davon abgesehen, dass man keinen Parser auf die Änderungen der nächsten Jahre einstellen kann, das musste auch jh feststellen ( falls er noch gelegentlich drüber schaut, hat ja auch schon lange keine neue Version mehr rausgelassen, war abba ja bisher auch nicht nötig, seit libelf schon.
Schön, dass Andere denn gleichen Weg gehen und auch straucheln, das beruhigt ungemein
HJS
Meine 60GB SSD im Vdr ist ca. 2 Jahre alt. Die war am Anfang für 1/2 Jahr in einem Windows PC verbaut. Auf die Platte wurden in den 2Jahren ca. 2TB geschrieben. Ohne regelmäßiges Trim wäre die Platte vermutlich schon tot.
Ernsthaft? Nach statistisch 30maligem Beschreiben jeder Zelle stirbt ne SSD ? Glaubste nicht wirklich oder ? Wenn das der Fall wäre, wäre die derzeit zum hjslfs-build benutzte nvme , mit Build auf 30GB ( immer die gleichen ) auch schon ziemlich tot.
HJS
..auf deinem ftp liegt noch eine komplette LFS stage1, die erst ein paar Wochen alt ist.
kannste mal sehen, wie oft ich in Dein Verzeichnis auf Meinem Server schaue
Hatte auch gar nicht mehr damit gerechnet, dass Du noch mal n Upload machst.
Hats dann also doch noch funktioniert - fein - Thx
Die Version, die mal angekommen ist, hatte ich mir angesehen, aber mich dann doch entschieden, Zähne zusammen beissen und durch.
Hatte leichte Probleme mit dem Handling und enweder alles händisch regeln oder n neues Script schreiben.
Da ich ja letztlich gerne meinen Weg weiterfahren wollte, haben meine Kronen halt leiden müssen
Aber vielen Dank. Könnt ich ja debian nach dem nächsten Kollaps wieder wechwerfen und n schönes LFS nehmen
Irgendwann zwischendurch hab ich denn auch mal erkannt, warum sowohl Du als auch jh den untar und rmsrc nicht in die Scripte packen. Als lfs kann das ziemlich nervig und nur mit hohem Aufwand automatisierbar werden.
Den untar übernimmt weiterhin das Buildscript, den rmsrc macht das Masterscript, da bin und bleib ich root.
Derzeit fahre ich den Host als lfs, den Rest zwangsweise als root : ich fands schon erstaunlich, das
im Host klappt, im system dagegen nicht.
Wie oben bereits erwähnt, werden die Fehlermeldungen i Ch6 immer rarer, der Weg zum vollständig einsatzfähigen Build ist nicht mehr weit.
Dann noch ch7&8 abhaken und die nötigen tools ergänzen, um das Ding zur CD, mittlerweile wohl eher DVD zu machen, um auch wieder mal nen aktuellen Host anbieten zu können.
HJS
Ächz, langsam kommt Licht ins Dunkel ...
Nachdem ich nun endlich den Grund für permanente Bauchlandungen bereits in gcc-pass1 stage2 heraus gefunden habe ( die Parameterübergabe bei Aufruf eines Scriptes mit der gleichen Bash Instanz funktioniert als root nicht mehr, lt Debian-aktivem Kollegen vor Ort haben die Jungs dort viel an der "Sicherheit" geschraubt ?!? ) muss ich nur noch meine Denkfehler und die Tücken des Parsens bewältigen .
- Erstaunlich, dass Dialog bei Verwendung von Umlauten eines anderen Zeichensatzes schlicht den Dienst verweigert
- Erschreckend, dass eine Parameterzuweisung die von ´04 bis ´13 funktionierte, bestenfalls einen Fehlermeldungshagel verursacht, dann weiss man wengstens, dass was nicht passt
- Übelst, dass man, durch Dauerfehler begünstigt, Messages im web Glauben schenkt, mit vielen gängigen Distris sei der Build von gcc wegen "unresolved symbols" bzw Header-Fehlern nicht möglich und man eine Distri nach der Anderen checkt und kickt - weil der Fehler wie erwähnt an ganz anderer Stelle liegt.
- Dumm gelaufen, dass beim configure als root von coreutils die Message kommt, man möge den "unsafe configure" per Parameter erlauben, aber kein Hinweis, dass dies auch beim make nötig wäre, um so unscheinbare tools wie env auch zu bauen.
- ganz Dumm gelaufen, wenn man zwar weiss, dass die Parameterübergabe nich mehr geht wie früher, aber leichtfertig statt in /mnt/lfs in / chrootet und dann selbstverfreilich seinen Host zum hangup und anschliessend beim reboot zur kernelpanic verurteilt, dezent geschrottet
Die Litanei will ich nicht fortsetzen, ist zu lang und interessiert vermutlich keinen.
Aber gibt es da draussen jemanden, der mit erklären kann, inwiefern es unsecure ist, die coreutils und _TAR_ als root zu bauen ? Insbesondere bei _TAR_ ??
Naja, viel Gesabbel, noch n bisschen biegen hier und schubsen dort, dann wirds ne 1.7 geben.
Anfangs nur mit dem Nachladen der vorbereiteten Buildscripte wie bisher und nur LFS.
Ziel der Dev-Runde ist die Option laden der jeweiligen SVN-Build-Tarballs oder Downloads des Books (wenn ich mal wieder anderweitig beschäftigt bin und der Buildtarball nicht online ist z.B.) und die Generierung der Buildscripte direkt aus dem Book, auch für BLFS ( das wird sicher noch lustig und ne Weile dauern )
HJS
[...] habe zwar parallel gesehen, dass auf sourceforge tatsächlich ein inoffizieller LFS-8.0-LiveCD-Build verfügbar ist und den mal pauschal gezogen,
Ne Live CD zum BLFS Build (lt Site) ohne wget ... 
HJS
Musste nur meine ersten Cds dünne halten und auf max 65 MB begrenzen, seither mit der Domain anfangs 10, derzeit glaub ich 20 GB.
Kost mich in der teuren Schweiz derzeit knapp 90 jährlich, das gönn ich mir
BN/PW haste in der 4-Augen-Ecke
HJS
Gebaut wird immer parallel auf allen maximal möglichen Kernen, die i7-7700T x86_64 hat.
Deshalb acker ich ja grad, hab z.Zt. nen i7-7700HQ mit ner nvme zur Nutzung ![:]](https://www.vdr-portal.de/images/smilies/pleased.gif){kind=small}
Da geht was, wenn ich denn mal endlich was lauffähiges hinkrieg, denk ich über nen Hexacore mit ner WD Black nach, im bezahlbaren Rahmen derzeit wohl optimal, zumal ich noch ner Filemaker App MySQL/PHP näherbringen muss.
Daher muss ich mit dem LFS mal langsam zu Potte kommen, die andere Geschichte wird besser bezahlt und n fms leidet auch nich unter was Zügigem.
HJS
Immer das bei mir aktuell noch laufende LFS, z.Z. ist mein vdr ein LFS-dev vom 08.02.2017.
War bis zur grossen Pause bei mir auch so, aber die Anforderungen sind nu halt zu hoch für das alte Sys
Ich generiere daraus dann immer halb-automatisch build-scripte lade mit wget die Pakete dazu herunter.
Das mach ich nu schon (annähernd fehlerfrei) vollautomatisch
Ich hab zum letzten Build noch alle sourcen, bash scripte und die tool chain.
mit tool chain meinst Du den Host, also den vorherigen Build oder schon den statischen /tool ?
Wäre interessant, habe zwar parallel gesehen, dass auf sourceforge tatsächlich ein inoffizieller LFS-8.0-LiveCD-Build verfügbar ist und den mal pauschal gezogen,
Allerdings wäre natürlich der Vergleich meine Scripte / Deine Scripte vielleicht auch sehr aufschlussreich , wobei ich schon ziemliche Gurkenscheiben auf den Augen haben müsste, um so gravierende Fehler der Scripte nicht zu erkennen ( bis gcc-pass2 isses ja nich weit ).
Mal davon abgesehen, machen auch die ausgeliehenen jhalfs Scripte ne Bauchlandung und sehen meinen ziemlich ähnlich ...
Haste nen ftp im Einsatz ?
HJS
