Buildumgebung: freetz-linux

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
325
Punkte für Reaktionen
6
Punkte
18
Oder man konfiguriert das Interface richtig für dhcp in der /etc/networks ...
 

esel08

Neuer User
Mitglied seit
9 Jul 2008
Beiträge
57
Punkte für Reaktionen
1
Punkte
8
Hallo Profi´s

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

Danke
 

esel08

Neuer User
Mitglied seit
9 Jul 2008
Beiträge
57
Punkte für Reaktionen
1
Punkte
8
Ubuntu LTE 16.04 mit einen richtigen Kernel rootrechte erst mit Anmeldung.
 

Novize

Moderator
Teammitglied
Mitglied seit
17 Aug 2004
Beiträge
21,252
Punkte für Reaktionen
164
Punkte
63
Klar doch ;)
 

gismotro

Mitglied
Mitglied seit
5 Sep 2007
Beiträge
412
Punkte für Reaktionen
59
Punkte
28
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
 
Zuletzt bearbeitet:

Master SaMMy

Neuer User
Mitglied seit
20 Apr 2016
Beiträge
101
Punkte für Reaktionen
16
Punkte
18
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
[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
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: gismotro

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,286
Punkte für Reaktionen
1,095
Punkte
113
@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.



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.
 
  • Like
Reaktionen: gismotro

gismotro

Mitglied
Mitglied seit
5 Sep 2007
Beiträge
412
Punkte für Reaktionen
59
Punkte
28
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....
Code:
~/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 ?
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,286
Punkte für Reaktionen
1,095
Punkte
113
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.
 
  • Like
Reaktionen: gismotro

gismotro

Mitglied
Mitglied seit
5 Sep 2007
Beiträge
412
Punkte für Reaktionen
59
Punkte
28
Hier die geforderten Informationen:

Ausgabe df :
Bild 1.PNG
Festplatte im PC:
Bild 2.PNG
Festplatte in der VM:
Bild 3.PNG
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,286
Punkte für Reaktionen
1,095
Punkte
113
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:


- 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.
 
  • Like
Reaktionen: gismotro

fda89

Mitglied
Mitglied seit
31 Aug 2020
Beiträge
240
Punkte für Reaktionen
44
Punkte
28
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

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,286
Punkte für Reaktionen
1,095
Punkte
113
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.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,286
Punkte für Reaktionen
1,095
Punkte
113
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.
 
3CX

Neueste Beiträge

Statistik des Forums

Themen
236,248
Beiträge
2,073,172
Mitglieder
357,507
Neuestes Mitglied
dsaltos