Sodele, der Garten ist im Groben versorgt, nu gehts denn bald weiter.
Meine Cinergy ist eingetroffen und die Spiele können beginnen 
HJS
Posts by hjs
-
-
Nu is die 1.7.8 online.
Wie bereits oben erwähnt, bauen die Scripte auf nem 32Bit Host n 32Bit LFS, auf nem 64er einen 64Bit LFS.
Grub-target wird ebenfalls angepasst, falls sich grub-configure darum scheren sollte ...
HJS
-
Mein lieber Herr Gesangsverein!
Wollte mal wissen, ob die Scripte auch n 32Bit sys schaffen, da momentan keine akzeptable PCIe S2 Karte in Sicht ist, muss ich vielleicht mein altes Sys mal neu baue.
Gesagt, getan, Fossil ausgegraben, Debian drauf, Scripte anschubsen und manuell eine kleine Korrektur vornehmen, ne gute Stunde später ins log schauen und "out of Memory" im log des gcc-pass1 finden, grmpf, anderes Fossil beklauen, nochmal bittscheen ...
nach vier Stunden gings mir auf den Sack und ich hab meinen beiden 64Bittern einen 32Bit Host aufgenötigt, mit Installieren des Hosts inkl. aller Zutaten und Scriptdurchlauf, waren beide immer noch deutlich vor dem "echten" 32 Bitter fertig, aber beide brauchten für den 32 Bit Build die doppelte Zeit, die sie für den 64er gebraucht haben, Dass ein 32Bit Build sicher nicht mit doppelter Geschwindigkeit belohnt wird, war sicher, aber nur mit halber?
Naja, um für ein alterschwaches 32Bit system noch schnell n neues LFS aufzusetzen, ist auch doppelte Zeit noch wesentlich besser, als der 32Bitter benötigt, um sich sein neues Sys selbst zu bauen.
Wens interessiert:
C2Duo@1.8G, 2G DDR2 64G SSD Host: deb10rc1 : 6:45
64 Bitter 512G NVME gleicher Host : 1:30 (64Bit 0:43)
Nichtsdestotrotz werde ich in Kürze die 1.7.8 online haben, die kann dann mit nem 32Bit Host ein 32Bit LFS oder mit nem 64Bit Host ein 64Bit LFS bauen
HJS -
Sodele, in den Buildscripts v. 1.5. sind denn auch der efibootmgr nebst seinen Abhängigkeiten efivar und popt drin und schon klappt auch der Install von rEFInd.
Erschreckend ist, dass ich keinen tarball uploaden kann, angeblich ist da n Virus drin ... glaub ich nich wirklich, abba wir werden sehen ...
HJS
-
Das install-script meldet, mit dem efi-bootmanager stimmt was nicht...
Offensichtlich is keiner da, wozu sollte unter LFS sowas auch installiert werden
Kopieren des eigentlichen "Bootmanagers" ins Standard-efi-boot Verzeichnis mit dem Standardnamen führt zwar zum Boot aber leider muss man das gleiche Ding nochmal aufrufen, um zur GUI zu gelangen.
GUI is nich so zwingend, aber ein unfeiner Nebeneffekt ist, dass der "Boot-selektor" als "Boot-Manager" nur bootfähiges auf der Platte zeigt, auf der er installiert ist, typischweise findet rEFInd aber alles, was irgendwie ausführbar ist, auf jeder Platte.
Legt man nicht nur den Manager, sondern auch all seine (benötigten) Files mit nach EFI/Boot, dann klappts auch mit dem Nachbarn.
Allerdings hat man dann keine mehrfach-manager Option, was rEFInd nich starten kann, startet halt nicht ...
Daher werd ich mich mal um den grundlegenden "Bootmanager" kümmern, dann klappts nicht nur mit Einem, sondern mit allen Nachbarn
HJS
-
Die 1.7.7 ist online.
Grub find ich immer noch doof - im Vergleich mit refind, allerdings konnte ich den Fehler mit nem i386er grub nicht sauber booten zu wollen an der üblichen Stelle finden
Wenn ich an der gleichen Stelle den Grund für das schlichte ignorieren der o.g. configure Parameter finde, is ja alles gut, aber da glaub ich nu nich dran.
Nu kann man zumindest schonmal ne UEFI Partition bestimmen, falls Grub sich mal zusammen reisst oder rEFInd ihn in der Versenkung verschwinden lässt.
Auf Platten mit GPT sollte man 1M für ne BIOS-Boot-Partition "verschwenden", dann klappts auch mit dem 386er grub.
rEFInd is noch nich drin, da ichs bisher interessanterweise auf beiden Maschinen nicht geschafft habe, die Scripte zu installieren und beim boot die gewünschte GUI mit den verfügbaren Systemen zu sehen.
Das install-script meldet, mit dem efi-bootmanager stimmt was nicht...
Kopieren des eigentlichen "Bootmanagers" ins Standard-efi-boot Verzeichnis mit dem Standardnamen führt zwar zum Boot aber leider muss man das gleiche Ding nochmal aufrufen, um zur GUI zu gelangen.
GUI is nich so zwingend, aber ein unfeiner Nebeneffekt ist, dass der "Boot-selektor" als "Boot-Manager" nur bootfähiges auf der Platte zeigt, auf der er installiert ist, typischweise findet rEFInd aber alles, was irgendwie ausführbar ist, auf jeder Platte.
HJS
-
Nu kann man sich auch für nen 5er Kernel entscheiden und die Sourcen werden auch tatsächlich gefunden und geladen
Grub install ist grundsätzlich wieder möglich, aber ich bin immer noch nicht begeistert.
Defaultmässig für ne Platform i386-pc zu bauen, obwohl er auf ner x86_64-efi läuft, find ich schlicht doof, zumal beide 64Bitter, die mir zur Verfügung stehen damit schlicht nicht booten wollen ( nicht sauber )
Sich darüberhinaus über "--target=x86_64 --with_platform=pc" hinwegzusetzen und dann tatsächlich x86_64-efi zu bauen (also platform stumpf zu ignorieren), das dann aber nicht zu installieren, weil: "Fehler 0x04 Ersetzung nicht supported", ist schlimmer als nur doof.
Jedenfalls sind die beiden Parameter nun so im grub-build-script fixiert, vielleicht komm ich ja noch hinter den Grund für den 0x04
HJS
-
Da hatte sich ein Kinken in der Partitionierung eingeschlichen - fixed
Nu kann man auch von Haus aus "removable" Massenspeicher für den LFS Build verwenden.
Bisher waren "echte" USB Sticks fürs LFS nicht verwendbar.
HJS
-
Die 1.7.5 ist online, Buildscripte vom 11.4.
In den Buildscripten ist ein kleiner Kinken in libc entsorgt und slang-2.3.2 ist nu auch auf meiner HP angekommen
.Die 1.7.5 bietet die Möglichkeit den Build vollständig auf der Host Partition, also im Verzeichnis /mnt/lfs zu fahren.
Man kann nach dem Build eines Packages den Erfolg checken lassen und bei Misserfolg das Gleiche nochmal versuchen lassen.
Ist mehr für mein Debugging gedacht, genauso wie die Option, das Arbeitsverzeichnis (/mnt/lfs/sources) mit einer Ramdisk zu belegen.
Da unsere geliebten SSDs ja keine unendlichen Schreibkapazitäten haben, lässt sich die Platte schonen oder auch nen alter magnetischer Mtbewerber.
Zusätzliche Geschwindindigkeit bringt die Ramdisk bei ner nvme eher im homöopatischen Bereich, bei ner "echten" Platte sieht das wohl anders aus.
Dort gibts noch keine Sicherheitsabfrage: Wenn dort was anderes als "n" oder "N" steht, wird ne RDisk dieser Grösse gemounted,
Sinnvoll erst ab min 16G, da beim Bauen der grossen Packages doch einiges an Platz gebraucht wird, sind hier Werte um 6G - 8G sinnvoll.
Ein zu kleiner Wert torpediert den Build, ein zu Grosser selbstverfreilich auch.
HJS
-
Hch - immer diese Kopfhörerfehler
Die 1.7.4 kommt vorbereitend mit den dosfstools daher - auf ner jungfräulichen Platte ne EFI Partition anlgen, aber zum Formatieren WinDoof benötigen is doof.
Ausserdem ist bereits ein "mini"-Addonsetup/config enthalten ( z.Zt. nur separat zu starten, mit dessen Hilfe man sich durch die BLFS-Scrpte hangeln kann und entweder zur späteren Verwendung eine Liste erstellen kann oder zum gewählten Script die Source ziehen ( sobald man ihm sagt "sofort bauen" ) und das Build-Script anstossen kann.
Eine Berücksichtigung der (vorhandenen) Optionalen , Empfohlenen oder zwingend nötigen anderen Packages findet allerdings noch nicht statt.
Die Fileselectbox von Dialog ist etwas gewöhnungsbedürftig, aber wenn man sich ersma dran gewöhnt hat ...
HJS
-
Die 1.7.3 ist online.
Offensichtlich ist slang auch in den älteren Versionen gemütlich - fiel mir beim Nachbauen nicht auf, weil die MAKEFLAGS nicht gesetzt waren
Daher jetzt wieder das Orig BLFS Script mit leeren MAKEFLAGS drin, nu is auch mc da
Eine wegen Dummheit nicht kopierte .config hat auch direkt den Auffangmechanismus für "Kernel-ging-nich" erfolgreich geprüft
Zum Ersten Mal hab ich denn auch mirt dem vorherigem Buildergebnis die Scripte laufen lassen und das gebaute hjslfs hat sich auch als Host bereits bewährt, insbesondere wg, des governors.
Nur um mal anzugeben
Debian "ondemand" RAM auf mittlerer Quälstufe : ca 75 Min.
Debian "ondemand" RAM auf hoher Quälstufe : ca 62 Min.
hjslfs "performance" RAM auf hoher Quälstufe : ca 50 Min
By the Way: gibt es einen Weg den governor zu ändern, auch wenn der Weg via /sys jeden einzelnen Core hochzutäkten versperrt wurde (wegen <not supported> )?
Nu wäre ein weiterer Schritt, Debian dankend zu verabschieden und ne Host CD/DVD zu basteln, allerdings tendiere ich mittlerweile mehr und mehr zu ner USB Lösung, statt ner Scheibe; Bootet zügiger und zickt weniger wegen Staub, Kratzer und ä. rum.Und selbst der alte 4GB in der untersten Schublade tuts
HJS
-
Kinken gefunden
Wer make menuconfig aufruft, darf sich über einen bootfähigen Kernel freuen (es sei denn, seine Config war nich wirklich dolle, da wasche ich meine Hände aber in Unschuld).
Wer ne config von irgendwoher laden (lassen) will, muss auf die 1.7.3 warten oder das im make menuconfig erledigen.
Wies aussieht, hab ich auch die Ursache fürs slang Versagen, die 2.3.x sind wohl eher gemütlich veranlagt und wünschen einen make -j1
Da der einzige Grund für slang der mc ist, hab ichs lieber zügig fixiere auf 2.2.4.
Wers neuer braucht, kann sich ja jederzeit die 2.3.2 nachbauen, die Scripte sind bereits enthalten.
HJS
-
Für mich muss der VDR in erster Linie empfangen, aufnehmen und abspielen können. Und genau das tut er mit der HD-FF perfekt. Alle anderen Soft-Lösungen hatten im Vergleich dazu nie diese Stabilität erreicht.
FullAck - umso ärgerlicher, dass es quasi keine HD FF mehr gibt
HJS
-
Es gibt durchaus noch einige hier, die einen alten Full-Featured-VDR noch am Laufen haben und sich eine Karte als "Reserve" aufheben wollen.
Ich würde auch heute noch ne FF (allerdings S2) jeder SW Decoder Lösung vorziehen, aber leider gibbet ja nur noch alte Schinken.
Nur weil moderne Prozze das Decoding locker leisten können, macht das ein System auch nicht stabiler ...
HJS
-
Grmpf - irgendwie hab ich mir nen üblen Kinken bei der Übernahme der .config eingebaut. Der Kernel des Orig-Durchlaufs ist ziemlich panisch.
glib2 hab ich mitterweile auf die 2,55,2 fixiert, das funzt, dafür zickt dialog und slang ... und wegen slang auch mc ...
Morgen ist auch noch ein Tag
HJS
-
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
-
Display More
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.
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-[VERSION].tar.bz2
-
Alle VDRler im Bereich des Sees ausgewandert ?
HJS
