Kernel update Bootschleife nach Update

[max_10]

nein
libjpeg-turbo erzeugt die libs die unten im Codeblock zu sehen sind, die libturbojpeg wird nirgends genutzt, immer nur der libjpeg teil davon.

Code: Alles auswählen

max@max:~/0_buildsystem-ddt/tufsbox/cdkroot/usr/lib$ ls -l
insgesamt 1396
drwxr-xr-x 3 max max   4096 30. Jul 11:14 cmake
lrwxrwxrwx 1 max max     13 30. Jul 11:14 libjpeg.so -> libjpeg.so.62
lrwxrwxrwx 1 max max     17 30. Jul 11:14 libjpeg.so.62 -> libjpeg.so.62.4.0
-rw-r--r-- 1 max max 619076 30. Jul 11:14 libjpeg.so.62.4.0
lrwxrwxrwx 1 max max     17 30. Jul 11:14 libturbojpeg.so -> libturbojpeg.so.0
lrwxrwxrwx 1 max max     21 30. Jul 11:14 libturbojpeg.so.0 -> libturbojpeg.so.0.3.0
-rw-r--r-- 1 max max 796668 30. Jul 11:14 libturbojpeg.so.0.3.0
drwxr-xr-x 2 max max   4096 30. Jul 11:14 pkgconfig
max@max:~/0_buildsystem-ddt/tufsbox/cdkroot/usr/lib$
 

[Don de Deckelwech]

Hi,
sorry für die späte Rückmeldung, aber die Nevis-Images ab dem 8.8. laufen wieder ohne Fehler.

Wir haben mal ein wenig überlegt: was wirklich richtig Platz im Image schaffen würde, und zwar mehr als alles andere, wäre Samba aus dem Image zu werfen. Also keine Cifs- / Windowsfreigaben mehr für/auf die Nevis. NFS ginge aber natürlich weiterhin.

Also, wer nutzt bei der HD1 noch Sambafreigaben??? Kann das weg?

Ciao,
DdD.

[Bualicher]

…
Also, wer nutzt bei der HD1 noch Sambafreigaben??? Kann das weg?

Ciao,
DdD.

Kann meinetwegen gerne weg. Ist nach jedem Update das Erste was bei mir rausfliegt.

[stefanx]

.. ich habe bisher auch immer nur NFS im Einsatz, sollte bleiben.
Das ganze Fritz Gedöns, braucht das noch wer oder braucht das keinen nennenswerten Platz?

[Don de Deckelwech]

Hi,
also die ganzen Plugins und Senderlisten sind Kleinkram.
Man muss immer bedenken, dass das Dateisystem in den Boxen komprimiert ist, also alles was Textdateien sind, zB Shellskript-Plugins und auch Senderlisten, schrumpfen so auf einen Bruchteil ihrer angezeigten Grösse. Binaries sind allerdings ein anderes Thema.

Aber: die beiden fettesten Brocken von Samba sind ungepackt so um die 6MB, gepackt immernoch so 3 oder 4MB (nur aus dem Kopf heraus). Und das bei 32MB Flash insgesamt, wovon nach frischem Flash nur noch so ca 1 bis 1,5MB frei sind!

Da würde Samba also ne Menge Luft nach oben bringen.

Ciao,
DdD.

[Gorcon]

Hi,
also die ganzen Plugins und Senderlisten sind Kleinkram.
.

Aber nicht die Transponder Listen.

[Don de Deckelwech]

Hi,
auch die lassen sich hervorragend komprimieren.

Ciao,
DdD.

[Gorcon]

Sicher, aber dann brauchst Du entsprechende Funktionen.
Könnte man diese Dateien nicht über den Senderlisten Import auch nachinstallieren? Am besten spezifisch je nach Tuner.

[Janus]

Ich habe nur die relevanten Scandaten - je nach "Anschlußpunkt" - auf meinen Boxen.

Bei Anschluß an den Multischalter nur Astra 1 und Hotbird. Bei DVB-C - Tuner nur Vodaphon und bei DVB-T2 (HD51) nur Colonius.
Bei Zugriff auch auf die Motorschüssel nur die Sat-Positionen, die meiner Meinung nach zwischen 50E bis 30W relevant und 'ergiebig' sind.

Darüberhinaus pflege ich die satellites.xml in Einzelverzeichnissen für jeden Broadcaster/Satelliten separat.
Das ist auf der Fritzbox mit einem 128GB-USB-Flash organisiert und wird beim Start jeder Box gemountet.
Darin enthalten sind nur die Transponder mit erreichbarem "Inhalt". Footprints außerhalb meines Standorts sind z.B. raus aus der Liste.

Der für den jeweiligen Anschlusspunkt erfoderliche "Satz" von Scandaten befinden sich auf der angeschlossenen Box und wird per Script und xsltproc bei Bedarf aus den o.g. Einzelverzeichnissen generiert.
=> /var/tuxbox/config/select_satellite.xml

Code: Alles auswählen

<?xml version='1.0'?>
<satellites xmlns:xi="http://www.w3.org/2001/XInclude" >
    ...
    <xi:include href="/mnt/settings/710/satellites.xml" xpointer="xpointer(//sat[@name='710 Thor'])" />
    ...
    <xi:include href="/mnt/settings/6AE/satellites.xml" xpointer="xpointer(//sat[@name='6AE ESat 9'])" />
    <xi:include href="/mnt/settings/686/satellites.xml" xpointer="xpointer(//sat[@name='686 Hotbird'])" />
    <xi:include href="/mnt/settings/668/satellites.xml" xpointer="xpointer(//sat[@name='668 ESat 16'])" />
    <xi:include href="/mnt/settings/648/satellites.xml" xpointer="xpointer(//sat[@name='648 Astra 1'])" />
    <xi:include href="/mnt/settings/61D/satellites.xml" xpointer="xpointer(//sat[@name='61D Astra 3'])" />
    <xi:include href="/mnt/settings/5EE/satellites.xml" xpointer="xpointer(//sat[@name='5EE Astra 2'])" />
    ...
    <xi:include href="/mnt/settings/582/satellites.xml" xpointer="xpointer(//sat[@name='582 Hellas'])" />
    ...
</satellites>

Von dem Zielverzeichnis auf der Box aus (üblich: /var/tuxbox/config) wird dann das Script von dem Verzeichnis auf der Fritzbox (== /mnt/settings/bld_globals_here.sh) gestartet.

Code: Alles auswählen

#!/bin/sh
#
#  Aufruf:  
#  >> cd /var/tuxbox/config/
#  >> /mnt/settings/bld_globals_here.sh 
#
echo build 'globals' in active-directory
#
# create a timestamp
date +%d.%m.%y > datum
#
echo collect broadcaster
xsltproc --xinclude -o satellites.xml /var/script/xsl/satcollect.xsl select_satellite.xml
#
# TODO ?? (mehrere Anbieter)
#echo collect cables.xml
#xsltproc --xinclude -o cables.xml /var/script/xsl/cabcollect.xsl select_cable.xml
#
echo copy cables.xml
cp /mnt/settings/F01/cables.xml .
#
echo copy terrestrial.xml
cp /mnt/settings/E11/terrestrial.xml .
#
echo collect providermaps
xsltproc --xinclude -o providermap.xml /var/script/xsl/prmapcollect.xsl select_providermap.xml
#
echo !! done !!

Die "*collect.xsl"-Dateien sind die XSLT-Anweisungen für den Import und Zusammenfassung der zu selektierenden XML-Dateien.

Ich baue auf die gleiche Art auch meine Services und Providerbouquets aus diesen Einzelverzeichnissen zusammen.
Vielleicht lässt sich das als Option/Plugin auch generell in die Images einpflegen. (xsltproc wird ja inzwischen mitgebaut)

[seife]

Sicher, aber dann brauchst Du entsprechende Funktionen.

Du hast "das Filesystem komprimiert die" nicht verstanden, oder?

[Gorcon]

Nein.

[trapped]

Wenn die Daten komprimiert auf der Box gespeichert werden, dann übernimmt das Betriebssystem die Dekomprimierung, so dass die Daten im Betrieb unkomprimiert im Arbeitsspeicher vorliegen und auch funktionieren.

Kannst Du Dir wie bei einem PC vorstellen, bei dem die Daten ggf. komprimiert auf der Festplatte liegen, um dort Platz zu sparen. Im Betrieb werden die Daten dann vom Datenträger gelesen und dekomprimiert in den Arbeitsspeicher geladen, wo sie dann verwendet werden können. Beim Speichern komprimiert das Betriebssystem dann wieder die Daten, damit sie auf dem Datenträger weniger Platz belegen.

Diese Prozesse regelt das Betriebssystem dann völlig automatisch, so dass der Benutzer nicht selbst mit irgendwelchen Plugins aktiv werden muss. Und natürlich kostet diese automatische Kompression/Dekompression etwas Rechenleistung, aber das fällt in der Regel gar nicht auf.

[jokel]

schön und gut ..
arbeitsspeicher ist z.b. 100% ausgelastet .. jetzt möchte ich aber eine anwendung starten ..
da ist es pille palle ob die datei komprimiert ist oder nicht .. wenn dieser keinen platz mehr hat
für die aufnahme der anwendung .. da der speicher zu 100% ausgelastet ist .. ergo
zusehen das der arbeitsspeicher bzw. cache immer kapazität hat für die anwendung
.. abspecken .. so das der arbeitsspeicher das auch stemmen kann

[Gorcon]

Kannst Du Dir wie bei einem PC vorstellen, bei dem die Daten ggf. komprimiert auf der Festplatte liegen, um dort Platz zu sparen. Im Betrieb werden die Daten dann vom Datenträger gelesen und dekomprimiert in den Arbeitsspeicher geladen, wo sie dann verwendet werden können

Am PC funktioniert das aber nicht so ohne weiteres. Darauf wollte ich hinaus. Dass das bei dem Image so viel anders geht ist mir jetzt vollkommen neu.

[seife]

Das ist jetzt auf einer spark box, aber das Filesystem ist ebenfalls JFFS2:

Code: Alles auswählen

root@amiko2:~# df /
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root               121856     49264     72592  40% /
root@amiko2:~# du -sx /
73233   /

Bedeutet:

• das rootfs ist 121856kb groß
• im Filesystem sind 49264 kilobytes benutzt
• im Filesystem sind 73233kb gespeichert

Die Differenz von den 49264 und den 73233 kommt durch die transparente Kompression.
Und natürlich funktioniert das beim Computer genauso. Sogar beim Windows kann man, glaub sogar pro Verzeichnis, einstellen daß die Dateien darin komprimiert werden. Ob man das will bei den heute immer günstiger werdenden Massenspeichern ist eine andere Sache.

Edit: und wenn ich 10MB Nullen auf das rootfs schreibe (lassen sich ganz gut komprimieren...), dann wirds noch offensichtlicher:

Code: Alles auswählen

root@amiko2:~# dd if=/dev/zero of=./zero bs=128k count=80
80+0 records in
80+0 records out
root@amiko2:~# ls -lh zero 
-rw-r--r--    1 root     root       10.0M Aug 18 17:18 zero
root@amiko2:~# df /
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root               121856     49576     72280  41% /
root@amiko2:~# du -sx /
83473   /