[Erledigt] pyload: Config -> OperationalError: database or disk is full + WebIF startet nicht

horst123456

Neuer User
Mitglied seit
4 Mrz 2007
Beiträge
55
Punkte für Reaktionen
0
Punkte
0
Ich habe auf meine FB 7320 die neueste Trunk-Version von Freetz aufgespielt (hatte vorher einen älteren Trunk drauf laufen), was ohne Probleme funktionierte. Von der Vorinstallation wurden alle möglichen Einstellungen übernommen, nur nicht die von pyload. Möchte ich pyload konfigurieren, dann sieht es wie folgt aus:

Code:
root@fritz:/var/mod/root# rc.pyload setup
Choose your Language / Wähle deine Sprache ([en]):

Welcome to the pyLoad Configuration Assistent.
It will check your system and make a basic setup in order to run pyLoad.

The value in brackets [] always is the default value,
in case you don't want to change it or you are unsure what to choose, just hit e
nter.
Don't forget: You can always rerun this assistent with --setup or -s parameter,
when you start pyLoadCore.
If you have any problems with this assistent hit STRG-C,
to abort and don't let him start with pyLoadCore automatically anymore.

When you are ready for system check, hit enter.

## System Check ##
Python Version: OK
pycurl: OK
sqlite3: OK

pycrypto: OK
py-OpenSSL: OK

py-imaging: OK
tesseract: missing

jinja2: OK
beaker: OK
JS engine: OK

System check finished, hit enter to see your status report.

## Status ##

Features available: container decrypting, ssl connection, Webinterface, extended
 Click'N'Load

Features missing:

no Captcha Recognition available
Only needed for some hosters and as freeuser.

You can abort the setup now and fix some dependicies if you want.
Continue with setup? ([y]/n):


Do you want to configure login data and basic settings?
This is recommend for first run.
Make basic setup? ([y]/n):

## Basic Setup ##

The following logindata is valid for CLI, GUI and webinterface.
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
  File "/opt/pyLoad/module/database/DatabaseBackend.py", line 140, in run
    self._createTables()
  File "/opt/pyLoad/module/database/DatabaseBackend.py", line 218, in _createTab
les
    self.c.execute('CREATE TABLE IF NOT EXISTS "storage" ("id" INTEGER PRIMARY K
EY AUTOINCREMENT, "identifier" TEXT NOT NULL, "key" TEXT NOT NULL, "value" TEXT
DEFAULT "")')
OperationalError: database or disk is full

Die Konfiguration kann ich dementsprechend nicht durchführen. Selbige Meldung wird ausgegeben, wenn ich versuche die Nutzer zu verwalten per rc.pyload user.

Nun weiß ich nicht genau, wo er eine Datenbank anlegen möchte - einige Sachen auf der Box sind tatsächlich voll.
Code:
root@fritz:/var/mod/root# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                14.0M     14.0M         0 100% /
tmpfs                    25.4M      1.1M     24.3M   4% /var
dev                      25.4M     60.0K     25.3M   0% /dev
/dev/loop0              274.0K    271.0K         0 100% /var/media/ftp
/dev/sda1                29.8G     18.6G     11.3G  62% /var/media/ftp/UStor01

Alternativ zu dem möglichen Platzproblem hab ich eigentlich nur gefunden, dass es sich um einen Fehler bei Python- oder SQLite handeln könnte - aber ohne eine Lösung.

Spiele ich die Freetz-Stable-2.0 mit identischer Paketauswahl auf, läuft alles ohne Probleme. Dabei stört mich lediglich, dass eine "alte" Firmware (100.05.51 mit älterem Fritz!OS) zum Einsatz kommt. Daher würde ich schon gerne die Trunk-Version nehmen.

Hat jemand eine Idee, wie ich das Problem lösen kann?
 
Zuletzt bearbeitet:
Das Problem dürfte - alles nur Theorie und etwas Nachschauen im Code ohne eigenen Test - in der Änderung der Mountpoint-Namen liegen.

In der Paket-Konfiguration (make/pyload/files/root/etc/default.pyload/pyload.cfg) wird folgendes definiert:
Code:
export PYLOAD_CONFIGDIR='/var/media/ftp/uStor01/pyload'
Im Zuge einiger Probleme mit neuerer Firmware gab es eine Änderung bei der Benennung der Mountpoints (Freetz-Ticket 2499) und daraus entstand der auch bei Dir offenbar vorhandene
/dev/sda1 29.8G 18.6G 11.3G 62% /var/media/ftp/UStor01
abweichende Name. Da unter /var/media/ftp nur ein kleines Image eingebunden ist, wird jede größere Schreiboperation abseits von /var/media/ftp/UStor01 schnell an ihre Grenzen stoßen, das dürfte auch bei Dir jetzt der Fall sein.

Als schnelle Hilfe könntest Du vor dem 'make' in der o.a. Datei den Pfad von Hand ändern.

Als dauerhafte Lösung wäre eine "etwas weniger feste" Festlegung des Pfades zur Konfigurationsdatei wünschenswert. Meines Wissens ist es im Freetz noch niemals zwingend gewesen, daß ein Datenträger unter /var/media/ftp/uStor01 eingebunden wurde, da hat die Änderung nur ein potentielles Problem zutage gefördert, das auch in anderer Konstellation auftreten würde.

Wenn das dann bei Dir zum Erfolg führen sollte, wäre das Eröffnen eines Tickets im Trac-System von Freetz ein erster Schritt, das Problem aufzuzeigen und jemanden für dessen Beseitigung zu interessieren.
 
Vielen Dank PeterPawn, diese Änderung hat das Problem soweit behoben.

Jetzt habe ich also pyload konfiguriert, stehe aber vor einem Problem mit dem Webinterface.

Starte ich pyload über das Freetz-Webinterface, dann ist das pyload-Webinterface nicht erreichbar (auf dem Port läuft dann auch nichts). Gleiches passiert, wenn ich
Code:
rc.pyload start
oder auch
Code:
python /opt/pyload/pyloadcore.py --daemon
unter telnet eintippe.

Im Log steht in den Fällen nur:
Code:
Starting pyLoad 0.4.9
Using home directory: /var/media/ftp/UStor01/pyload

Das Webinterface von pyload ist bei der folgenden Variante dann aber erreichbar:
Code:
python /opt/pyload/pyloadcore.py

Log sagt:
Code:
Starting pyLoad 0.4.9
Using home directory: /var/media/ftp/UStor01/pyload
Error importing BypassCaptcha: invalid syntax (BypassCaptcha.py, line 91)
ExtractArchive: No UnRar installed
ExtractArchive: Activated UnZip
Activated plugins: Captcha9kw, Checksum, ClickAndLoad, ExternalScripts, ExtractArchive, ImageTyperz, LinkdecrypterCom, UnSkipOnFail, UpdateManager, XFileSharingPro
Deactivate plugins: AlldebridCom, CaptchaBrotherhood, DeathByCaptcha, DebridItaliaCom, DeleteFinished, DownloadScheduler, EasybytezCom, ExpertDecoders, FastixRu, FreeWayMe, HotFolder, IRCInterface, LinksnappyCom, MegaDebridEu, MergeFiles, MultiHome, MultishareCz, MyfastfileCom, OverLoadMe, PremiumTo, PremiumizeMe, RPNetBiz, RealdebridCom, RehostTo, RestartFailed, SimplyPremiumCom, SimplydebridCom, UnrestrictLi, WindowsPhoneToastNotify, XMPPInterface, ZeveraCom
Downloadtime: True
Starting builtin webserver: 0.0.0.0:5555
Free space: 11.25 GiB
Activating Accounts...
Activating Plugins...
pyLoad is up and running
UpdateManager: No new pyLoad version available
UpdateManager: No plugin updates available

Ich dachte nun daran, das Problem zu lösen indem ich pyload aus dem Autostart nehme und
Code:
python /opt/pyload/pyloadcore.py
in die rc.custom eintrage.

Bei Freetz steht dazu aber extra
Es dürfen keine Befehle eingetragen sein, die im Vordergrund bleiben oder sehr lange brauchen. Dies könnte Probleme beim Starten der FritzBox verursachen.
womit diese Variante vermutlich flach fällt.

Vermutung meinerseits war, dass die Fehlermeldung bzgl. der BypassCaptcha.py was damit zu tun hat. Meine Recherche brachte, dass man die Datei einfach löschen kann und pyload das Plugin selbst neu herunterlädt. Ich kann die Datei jedoch nicht löschen, da sie als readonly im Pfad
Code:
/opt/pyLoad/module/plugins/hooks
liegt.

Jetzt bin ich vorerst wieder ratlos. :p

edit:
An dem Fehler mit dem Plugin sollte es wohl nicht liegen. Ich habe es im pyload-Webinterface deaktiviert, sodass das Log bei
Code:
python /opt/pyload/pyloadcore.py
so aussieht:
Code:
Starting pyLoad 0.4.9
Using home directory: /var/media/ftp/UStor01/pyload
ExtractArchive: No UnRar installed
ExtractArchive: Activated UnZip
Activated plugins: Captcha9kw, Checksum, ClickAndLoad, ExternalScripts, ExtractArchive, ImageTyperz, LinkdecrypterCom, UnSkipOnFail, UpdateManager, XFileSharingPro
Deactivate plugins: AlldebridCom, BypassCaptcha, CaptchaBrotherhood, DeathByCaptcha, DebridItaliaCom, DeleteFinished, DownloadScheduler, EasybytezCom, ExpertDecoders, FastixRu, FreeWayMe, HotFolder, IRCInterface, LinksnappyCom, MegaDebridEu, MergeFiles, MultiHome, MultishareCz, MyfastfileCom, OverLoadMe, PremiumTo, PremiumizeMe, RPNetBiz, RealdebridCom, RehostTo, RestartFailed, SimplyPremiumCom, SimplydebridCom, UnrestrictLi, WindowsPhoneToastNotify, XMPPInterface, ZeveraCom
Downloadtime: True
Free space: 11.25 GiB
Starting builtin webserver: 0.0.0.0:5555
Activating Accounts...
Activating Plugins...
pyLoad is up and running
UpdateManager: No new pyLoad version available
UpdateManager: No plugin updates available

Starte ich wieder ganz normal über das Freetz-Webinterface, dann steht nur:
Code:
Starting pyLoad 0.4.9
Using home directory: /var/media/ftp/UStor01/pyload
 
Zuletzt bearbeitet:
womit diese Variante vermutlich flach fällt.
Die dirty-Lösung wäre es jetzt, wenn Du das benötigte Kommando einfach von einem anderen Daemon starten läßt:
Code:
delay -d [B]seconds[/B] [B]jobid[/B] "[B]command[/B]"
Damit startet mit einer Verzögerung von 'seconds' Sekunden ein Prozess mit dem angegebenen 'command', die 'jobid' darf m.W. bis zu 8 Zeichen lang sein und sollte eindeutig sein (meinetwegen 'pyload' in Deinem Falle).

Ich kann die Datei jedoch nicht löschen, da sie als readonly im Pfad [...] liegt.
Vor dem Packen des Images z.B. in der fwmod.custom löschen lassen.

Allerdings muß es ja eine Ursache geben für den nicht erfolgten Start. Gibt es bei Dir eine Datei '/mod/pyload/pyload.conf' ? Wenn ja, was steht dort drin ?
 
Allerdings muß es ja eine Ursache geben für den nicht erfolgten Start. Gibt es bei Dir eine Datei '/mod/pyload/pyload.conf' ? Wenn ja, was steht dort drin ?
Ja, die gibt's - der Pfad ist dabei scheinbar direkt auf den USB-Stick verlinkt:
Code:
root@fritz:/var/mod/root# cd /mod/pyload/
root@fritz:/var/media/ftp/UStor01/pyload#

So sieht die pyload.conf aus:
Code:
version: 1

remote - "Remote":
        bool nolocalauth : "No authentication on local connections" = True
        bool activated : "Activated" = False
        int port : "Port" = 7227
        ip listenaddr : "Adress" = 0.0.0.0

log - "Log":
        int log_size : "Size in kb" = 100
        folder log_folder : "Folder" = Logs
        bool file_log : "File Log" = True
        int log_count : "Count" = 5
        bool log_rotate : "Log Rotate" = True

permission - "Permissions":
        str group : "Groupname" = users
        bool change_dl : "Change Group and User of Downloads" = False
        bool change_file : "Change file mode of downloads" = False
        str user : "Username" = user
        str file : "Filemode for Downloads" = 0644
        bool change_group : "Change group of running process" = False
        str folder : "Folder Permission mode" = 0755
        bool change_user : "Change user of running process" = False

general - "General":
        en language : "Language" = en
        folder download_folder : "Download Folder" = Downloads
        bool checksum : "Use Checksum" = False
        bool folder_per_package : "Create folder for each package" = True
        bool debug_mode : "Debug Mode" = False
        int min_free_space : "Min Free Space (MB)" = 200
        int renice : "CPU Priority" = 0

ssl - "SSL":
        file cert : "SSL Certificate" = ssl.crt
        bool activated : "Activated" = False
        file key : "SSL Key" = ssl.key

webinterface - "Webinterface":
        str template : "Template" = default
        bool activated : "Activated" = True
        str prefix : "Path Prefix" =
        builtin;threaded;fastcgi;lightweight server : "Server" = builtin
        ip host : "IP" = 0.0.0.0
        bool https : "Use HTTPS" = False
        int port : "Port" = 5555

proxy - "Proxy":
        str username : "Username" = None
        bool proxy : "Use Proxy" = False
        str address : "Address" = "localhost"
        password password : "Password" = None
        http;socks4;socks5 type : "Protocol" = http
        int port : "Port" = 7070

reconnect - "Reconnect":
        time endTime : "End" = 0:00
        bool activated : "Use Reconnect" = False
        str method : "Method" = None
        time startTime : "Start" = 0:00

download - "Download":
        int max_downloads : "Max Parallel Downloads" = 3
        bool limit_speed : "Limit Download Speed" = True
        str interface : "Download interface to bind (ip or Name)" = None
        bool skip_existing : "Skip already existing files" = False
        int max_speed : "Max Download Speed in kb/s" = 300
        bool ipv6 : "Allow IPv6" = False
        int chunks : "Max connections for one download" = 3

downloadTime - "Download Time":
        time start : "Start" = 0:00
        time end : "End" = 0:00

Als IP hatte ich auch schon die tatsächliche IP der Box angegeben, was aber nicht's ändert. Ohne den Daemon läuft das Webinterface ja auch mit dieser Konfiguration (Standard-Port wäre 8000, da übernimmt er meine 5555 ja).

Damit wir uns nicht falsch verstehen - pyload läuft laut Freetz-Webinterface und Log bei allen der o.g. Befehle - nur das WebIF nicht.
 
Zuletzt bearbeitet:
Damit wir uns nicht falsch verstehen - pyload läuft laut Freetz-Webinterface und Log bei allen der o.g. Befehle - nur das WebIF nicht.
Verstehe ich das richtig ? Auch beim Start über das Freetz-Interface läuft pyLoadCore.py, wenn Du mit 'ps w' nachschaust ? Aber dann ohne allen Kontakt zur Außenwelt und ohne das Lesen und Interpretieren der Konfiguration, oder ?

Ansonsten bin ich auf der falschen Baustelle ... nun ist Freetz-Mod und der Ablauf beim Start von Services aber auch schon seit Jahren nicht mehr mein Ding.

Ursprünglich hätte ich darauf getippt, daß bei Start über Freetz der Aufruf mit den Parametern "--daemon -p $PID_FILE" erfolgt (im Gegensatz zum "manuellen" Start) und - nach meinem Verständnis und dem Verfolgen der Abläufe - da einfach $PID_FILE nicht gesetzt ist. Ein Setzen eines Standard-Namens, wenn es im rc-File nicht passiert, konnte ich nicht in den mod-Files finden ... das muß nicht heißen, daß es das nicht trotzdem gibt.

Ich hätte aber als Test in der Datei 'make/pyload/files/root/etc/init.d/rc.pyload' den Eintrag von
Code:
PID_FILE=/var/run/$DAEMON.pid
vor Zeile 5 empfohlen.

Da auch das Freetz-GUI bei der Anzeige des pyLoad-Status nach dem Status des Dienstes fragt und dieser wieder über das PID-File ermittelt wird, dachte ich eigentlich, vor der richtigen Schmiede zu sein. Vielleicht habe ich Dich ja auch falsch verstanden und Du probierst den o.a. Vorschlag doch einmal aus.

EDIT:
Ansonsten schau mal mit 'ls' in /var/run nach, ob da ein PID-File steht für pyload.

EDIT2:
Ok, das Setzen des Namens für das PID-File habe ich doch noch gefunden in modlibrc ... dann vergiss das oben stehende bitte.
 
Zuletzt bearbeitet:
@horst123456: kann das Problem bestätigen, vermutete Ursache ist diese Methode, die aus was auch immer welchen Gründen nicht mehr funktioniert bzw. python bleibt in dieser hängen - habe es allerdings noch nicht näher eingrenzen können.

Edit: folgender Workaround scheint zu funktionieren - starte pyload vorübergehend mittels start-stop-daemon -S -b -x /opt/pyLoad/pyLoadCore.py (in busybox muss dafür start-stop-daemon applet ausgewählt sein).
 
Zuletzt bearbeitet:
Verstehe ich das richtig ? Auch beim Start über das Freetz-Interface läuft pyLoadCore.py, wenn Du mit 'ps w' nachschaust ? Aber dann ohne allen Kontakt zur Außenwelt und ohne das Lesen und Interpretieren der Konfiguration, oder ?
Ich habe pyload über das Freetz-WebIF gestartet, 'ps w' bringt dann zum Thema pyload:
Code:
 2161 root     12608 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py --
daemon -p /var/run/pyload.pid
 2172 root     12608 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py --
daemon -p /var/run/pyload.pid
 2173 root     12608 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py --
daemon -p /var/run/pyload.pid
In /var/run liegt dann auch eine pyload.pid. Es läuft also scheinbar, bleibt aber entweder wirklich irgendwo hängen oder läuft ohne irgendeine Konfiguration. Letzteres würde mich aber wundern, da - wenn ich mich nicht irre - das WebIF von pyload standardmäßig aktiviert und auf Port 8000 gelegt ist. Es ist aber unter keinem der offenen Ports zu erreichen (habe bei beiden Varianten einen Port-Scan gemacht).

Wenn ich pyload mit 'python /opt/pyLoad/pyLoadCore.py' starte, gibt 'ps w' das hier aus:
Code:
 3342 root     17748 S    /usr/bin/python2.7.bin /opt/pyLoad/pyLoadCore.py
 3345 root         0 SW   [flush-8:0]
 3346 root     18080 R    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
 3347 root     18080 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
 3348 root      1216 S    -sh
 3388 root     18080 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
 3391 root     18080 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
 3392 root     18080 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
 3393 root     18080 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
 3397 root     17748 S    /usr/bin/python2.7.bin /opt/pyLoad/pyLoadCore.py
 3398 root     17748 S    /usr/bin/python2.7.bin /opt/pyLoad/pyLoadCore.py
 3399 root     17748 S    /usr/bin/python2.7.bin /opt/pyLoad/pyLoadCore.py
 3400 root     17748 S    /usr/bin/python2.7.bin /opt/pyLoad/pyLoadCore.py
 3401 root     17748 S    /usr/bin/python2.7.bin /opt/pyLoad/pyLoadCore.py
 3404 root     17748 S    /usr/bin/python2.7.bin /opt/pyLoad/pyLoadCore.py
 3405 root     17748 S    /usr/bin/python2.7.bin /opt/pyLoad/pyLoadCore.py
Bei diesem Aufruf ist keine entsprechende pid-file in /var/run zu finden (wird nur bei einem Daemon angelegt?).

(in busybox muss dafür start-stop-daemon applet ausgewählt sein).
Hat eine Weile gedauert, bis ich den Punkt beim Image-Bau gefunden habe - nur um dann zu sehen, dass er schon ausgewählt war. :p
Ich habe pyload nun damit gestartet und das WebIF läuft. Der Vollständigkeit halber, 'ps w':
Code:
14472 root     17748 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
14475 root     17748 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
14476 root     17748 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
14481 root     17748 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
14482 root     17748 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
14483 root     17748 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
14486 root     17748 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
14492 root     17748 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
14493 root     17748 S    /usr/bin/python2.7.bin -B /opt/pyLoad/pyLoadCore.py
Auch hier liegt keine pyload.pid in /var/run.

Kann ich den Befehl einfach in die rc.custom reinbappen?

BTW: Ich habe mal versucht den Thread-Titel etwas an das aktuelle Thema anzupassen.

edit:
@horst123456: kann das Problem bestätigen, vermutete Ursache ist diese Methode, die aus was auch immer welchen Gründen nicht mehr funktioniert bzw. python bleibt in dieser hängen - habe es allerdings noch nicht näher eingrenzen können.
An der Stelle hatte ich vermutet, dass sich ein Rechtschreibfehler eingeschlichen hat - in der Datei steht 2x "deamon" anstelle von "daemon". Ich habe das einfach mal vor dem make in den vorhandenen pyLoadCore.py-files geändert, es ändert aber leider nichts an dem beschriebenen Verhalten...
 
Zuletzt bearbeitet:
Sowohl beim Trunk als auch bei der Stable-2.0 wird die gleiche pyload-Version verwendet (0.4.9-git-stable-branch) - bei der stable-Version lief das ohne Probleme.

Vielleicht hat es daher eher was mit Python an sich zu tun. Bei der Stable-2.0 kommt Python 2.7.4 zum Einsatz, beim Trunk die Version 2.7.8.
 
Vielleicht hat es daher eher was mit Python an sich zu tun. Bei der Stable-2.0 kommt Python 2.7.4 zum Einsatz, beim Trunk die Version 2.7.8.
Irgendwo schwirrt bei mir noch eine Erinnerung im Kopf herum, daß bei Python 2 etwas mit Child-Prozessen im Argen war ... keine Ahnung, ob das zwischen diesen beiden Versionen gefixt wurde.

Da ja nun Python 3 schon einige Jahre am Start ist, mache ich eigentlich absolut nichts mehr mit Python 2 ... steht denn auf pyload.org nichts zu den Python-Versionen ?
 
Rein aus dem Kopf: Ich hatte dort irgendwo gelesen, dass einige Probleme mit der 2.7.x haben und daher die 2.6.x verwenden. Was/wie/wann/warum muss ich nochmal gucken. :p

Kann man testweise einfach vor dem make die Dateien von Python 2.7.4 (von der Stable-2.0) in den entsprechenden Ordner vom Trunk packen und damit die 2.7.8 ersetzen? Oder ist so ein Gefriemel eher nicht ratsam? :confused:
 
Aus dem NetBSD-Mailinglist-Archive
Code:
When a child is forked, it gets a copy of the executing thread
only.  If another thread happens to hold a mutex in the malloc
module, and then a child tries to do a malloc or free, the child
will hang, because the thread which holds the mutex will never
come alive and free it.

Klingt als könnte dies auf pyLoad zutreffen. Muss es mir aber genauer anschauen (bin immer noch nicht dazu gekommen).

Edit: Vermutung (vom Lesen her, noch keine Gelegenheit es zu testen) - vor den beiden dup2-Zeilen fehlt
Code:
os.dup2(os.devnull, 0)
 
Zuletzt bearbeitet:
Ich hab's einfach mal eingebaut, ändert leider nix.
 
Konnte leider noch nicht eingrenzen, was da schief läuft. Habe ehrlich gesagt auch nicht viel Lust, viel Zeit in die Sache zu investieren. Habe daher erst mal einen start-stop-daemon basierten Workaround umgesetzt. Bei mir geht's damit.
 
Reicht ja so auch erstmal, ich müsste es mal in das Image einbauen und neu kompilieren. Das lasse ich aber fürs erste weg und starte pyload per telnet. So oft wird meine Box nicht neugestartet. :eek:

Danke auf jeden Fall für die Hilfe!
 
Gleiches Problem tritt bei Transmission auch auf. AUfgrund von Platzmangel auch keine Konfiguration möglich bzw. gespeichert. Ich denke die ÄNderung der Mountpoints werden auch in anderen Bereichen zu möglichen Fehlern führen.

What to do?
 
MAGIo schrieb:
Einen allgemeineren Mechanismus zum Lokalisieren von USB-Datenträgern finden bzw. den AVM-Weg übernehmen.

Nach dem derzeitigen Kenntnisstand sieht es ja so aus, daß AVM dort an der Verwaltung von mehreren Datenträgern (das macht spätestens bei 2 USB-Ports an einem Gerät ja auch Sinn) und auch an der Verwaltung von mehreren logischen Volumes (Partitionen) auf einem physikalischen Datenträger (das verwendet AVM dann selbst z.B. bei der 6490, wo der interne NAND als "Festplatte" (mmcblk) angesprochen wird) arbeitet.

Es fehlt also an einer Freetz-Funktion, die die diversen Freetz-Pakete benutzen könnten, um den richtigen Platz für ihre Default-Konfiguration (die fast immer fest auf /var/media/ftp/uStor01 eingestellt ist) stattdessen auf der konkreten Box abzufragen (ganz so, wie es AVM offenbar mit der /var/tmp/mediadevmap auch macht).

Die derzeitige Lösung mit der Änderung des MP-Namens ist auch nur ein Workaround, wenn FREETZMOUNT unbedingt ins Image soll.

Solange die eigentliche Ursache weiter im Dunklen liegt, bleibt entweder die Anpassung der verwendeten Pakete oder das Auslassen von FREETZMOUNT aus dem Image (was offenbar hilft, gegenteilige Meldungen sind bisher Mangelware), wobei auch ohne FREETZMOUNT die Default-Konfiguration i.d.R. nicht stimmen wird, denn dann gibt es ja auch kein /var/media/ftp/uStor01.

Es ist ziemlich sicher nicht nur der Name, sondern noch etwas anderes im FREETZMOUNT - die reine Änderung eines MP-Namens ohne Freetz und damit auch ohne FREETZMOUNT (einfach durch Änderungen in der udev-mount-sd zur Abfrage eines Labels) führt - bei mir jedenfalls - noch nicht zum Absturz.
 
Problem ist leider immer noch akut. "Insufficient Storage" ist für jegliche Module die Folge, auch für SWAP.
 
Na das einfachste wäre doch das Anpassen des Mountpoints in den Standard-Einstellungen der Pakete (liegen irgendwo unter make/<paket>/files/...) und dann ein knackiges 'make', womit dann zu den neuen Mountpoint-Namen passende Einstellungen (als Standard, das sollte man imho eigentlich auch nachträglich problemlos korrigieren können) schon im Image sein sollten.

Oder wo verstehe ich das jetzt falsch ?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.