Buildumgebung: freetz-linux

[esel08]

Hallo Profi´s

Gibt es schon jemanden der Freetz unter Windows10 WSL2 ab laufen hat ??

Danke

 

[Cataclysm_177]

@gismotro

Windows-Subsystem für Linux – Wikipedia

de.wikipedia.org

WSL2 nutzt Hyper-V, aber Virtualbox magt das nicht und startet nicht mehr, das ist mein problem.

 

[gismotro]

Danke, hab es auch gerade gegooglet.

Mehr Hinweise : https://docs.microsoft.com/de-de/windows/wsl/install-win10

 

[esel08]

Ubuntu LTE 16.04 mit einen richtigen Kernel rootrechte erst mit Anmeldung.

 

[gismotro]

Hier ein kleines HowTo für alle die Ihr eigenes Freetz-Linux basteln möchten: https://www.ip-phone-forum.de/threads/freetz-ng-fehler-beim-bau-der-toolchain.308030/post-2387896

@Moderatoren: Vielleicht könnte das als Hinweis in Post 1 übernommen werden ?

 

[Novize]

Klar doch

 

[Cataclysm_177]

@gismotro
Danke für die Anleitung, klappt auch einwandfrei mit einem Ubuntu das per WLS2 läuft.

 

[gismotro]

Update :
Freetz-Linux-1.5.8-Ubuntu 20.04.01 LTS (Focal Fossa) 64-Bit

Download: >> hier <<

- Ubuntu update von 20.04 LTS auf 20.04.01

Die Aktualisierung behebt in erster Linie Fehler, die nach der Veröffentlichung von Ubuntu 20.04 bekannt wurden. Nach Angaben der Entwickler handelt sich dabei neben gestopften Sicherheitslücken auch um einige ausgemerzte schwerwiegendere Fehler. Die neue Version 20.04.1 soll insgesamt stabiler laufen.
Quelle : www.linux-magazin.de

- Spracheinstellung auf Deutsch hinzugefügt

 

[Master SaMMy]

Hi Leute ich habe mir mal für meine Qnap TS-451+ mit 8GB RAM ein Virtuelles Linux auf Basis von Ubuntu 20.10 (Groovy Gorilla) Beta nach dieser Anleitung von gismotro ( https://www.ip-phone-forum.de/threads/freetz-ng-fehler-beim-bauen-f%C3%BCr-unterschiedliche-konfigurationen.308030/#post-2387896 ) gebaut.

Ich habe nur VSFTP, Samba und das auf Deutsch umstellen raus gelassen da ich das so oder so nie nutze. Daher wenn es wer brauch kann es ja jeder selber noch nachträglich hinzufügen.

Wenn es einer haben will das ganze könnt ihr hier

http://www.onlinewahn.de/ende.htm

[Edit Novize: Halbseidenen Link etwas "korrigiert"]

Da meine NAS immer an ist kann ich mein Rechner ausmachen wenn ich mir zB nenn neues Image für meine FitzBoxen bauen will oder auch Oscam (gibt ja einiges was länger dauert beim bauen). Ich habe es kurz angetestet mit Oracle VM VirtualBox ob es auch da läuft und es geht.

Ich habe auch mal mein Aufbau meiner freetz-ng dirs dabei gepackt und auch s3_releases wo ich die fehlenden Packtet auch schon installiert habe.

Wie gismotro schon sagte macht er 1 mal Wöchentlich sudo apt update && sudo apt upgrade. Ich mache dieses noch dazu sudo apt dist-upgrade && sudo apt autoclean && sudo apt autoremove

 

[gismotro]

Update : Freetz-Linux-1.5.9-Ubuntu 20.10(Groovy-Gorilla) 64-Bit

 

[PeterPawn]

@gismotro:
Mal 'ne Frage am Rande ... was genau ist denn der Vorteil von 20.10 ggü. einen Image auf der Basis von 20.04?

Letzteres ist eine LTS-Version, die über 5 Jahre (also bis 2025) mit notwendigen Updates versorgt wird - die 20.10 ist ein "short term release" und in 9 Monaten ohnehin wieder Geschichte.

Ubuntu release cycle | Ubuntu

Overview of the Ubuntu release cycle - maintenance, support and security coverage, lifetime, upgrade paths, kernel versions and the range of editions and images published by Canonical.

ubuntu.com

Ubuntu 20.10 New Features Review and How to Upgrade

Ubuntu 20.10 is a short-term release that will receive official support with important updates up to July 2021. Here's what's new and how to do an upgrade.

www.fosslinux.com

Die Änderungen der 20.10 (in erster Linie ja der Desktop und ein neuerer Kernel) spielen für einen Build-Host für Freetz jetzt sicherlich auch nicht die entscheidende Rolle - warum sollte man als Freetz-User jetzt auf die 20.10 setzen und nicht auf die 20.04? Freetz braucht ja nun auch keine Komponenten, die in der 20.04 noch nicht existieren oder irgendwelche entscheidenden Änderungen erfahren hätten.

Nach meiner Meinung (die ist natürlich auch nicht maßgeblich) tust Du anderen Freetz-Nutzern mit einem Image, das auf 20.04 basiert (und dann natürlich auch die Repos dafür in den Einstellungen hat), einen wesentlich größeren Gefallen ... zumindest kommt man damit bis zur nächsten LTS-Version, die (planmäßig) im April 2022 erscheinen müßte - bis dahin geht der Support für die 20.10 aber gar nicht.

 

[gismotro]

Da gebe ich Dir recht.
Ich hatte nur gesehen das die 20.10 beta durch ein Release ersetzt wurde und da hab ich einfach mal ein Update gebaut.

Grund war eigentlich, das ich einen Fehler in der Beta hatte, den ich nicht gefunden habe, aber vielleicht weiß ja einer von Euch wo das Problem liegen könnte:

Ich habe der VM eine 100GB virtuelle Festplatte gegeben. Diese soll sich je nach Bedarf selbständig vergrößern, aber bei mir war immer bei 48,5 GB feierabend. Dann bekomme ich immer Schreibfehler beim Bauen mit der Meldung das abgebroche wurde weil Freetz Dateinen nicht schreiben konnte. Lösche ich einen anderen Freetz-Ordner in der VM, dann geht es wieder....

~/freetz/73/...
~/freetz/74/...
~/freetz/75/...

Hab mir mit df mal die Verteilung angesehen und da ist laut Anzeige die Platte nur zu 40% belegt. Ebenso wird sie nicht größer als 50 GB (Original hat die Platte 200GB) auf der die VM läuft.

Hat das sonst son wer so beobachtet ?

 

[PeterPawn]

Ich frag mal explizit nach ... die Partition, auf der die Container-Datei für Deine virtuelle HDD liegt, hat auch wirklich noch genug Platz, um eine Erweiterung der Datei zu verkraften? Welches Dateisystem verwendet die Partition denn? Ist das auch tatsächlich fehlerfrei?

Alles das sind mögliche Fallstricke ... ich werde auch aus

Original hat die Platte 200GB

nicht so richtig schlau. Soll das heißen, die Containerdatei liegt auf einer eigenen HDD, die eine physikalische Größe von 200 GB hat? Wenn ja, muß das ja auch noch nicht heißen, daß die darauf befindliche (einzelne?) Partition ebenfalls die vollen 200 GB umfaßt.

Da mußt Du wohl konkreter werden, wenn man das verstehen soll - am besten mit einer passenden Beschreibung, wo und wie die HDD eingebunden ist in die VM und ein paar Screenshots (wenn man die GUI-Tools von VirtualBox nutzt) oder ein paar Protokollen der CLI-Tools (https://www.virtualbox.org/manual/ch05.html).

Am wahrscheinlichsten ist ein "eingeschlepptes Problem" durch kaputte Verwaltungsinformationen für die Image-Datei (die dann die dynamische Erweiterung verhindern) oder fehlender (physischer) Platz - dafür gibt es ja die passenden Tools, mit denen man die Integrität dieser Dateien testen kann. Zuvor sollte man halt dann auch die Integrität der Partitionen testen, auf denen die (VM-)Image-Files abgelegt werden und erst danach kann man dann auch sicher sein, daß die Angaben zum freien Speicherplatz stimmen. Wer z.B. eine FAT(32)-Partition für Images verwendet, kann ganz schnell in die Falle laufen, daß "Gesamtkapazität - genutzte Kapazität = freie Kapazität" nur eine Milchmädchen-Rechnung ist, wenn eine Partition mit diesem Format viele "lost clusters" enthält - da kommt es dann auch immer darauf an, wo man genau nachsieht, was da noch frei wäre.

 

[gismotro]

Hier die geforderten Informationen:

Ausgabe df :

Festplatte im PC:

Festplatte in der VM:

 

[PeterPawn]

Nun mußt Du die halt auch mal so weit wachsen lassen, daß der Fehler auftreten kann - entscheidend sind ja die Angaben zu diesem Zeitpunkt.

Das muß nicht unbedingt ein Freetz-Build sein - man kann ja auch mit geeigneten Kommandos einfach Dateien (z.B. mit 1 GB-Größe, was dann ca. 35 dieser Dateien bräuchte, damit es ungefähr an die von Dir erwähnte Grenze von 48,5 GB kommt) in der Linux-Partition erzeugen lassen, wobei man dann aufpassen muß, daß die (Host-)Partition nichts komprimiert (ist ja derzeit abgeschaltet lt. Screenshot), damit identische Daten (z.B. nach dem Kopieren aus /dev/zero) nicht nur zu einer "Scheinauslastung" führen.

Und auf NTFS-Partitionen kommt dann noch hinzu, daß dort i.d.R. "Schattenkopien" liegen (oder zumindest liegen können) - und da dort die Verwaltung freier Blöcke auch anders erfolgt, ist hier erst recht eine vorherige Prüfung des Zustands des Dateisystems "Pflicht". Das geht entweder unter dem "Tools"-Tab in den Laufwerkseigenschaften (dann findet man das Ergebnis (das ausführliche, in Textform) im Event-Log) oder über die Kommandozeile mit "chkdsk".

Außerdem kann man das natürlich auch einfach gegenprüfen ... man kopiert die Image-Datei einfach auf ein anderes Laufwerk, auf dem ausreichend Platz zur Verfügung steht, um die Image-Datei um mind. 40 GB zu erweitern, wenn sie (im virtuellen System) wachsen muß.

Funktioniert die Erweiterung dort dann doch, liegt es an der Container-Partition, ansonsten halt am Image der virtuellen Partition.

Keiner der drei Screenshots zeigt ja, wie es um die (internen) Verwaltungsstrukturen der Image-Datei bestellt ist - wer einen Eindruck davon bekommen will, wieviele verschiedene Formate es dort gibt (alleine innerhalb des "VMDK"-(Pseudo-)Standards, der m.W. irgendwann mal von VMware postuliert und dann von anderen Virtualisierungslösungen nachgebaut wurde), der kann ja mal einen Blick hier hinein werfen:

libvmdk/documentation/VMWare Virtual Disk Format (VMDK).asciidoc at main · libyal/libvmdk

Library and tools to access the VMware Virtual Disk (VMDK) format - libyal/libvmdk

github.com

- da müßten sich auch Tools finden lassen (habe ich nicht geprüft), mit denen man diese internen Strukturen und die verwendeten Formate visualisieren kann.

Auch eine einzelne Image-Datei muß (afaik) nicht unbedingt eines der "monolithic*"-Formate benutzen und manchmal steht eben auch das interne Format der (mehrfachen) Erweiterung entgegen, denn jede dieser Erweiterungen der (physikalischen) Container-Datei hat (bei einigen Formaten zumindest) ihren eigenen Extent-Header - daher wächst so eine Image-Datei üblicherweise auch immer gleich um einen ganzen "Extent" und nicht nur um die gerade benötigte Anzahl von Blöcken.

Und die Host-Software für die VMs protokolliert bestimmt auch noch ihren Teil, wenn es den Wunsch nach einer Vergrößerung der Datei durch das OS in der VM gibt (bzw. durch die dort aktive "Vermittlungsschicht" beim Disk-Zugriff) und diesem nicht entsprochen werden kann - da kann man dann (wenn der Fehler aufgetreten ist und man den Zeitpunkt kennt, i.d.R. sogar anhand passender Zeitstempel in den Protokoll-Zeilen) auch mal einen Blick hinein werfen, dann muß man nicht nur raten bzw. nach Wahrscheinlichkeiten sortieren.

 

[fda89]

Ich halte von diesem LTS und Debian Konzept gar nichts. 2 Jahre läuft alles supi. Danach hat man uralte Software, die nicht mehr upgradebar ist da sich bei vielen Paketen grundlegende Dinge an der Konfiguration geändert haben. Der Aufwand einer kompletten Neuinstallation ist dann geringer als so ein Debian/LTS zu updaten.
Dann lieber gleich eine rolling-release oder halbjährliches

 

[PeterPawn]

Wie kommst Du auf das schmale Brett mit LTS (bei Ubuntu) und 2 Jahren?

Die LTS hat 5 Jahre Support - und das heißt dann auch, daß die in diesen fünf Jahren Updates der wichtigsten Komponenten kriegt, solange das nicht zu einem "totalen Umbau" des Systems wird.

Und wenn die 20.04 derzeit einen älteren Kernel als 20.10 verwendet, wird das auch nicht bis 2025 so bleiben - irgendwann gibt's auch da ein Update (der Gnome-Desktop ist ohnehin Bummi, wenn's um einen Freetz-Host geht), denn genau dafür sind die STRs ja der "Testfall".

Ich bin bestimmt auch kein Fan von Ubuntu (oder dem Unterbau "Debian" an sich) - aber nur dann nicht, wenn es um ein auch anderweitig genutztes System geht. Theoretisch könnte man auch heute noch Freetz-Images mit einem Ubuntu 18.04 bauen lassen - selbst ein Host mit alten Paketen hat ja nur einen sehr geringen Einfluß darauf, was am Ende im Image landet.

Gerade dann, wenn man sich damit nicht so richtig gut auskennt, kann ein "rolling release" schon mit einem neuen Compiler, der irgendwelche anderen Standardeinstellungen verwendet, dazu führen, daß der komplette Freetz-Build scheitert. Das ist also (zumindest nach meiner Überzeugung) so gar keine gute Idee für einen Freetz-Nutzer, für seinen Build-Host auf eine solche Distribution zu setzen.

 

[fda89]

Dann waren die 2 Jahre wohl Debian. Auf jeden Fall ein Ärgernis wenn man alles komplett neuinstallieren muss statt updaten zu können
Freetz wurde noch oft mit einem Ubuntu von 2014 gebaut was diverse Fehler verursacht, angefangen von einem uralten svn/git https://github.com/Freetz-NG/freetz-ng/blob/master/Makefile#L88

 

[PeterPawn]

Da müßtest Du dann schon etwas konkreter werden, wo das Problem liegen soll. Denn wenn da alles richtig "verdrahtet" ist und der GCC für den Cross-Build sich übersetzen läßt, sollte der Kernel des Build-Hosts überhaupt nicht interessieren - solange nicht irgendwelche (falsch konfigurierten) Pakete anstelle der Dateien für den Cross-Build die des lokalen Hosts verwenden (bei "ncurses" z.B. habe ich etwas in der Richtung tief in der Erinnerung vergraben).

Wenn sich der Cross-Compiler mit einer älteren Systemversion nicht bauen läßt, ist das zwar auch das Aus für Freetz - aber solche Abhängigkeiten zwischen Linux-Kernel und GCC-Version sind (beiderseitig) eher selten - der Linux-Kernel hat erst in diesem Jahr auf "minimal GCC 4.9" umgestellt und diese Version des GCC ist immerhin auch schon aus 2014 und damit eher "gut abgehangen".

Da der Cross-Compiler selbst eigentlich ja auch nur auf Dateizugriffen (für die Übersetzung beim Cross-Build) basiert und ansonsten mit dem Kernel des laufenden Systems eher wenig zu tun hat, sollte der sich (außer in wirklich sehr speziellen Konstellationen) gar nicht dafür interessieren, welcher Kernel läuft, solange seine C-Library (egal, ob die statisch oder dynamisch gelinkt ist) sich mit dem vorhandenen Kernel und den von ihm angebotenen Syscalls verträgt.

Daß es ggf. Probleme gibt, wenn man 32- und 64-Bit-Code mixen will, steht auf einem vollkommen anderen Blatt - das kann man zwar auch anhand der "Kernel-Version" feststellen, aber die ist damit noch lange nicht "schuld" daran.

Wenn Du also in Freetz-NG jetzt einen zusätzlichen Test eingebaut hast, der alles mit einem Kernel kleiner 4.x ausschließt für den Build-Host, dann magst Du dafür ja Deine Gründe gehabt haben - aber welche das genau gewesen sein könnten, kann auch der geneigte Leser nur "raten", weil der Commit dafür (wieder mal) nicht den geringsten Anhaltspunkt liefert: https://github.com/Freetz-NG/freetz...debb9e9aad2d818052b07091de1f20cad0bbac34ffb52 - die einzige Feststellung dort ist, daß ältere Systeme ausgeschlossen werden und zu den Gründen dafür, findet sich nicht ein Wort und/oder ein Verweis auf ein Problem oder einen anderen Commit.

EDIT: Abgesehen davon war schon die 14.04.x die erste Ubuntu-Reihe, die mit neuen Kernel-Versionen versorgt wurde, um auch neue Hardware über die anvisierten fünf Jahre zu unterstützen: https://wiki.ubuntuusers.de/LTS_Enablement_Stacks/ - eine 14.04.6 (als finaler Stand der 14.04-LTS-Reihe) konnte also auch den Kernel 4.4 nutzen und zwar schon seit 14.04.5, die im August 2016 aktualisiert wurde.

 

[fda89]

Anscheinend wurde das Linux aber nicht von den Benutzern aktualisert, daher wars (und ist) auch egal ob LTS oder nicht.
Das konkrete Problem war, dass svn oder git auf dem Ubuntu von 2014 so alt war, dass es nötige Parameter noch gar nicht gab. Hätte man was workarounden können, aber keine Lust. Vermutlich war es git, da es Freetz damals nur als svn gab. Weitere Fehler hab ich auch erst gar nicht gesucht.
EDIT: Zu der Zeit kam die Revisionsanzeige ins Menuconfig, könnte daher auch bei Freetz/ ein Problem sind

Wo du mit x64/32 anfängst ... erinnerst du dich an das/dein dtc-host dass man zwingen als x86 bauen muss? Das fiel auch niemand auf, da scheinbar alle x86 nutzen.
Das ganze macht aber nun auf einem aarch64 System Probleme (was hast du auf deinem Raspberry für ein Linux?). Mit ARM kann man nicht einfach als 32-bit compilieren wie bei den Intels