[Info] Freetz im LXC Container gebaut

[targa]

Hallo,
keine Ahnung ob das wen interessiert.
ich hab statt in einer VM Freetz in einem LXC gebaut (unter Slackware64 13.37), könnte für alle die interessant sein, die sowieso einen Linux Rechner haben, aber nicht im Setup rumfuchteln wollen.

Wie man einen Linux Container aufsetzt, das ist woanders beschrieben (Onkel Google fragen), beachten muss man, dass die geforderten Pakete für die einzelnen Distributionen unter umständen anders heissen (hier hilft auch Onkel Google), und dass man bei einem 64-Bit System (wie in meinem Fall), die 32Bit-Kompatibiltäts pakete (z.B. compat32) im LXC installiert.

Ging dann weiter ohne Probleme und ist vermutlich die ressourcenschonendste Methode.

Hintergrund: Ein LXC (=Linux Container) ist eine Linux Umbegung innerhalb einer Linux Umgebung, aber es ist nicht wie in einer VM ALLES vorhanden, sondern es werden einige Ressourcen vom Host mitverwendet (z.B. Kernel und Treiber Module). Spart also Platz (RAM und HDD) und CPU Leistung.

 

[RalfFriedl]

Warum hast Du überhaupt einen Container verwendet, wenn Du schon ein Linux System hast? Freetz läuft als normaler Benutzer, die VM ist nicht zur Abgrenzung, sondern für die, die kein Linux System haben.
Die benötigten Pakete nicht zu installieren wäre als Grund nachvollziehbar, aber so muss man den Container einrichten UND die Pakete installieren, das klingt nicht nach weniger Arbeit.

 

[targa]

Ja, die Frage hab ich mir nachher auch gestellt.
Die ganzen Anleitungen sind so VM focussiert, dass ich automatich davon ausgegangen bin, dass ein isoliertes System wohl nötig ist.

Im Endeffekt hat es "nur noch" den Vorteil, dass ich Library-Versionen installieren konnte, die von "meinen" abweichen, was allerdings in meinem Falle nicht nötig war. Und dass sonst fast alles "mitgeliefert" wird geht aus der Doku auch nicht soooo eindeutig hervor, weil automatisch davon ausgangen wird, dass der Gemeinanwender ein Windows System hat und mit diesen Informationen eh nix anfangen kann..

Und jetzt noch die Freud'sche Begründung: Ich wollte unbedingt mal einen LXC bauen Der nächste wird dann ein Desktop-Android sein

 

[RalfFriedl]

Die Meisten verwenden nun mal ein Windows System, und deswegen ist die Beschreibung auch darauf ausgerichtet. Natürlich funktioniert die gleiche VM auch unter Linux, ist dort aber nicht notwendig. Im Wiki steht "Für die Freetz-Installation wird Linux als Betriebssystem empfohlen. Wer kein Linux dauerhaft auf seinem Rechner installieren will, ...". Meinst Du, man sollte deutlicher schreiben, dass für Linux keine VM nötig ist?
Ich selbst habe Freetz immer nur direkt auf einem Linux System erstellt, ohne VM oder LXC.
Die Host Libraries sind nur von Bedeutung für die Download Toolchain, und da sollten die meisten halbwegs aktuellen C Libraries funktionieren. Wenn man die Toolchain selbst erstellt, kommt man sogar ohne 32 Bit Unterstützung aus.

Erfahrung mit LXC zu sammeln ist natürlich ein guter Grund.

 

[targa]

War nicht als Kritik gedacht, nur als Erklärung, weil Du fragtest.

Andererseits.... wenn man sein Linux in Ruhe lassen will... immerhin sind glibc und gcc im Spiel, ist eine VM oder ein Container keine schlechte Sache.

Und... das Zielsystem ist ein 32-Bit Linux System... auf einem reinen 64 Bit System (wie Slack64) müssen die 32Bit compatibility libraries nachinstalliert werden. Das ist meist auch machbar, aber sollte Erwähnung finden. Muss man natürlich in einem Container auch machen, nicht in einer passenden VM.

 

[targa]

Habe jetzt mal versucht "mein" Image zu bauen... hab also noch ein paar mehr Pakete ausgewählt.

Zuersteinmal musste ich noch m4 nach installieren, sonst hatte flex/bison ein problem (Bus-error oder so etwas übles in der Art).

Jetzt stosse ich auf folgenden Fehler.... .... "none"....?

Stimmt da noch etwas in richtung 64 Bit /usr/lib vs. /usr/lib64, bzw. /usr/bin vs. /usr/bin/32 nicht ?

Jemand eine Ahnung?

make[4]: Leaving directory `/usr/src/freetz-trunk-10947/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/glib-2.32.4/gobject'
make[3]: Leaving directory `/usr/src/freetz-trunk-10947/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/glib-2.32.4/gobject'
Making all in gio
make[3]: Entering directory `/usr/src/freetz-trunk-10947/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/glib-2.32.4/gio'
  GEN    gconstructor_as_data.h
[b]  GEN    gdbus-daemon-generated.c
/bin/sh: none: command not found[/b]
make[3]: *** [gdbus-daemon-generated.c] Error 127
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory `/usr/src/freetz-trunk-10947/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/glib-2.32.4/gio'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/freetz-trunk-10947/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/glib-2.32.4'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/freetz-trunk-10947/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/glib-2.32.4'

[b]ERROR: Build failed.[/b]
make: *** [source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/glib-2.32.4/glib/.libs/libglib-2.0.so.0.3200.4] Error 1

 

[targa]

root@freetz:/usr/src/freetz-trunk-10947/source/target-mipsel_gcc-4.6.4_uClibc-0.9.28/glib-2.32.4/gio# grep PYTHON Makefile
[b]PYTHON = none[/b]
PYTHON_EXEC_PREFIX = 
PYTHON_PLATFORM = 
PYTHON_PREFIX = 
PYTHON_VERSION = 
		[b]$(PYTHON)[/b] $(srcdir)/gdbus-2.0/codegen/gdbus-codegen.in \

???

 

[RalfFriedl]

Ich verwende kein glib auf der Box, aber anscheinend wird hier für die Übersetzung phthon gebraucht.

 

[targa]

kann ich irgendwo übersichtlich die Dependencies sehen ? Also welches Package in python ist ? uU kann ich darauf verzichten ...

 

[RalfFriedl]

Die Frage ist nicht, welches Package in Python ist, sondern welches Package Python zum Übersetzen benötigt. Hier geht es um das Übersetzen von glib, und glib wurde vermutlich von einem anderen Paket ausgewählt, das Du aktiviert hast. Wenn Du im menuconfig die Hilfe bei glib auswählst, bekommst Du angezeigt, von welchen Paketen es ausgewählt wird.

 

[targa]

Die Frage ist nicht, welches Package in Python ist, sondern welches Package Python zum Übersetzen

Das meinte ich, keine Ahnung, warum ich es so geschrieben habe.

Wenn Du im menuconfig die Hilfe bei glib auswählst, bekommst Du angezeigt, von welchen Paketen es ausgewählt wird.

Nun, die Hilfe ist nicht immer soooo ausführlich.
Ich vermute mal stark, dass es um den Kernel geht

 

[RalfFriedl]

Nun, die Hilfe zeigt die Abhängigkeiten immer.
Und ich vermute nicht, dass es bei glib um den Kernel geht.

 

[targa]

grep -i python .config
# FREETZ_PACKAGE_PYTHON is not set

Komisch... ich hab dann mal ein cp -a auf den host gemacht und da läuft gio/gdb durch. FFMpeg will nicht, hab's dann mal ohne minidlna versucht.... läuft gerade.

FFMPeg abgewählt -> wieder beim 'none'-Problem, s.o.

wenn ich make clean mache meint make immer ich hätte eine andere SVN und ich soll make menuconfig fahren.... fürchte, das macht irgendwie mucken.

 

[RalfFriedl]

Es geht nicht darum, dass das Paket Python für die Box ausgewählt ist oder benötigt wird, sonder dass der Build-Prozess von glib ein Python auf dem Host haben will.

Vermutlich hast Du eine Unstimmigkeit in der Version, versuche mal "make oldconfig".

 

[targa]

Es geht nicht darum, dass das Paket Python für die Box ausgewählt ist oder benötigt wird, sonder dass der Build-Prozess von glib ein Python auf dem Host haben will.

Na Python ist natürlich da. Wissen nur die Build Scripte nicht.

 

[RalfFriedl]

Dann finde heraus, warum es nicht gefunden wird.

 

[milkpirate]

ok hatte das gleiche problem. habe die zeile zu dem richtigen python path geändert:

~/freetz/trunk/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/glib-2.32.4/gio/Makefile

--- Makefile         2016-01-23 15:13:51.460338392 +0100
+++ Makefile.bak     2016-01-23 15:13:43.252338488 +0100
@@ -681,7 +681,7 @@
 POSUB =
 PO_IN_DATADIR_FALSE =
 PO_IN_DATADIR_TRUE =
-PYTHON = none
+PYTHON = /usr/bin/python
 PYTHON_EXEC_PREFIX =
 PYTHON_PLATFORM =
 PYTHON_PREFIX =

bei mir liefs danach... vorerst... ist noch am bauen.