Beiträge von Fred Bogus Trumper

    Ich lese hier immer noch gerne mit, auch wenn ich nicht mehr so gerne aktiv bin.

    Sieh' meinen Post bitte nicht als Angriff - schon gar nicht als persönlichen. Aber ich hätte das auch wie viele andere einfach wieder mal kommentarlos lesen können. Aber so kommt vielleicht ein Stein ins Rollen der wieder etwas Stimmung in die Bude bringt ;)

    Ich will jetzt nicht Öl ins Feuer schütten oder eine unnötige Diskussion beginnen. Aber nachdem das Board alles andere als "userfreudlich" war bzw. ist, darf man sich nicht wundern, dass die user und ergo auch die Spenden ausbleiben


    Jede Medaille hat zwei Seiten. Aber ihr macht die Regeln, dass ist zu akzeptieren - wie auch die Folgen ...

    Schade drum.

    Gute Frage!


    Den Umweg über die connman settings habe ich selbst rausgefunden. Das funktioniert auch und ist in ~60 Sekunden eingestellt. Also warum 2 Mannstunden investieren, die bei meinen Python Kenntnissen auf mindestens auf das 10fache anwachsen würden.


    In der Zeit habe ich mit Trödeln 1000 mal die settings manuell über das CLI angepasst ...


    Und wenn die meisten User nicht mal die 10 Minuten investieren wollen um das HowTo zu lesen - wofür ich zumindest ebensolange gebraucht habe - muss man kein Rechenkünstler sein, um zu wissen was unterm Strich bei dem Zeitinvestment rauskommt.


    Die Zeiten sind längst vorbei, in denen User das fixen was DMM verbockt hat. Ich hab' das nicht ohne Grund Im Forum Bugreports im DMM Board gepostet

    ja danke, aber das chaos was denn jetzt der timeserver ist loest sich dadurch ja leider auch nicht. Ich muss mir da mal was ueberlegen wie man das ordentlich loesen kann.

    Das Ist zwar wahrscheinlich ein großer Aufwand - aber vielleicht über die timezone?


    d.h. das plugin liest die timezone aus und setzt entsprechend der timezone den entsprechenden ntp server und schreibt ihn in die conmann settings


    nach dem schematischen Motto

    Code
    1. case $(grep config.timezone.val /etc/enigma2/settings|cut -d\) -f2) in
    2. " Amsterdam, Berlin, Bern, Rome, Vienna") TIMESERVER="de.ntp.pool.org at.ntp.pool.org";;
    3. .
    4. .
    5. esac
    6. echo "Timerservers=$TIMESERVER;" >> /var/lib/connman/ethernet_000934*_cable/settings


    oder über eine hinterlegte "Datenbank", die beim setzen des Zeitservers über die GUI nur noch Server aus der entsprechenden timezone anbietet


    So wie das von DMM gelöst ist finde ich ziehmlich schwach. Von dem "Feature" des nicht veränderbaren default timeservers das mehr verwirrt als nutzt wissen sie auch nicht erst seit gestern ...

    IDIch habe hddtemp auch schon länger nicht mehr verwendet. den wert spuckt das binary meines Wissens trotzdem aus - auch wenn die hdd nicht in der db hinterlegt ist, es liefert dann keine Beizeichnung der disk. Kann man den teil nicht weglassen? Also nur den part nehmen, der den S.M.A.R.T Wert ausliest?


    Allerdings hat das auch einen Nachteil: die meisten Platten springen an, wenn über S.M.A.R.T. die Temp ausgelesen wird, ausser die meisten aktuellen Western Digital Platten, die bleiben im Standby.

    falls es eine 5.1 oder 6.0 gibt hätte ich noch einen Vorschlag:


    Ich bin ein Freund von aliases. Kannst du das mit aufnehmen

    /etc/profile.d/localfeed_aliases.sh

    Code
    1. alias localfeed='/data/localfeed/localfeed.sh'
    2. alias cdlocalfeed='cd /data/localfeed'

    dann kann man mit localfeed die Packages.gz einfach über das CLI updaten ohne den absoluten Pfad zur localfeed.sh anzugeben oder zuerst nach /data/localfeed/ zu springen, was aber mit cdl<TAB> <ENTER> einfach zu bewerkstelligen wäre


    Ich hab' schon angelegt, wäre ein easteregg für die Allgemeinheit

    Ich werd's weiter testen


    ich mach noch die Optionen --all (default), --mipsel und --armhf ins Script


    wenn eine der Optionen angegeben wird, wird im entsprechenden KITDIR [localfeed|localfeed/local-armhf|localfeed/local-mipsel] gesucht und für jede Architektur eine eigenen Packages.gz erstellt. Das ist für das Plugin wohl oversized ...


    Die source lists lege ich dann manuell auf den Boxen an und die feeds werden über http:// im Heimnetz bereitgestellt


    thx noch mal für das script, ich wollte das schon länger umsetzen und dachte, dass eine gpg signatur für den feed Voraussetzung ist - aber das war mir zu aufwändig

    Danke für's fixen!


    lag scheinbar doch an deinem script, mit der v0.4 klappt es jetzt ohne Hash mismatch ohne etwas am Paket zu ändern.



    Hätte gestern doch dein Script checken sollen anstatt an den Paketen rumzubasteln - ich geh' meist erstmal davon aus, dass ich einen Fehler gemacht habe ;)


    eine Liste der möglichen Felder im control file habe ich hier gefunden -> https://www.debian.org/doc/deb…document-ch-controlfields

    das mit dem control file könnte die Ursache sein, sieht so aus

    die description im control file habe auch schon entsprechend gekürzt, half auch nichts


    in der Packages sieht das dann so aus, und passt meines Erachtens auch

    auffallend ist, dass die Maintainerinfo in der nigma2-plugin-extensions-localfeed Info inder Packages 2x vorhanden ist


    das gesftpserver_0.2.2_armhf.deb findet man auch im DMM Board

    Das mit der Signatur ist klar, die Meldung kommt ja auch, wenn ich das localfeed.deb installiere.


    lösche ich die MD5sum aus der Packages kommt Size mismatch, lösche die Size aus der Packages kommt noch ein Error, den habe ich jetzt nicht mehr im Kopf, irgend etwas mit 201, vermute weil keine Sig mehr findet


    als letze Meldung kommt immer

    Code
    1. E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

    update und --fix-missing habe ich natürlich auch versucht.


    Es tritt auch nur bei bestimmten selbst erstellten Paketen auf, die sich ohne weiteres mit dpkg installieren und removen lassen


    Ich muss mir das am Abend nochmal in Ruhe ansehen, aber ich denke das hat nichts mit dem localfeed plugin zu tun, da läuft eher hier etwas falsch ...

    gutemine


    wie packst du die .deb's


    ich bekomme hier bei einigen selbsterstellten Paketen einen Hash Sum mismatch bzw. Size Error wenn ich über apt-get installieren will.


    Wenn ich allerdings die MD5sum und Size des Paketes mit der MD5sum und Size in der Packages vergleiche stimmen die überein.


    dein localfeed.deb geht durch


    ein apt-get clean && rm -rf /var/lib/apt/lists/* etc. bringt auch keine Abhilfe


    Ich hab' das betroffene Paket jetzt schon auf unterschiedliche Arten und und Systemen erstellt, immer der gleiche Fehler


    Hast du eine vielleicht eine Idee? Könnte das an deinem Script liegen?




    @Jogi



    ich kann euch schon verstehen, was euch Kopfweh macht. Aber man muss keine feeds mischen um aus dem GP3 feed Pakete zu klauen. Da gäbe es auch andere Möglichkeiten. Ohne dem localfeed plugin installiert der Bösewicht eben mit dpkg - also hat das eine nichts mit dem anderen zu tun.



    Wenn jemand an eure Pakete will, kommr er auf bestimmten Wegen immer ran, das werdet ihr glaube ich nicht verhindern können.

    Darum geht es hier eigentlich nicht

    wenn einer fremdfeeds in sein image macht wird er eh schnell merken, dass das keine gute Idee war


    alleup


    wenn du per dpkg -i ein paket installierst, musst du apt-get install -f nachjagen, wenn Abhängigkeiten nicht installiert sind

    apt-get install installiert die Depends automatisch, sofern sie am feed liegen

    Also werden nur die selbst reinkopierten genommen. Man selber muß dann seine Pakete aktuell halten?

    ja, das ist dein privater feed

    dort kannst du Pakete ablegen, die nicht am image feed liegen oder die du selbst gebaut hast udgl. Wenn du mehrere Boxen im Netzwerk hast, kannst du den lokalen feed über nfs oder cifs share bereitstellen und die /etc/apt/sources.list.d/localfeed.list entsprechend anpassen. Das Feedupdate erledigst du auf der Serverbox (neue Pakete hinzufügen, updates etc.)

    der Vorteil: nach einem neuflash einfach den localen feed hinzufügen, dann kannst du alle "Fremdpakete" ganz normal über apt-get installieren


    @ alle das sich bei uns anzapfen will:

    Wundert euch nicht wenn euer box nicht mehr startet! Gegenmaßnahme werden eingeschaltet.:thumbdown:

    Ich vermute du beziehst dich auf mich


    Wer hat etwas vom IHAD anzapfen gesagt? Ich habe das weder vor noch habe ich das jemals gemacht, ich glaube du verrennst dich gerade in etwas.


    Im DMM Board gings nur darum einem notifier zu basteln, wenn es eine neue Version des besagten Plugins gibt, aber selbst das würde ich nie puplic machen. Aber auf solche Ideen können andere auch kommen, da braucht es mich nicht dazu

    ich hab' mal binutils und tar deinstalliert, wie vermutet:


    ar ist im package binutils enthalten, da gibt es kein busybox ar, zumindest nach der deinstallation der binutils

    Code
    1. root@dm900uhd:~ # ar --help
    2. -bash: ar: command not found
    3. root@dm900uhd:~ #


    das busybox tar kennt den Schalter -J scheinbar doch, das muss neu sein


    um binutils wirst du nicht rumkommen - oder du verwendest dpkg-deb -e, dann liegt das control file in ./DEBIAN und kannst dir ar und tar gänzlich sparen

    damit es nicht heißt, dass das keiner testet ;)


    Ich hab's kurz getestet. So mag ich es, funktionell und schnörkellos


    Das Plugin tut was es soll und apt-get install findet lokal Sachen die definitiv auf keinem offiziellen Feed liegen ;)


    dein etwas modifizierte script läuft mittlerweile am Raspberry Pi und stellt 3 lokale sourcen bereit: all, mipsel und armhf

    Die lokale source.list auf den Boxen ist natürlich angepasst


    gibt es einen bestimmten grund warum du file:/ anstatt copy:/ verwendest?


    PS:

    mein "dbackup update scanner" läuft auch bereits, bin gespannt wie lange es dauert, bis dbackup_0.96 in der lokalen source.list ohne mein zutun auftaucht. Aber das ist nur ein Test, ich wollte nur wissen wieviel Aufwand das wirklich ist - hält sich in Grenzen ;)



    \\Edit:

    Ich bin zufällig darüber gestolpert. Wenn ich mir das localfeed.sh ansehe, gehören als dependencies tar und binutils ins control file damit es keine troubles gibt ...


    auf meiner Box war es egal, weil beides schon installiert war ...

    Ich hab' nach deinem letzen hint ne Weile gesucht und ein paar Ideen ausgebrütet die aber nicht funktioniert haben. Aber wenn du sagst, dass man CFE austricksen kann glaub' ich dir das, aber wahrscheinlich habe ich mich noch immer zu sehr von "alten" Methoden beeinflussen lassen :)


    hab' länger nicht dran rumgebastelt und bin bei modify environment zuletzt hängen geblieben


    Das musst du entscheiden, hier funktoniert das jetzt, hab' die Box ein paar mal mit und ohne Stick und HDD gebootet


    Zumindest von einem weiß ich, der das wohl noch dieses Wochenende testen wird

    Aber wenn es nur die zwei Code Zeilen waren, wird wohl sonst im kit nichts kaputt gegangen sein


    ich hab' im Flash den Stick vom flodder directory befreit und mit Stick neu gebootet, Flodder hat dann beim booten wieder brav /flodder am Stick neu befüllt und nach dem reboot vom Device gebootet

    vom bootlog wenn es funktioniert hast du aber nichts gesagt :)


    Ich sehe nichts Äuffälliges, Flodder bemerkt nun: Still in flash ....


    der boot wird auch nur kurz verzögert



    Schau dir das postinst an wenn du sehen willst wie es sich das binary auch im Flash austauscht, selbst wenn man beim installieren vom Flodderdeivce gebootet ist


    so ähnlich mache ich es auch, aber ich bin über einen anderer Fallstrick gestolpert:

    Wenn man die Box komplett von USB bootet (kernel auf FAT) wird /dev/ubi0_0 gar nicht erstellt, d.h. man muss mtd-utils-ubiattach installieren, damit man mit ubiattach das /dev/ubi0_0 erzeugen kann, damit man den Flash mounten kann.


    Wenn das wegfällt wenn die Box vom Flodderdevice bzw. den kernel vom Flash gebootet ist das ja viel weniger Aufwand, aber das ist ja jetzt mit der 0.1.8 wohl hinfällig bzw. hier offtopic

    Nochmals das Flodder such sich sein device schon selber ich weis nicht wer diese Mär mit dem flodder directory in die Welt gesetzt hat, aber das ist FALSCH und sollte nur in Ausnahmefällen verwendet werden.


    Insofern ist da eben KEIN versehen sondern die korrekte Vorgangsweise wenn du einen Stick < 32GB verwendest und sonst kein device an der box ist - ausser eine Harddisk die aber eben meistens größer als 32GB sein wird, oder ?

    dann habe ich dich vorhin wohl missverstanden, aber egal


    nach dem Neuflashen habe ich ja kein flodder directory am Stick gehabt, das habe ich ja gelöscht - also korrekt

    dann wurde beim Boot mit der alten 0.1.7 Version ohne device in den flash gefloddert



    ich hab' jetzt die 0.1.7 deinstalliert und das Testkit installiert


    und einfach mal ohne Stick rebootet, Box bootete sauber vom Flash


    dann den flodder Ordner am Stick in "dujetztnicht" unbenannt und rebootet

    es wurde neu gefloddert und das flodder rootfs wird beim Boot eingebunden


    Dann wieder ohne Stick neu gestartet, diesmal ging auch das gut, der Flash blieb verschont :)



    Kann man das Testkit drüberbügelen oder muss man die alter Version vorher deinstallieren? Ich hatte es zur Sicherheit gemacht

    ich hab' das jetzt mal komplett neu mit der 0.1.7 durchgespielt


    letztes OE2.0 dmm experiamental neu geflasht und flodder installiert

    /flodder/flash und /flodder/root wurden bei der Installation von Flodder erstellt


    bewusst KEIN Flodder directory am Stick angelegt und rebootet

    Box ist vom Flodder device gebootet, alles ok

    es gibt weiterhin nur /flodder/flash und /flodder/root in /dev/mtdblock3 - aber leer (flash zur Überpfüfung gemountet)



    Box abgedreht, Stick raus, boot

    da es kein device gibt, kann es auch kein norun oder flodder geben, nur das /flodder, welches bei der Installion erstellt wurde

    Flodder will beim Boot in den Flash floddern und swappen und endet in einer kernel Panik und die Box kommt dann 2. Anlauf mit zugemülltem Flash hoch


    Wenn man ein /flodder directory am Stick anlegen muss BEVOR man das Plugin installiert, sind wohl viele in die Falle getappt, wenn das das verursacht, wenn im worst case in den Flash gefloddert wird


    so sieht der log aus

    btw. scheinbar kann man hier keine .log files hochladen


    ich teste das jetzt mal mit der 0.1.8

    das hatte ich versucht, das klappte aber nicht

    die Ordner waren da, aber leer

    das hatte ich vorhin noch geprüft, das puttyfenster ist zum Glück noch offen


    ich mach' gerade alles neu

    jetzt wird es echt spannend


    mir hat es vorhin 5x hintereinander den Flash zugeballert, als ich ohne USB/HDD gebootet habe, jetzt bootet die Box ohne Device durch und floddert nicht mehr in den Flash


    Ich hatte vorher ein paar "Tricks" versucht um das zu verhindern, scheinbar hat nun doch einer gezogen


    Ich muss neu flashen


    Oder hast du eine MB Grenze eingebaut? Vorhin hatte ich 5MB im Flash frei, jetzt nur noch 3MB , nachdem ich den /flodder/flash/flodder bereinigt habe

    ja, das teste ich gerne, die hdd liegt wie der Gehäusedeckel noch neben der Box ;)


    Warum das beim Testen nicht aufgefallen kann ich nicht, sagen. Vermutlich hat nicht mal ein Benutzer einer dm500hd v1 mit USB-Mod jemals ohne USB gebootet. Schon beim ewig lang dauernten 1. Boot wäre aufgefallen, dass da etwas nicht stimmen kann. Wenn es passiert ist, hat wohl keiner das Flash rootfs überprüft sondern einfach mit Stick neu gestartet.


    wg. dem workaround:


    Das das hier wieder in eine Diskussion ausartet und starke Arguemente benötigt bis du richtig "zuhörst" war mir von Anfang an klar, ausserdem war ich mir nicht sicher, ob du da noch etwas machen wirst.


    der "workaround" hat eigentlich nichts mit dem bug zu tun, das ist eigentlich ein Nebenprodukt dafür, wenn man bewusst ohne SCSI device booten möchte, ohne vorher flodder zu installieren, d.h. 2x rebooten.


    Aber wenn Flodder so intelligent ist und nicht in den Flash floddert, kann ich mir das sparen, wenn du das mit ein paar codezeilen fixen kannst. So bekommt Flodder sogar einen Mehrwert.

    Danke dafür

    die postrm hatte ich mir schon angesehen, keine Sorge


    mein flodderctl verbiegt init ähnlich, wenn ich vom Flodder device gebootet bin, aber das ist eine andere Geschichte und hat jetzt grundsätzlich nichts mit dem Verhalten von Flodder zu tun, wenn kein SCSI Device angesteckt ist.


    Wenn man Flodder loswerden will, muss man also

    ein norun directory am Flodder device = / anlegen

    reboot

    flodder deinstallieren

    shutdown -h now

    stick abziehen

    booten


    Alles schon und gut, aber wenn der Stick defekt ist und die Box deshalb direkt in den flash bootet wird der flash zugemüllt. Auch dann, wenn man die Box runterfährt, den Stick warum auch immer abzieht und dann versehentlich die Box startet oder vergisst den Stick wieder anzustecken.


    Meines Erachtens darf Flodder NIE versuchen in den Flash zu floddern. Aber das will Flodder in letzer Konsequenz und müllt damit den Flash zu - und das ist aus meiner Sicht bug, oder einfach nicht oder schlecht abgesichert, damit das nicht passiert. Nenne es wie du willst.


    Jetzt ist auch klar warum ich per PN wg. der Sache angeschrieben wurde. Solche Diskussionen tut sich nicht jeder an ;)

    das funktioniert aber nur, wenn das device mit dem norun directory im Rootverzeichnis in der Box steckt


    bootet die Box ohne hdd und ohne usb, wird auch das norun directory nicht gefunden - wie auch - und floddert in den flash


    Es gibt szenarien, wo man ohne device booten möchte, wenn flodder installiert ist. Wenn der Stick völlig im Eimer ist und gar nicht mehr erkannt wird und die Box in den Flash bootet passiert das ohne zutun des Anwenders ...


    Mich hat es nur gewundert, dass das überhaupt passiert. lt. 1. Post interessiert sich Flodder nur für ext devices und schnappt sich das letzte gefundene device, wenn kein flodder directory gefunden wird.


    Deiner Aussage nach dürfte also nie in den Flash gefloddert werden, weil das flash filesystem entweder jffse2 oder ubifs ist bzw. der nand Flash kein SCSI Device ist. Und weil das unter bestimmten Umständen passieren kann, ist das ein bug.

    Hi gutemine


    ich wurde in einem anderen Board per PN wg. Flodder gefragt - da ist jemand auf einen Bug gestoßen. ich hab' das mal nachgespielt und kann das bestätigen.

    Eigentlich soll ja lt. 1. Post nur auf ext3/4 devices gefloddert werden, aber Flodder floddert auch in den Flash und müllt ihn unter bestimmenten Umständen komplett zu - nämlich dann, wenn keine HDD angeschlossen UND kein USB device gefunden wird.


    Solange die Box vom Flodderdevice bootet ist alles gut. Aber wenn man runterfährt, den Stick abzieht und neu startet sucht Flodder wohl verzweifelt ein SCCI Device und floddert dann aus Verzweiflung in den flash ...


    Ich hab's hier nachgespielt,

    hdd aus der dm800se ausgebaut, OE2.0 Image geflasht, auf USB Stick gefloddert alles OK

    Box runtergefahren, Stick abgezogen und neu gestartet.


    Box verhält sich wie beim Floddern auf den Stick und bleibt ewig im Bootsplash im Display hängen, startet dann noch einmal durch und fährt dann hoch


    sieht dann so aus, die Daten landen alle in /flodder/root/flodder/

    (vor dem reboot waren gut 5MB im Flash frei)




    Besteht eine Chance das zu fixen? Ich hab' ein flodderctl gebaut, das /sbin/init im Flash wieder umbiegen kann, wenn vom Flodderdevice gebootet wurde, damit die Box ohne SCCI Device normal hochfährt - also quasi ein flodder on/off Schalter. Allerdings bin ich jetzt bei über 100 Codezeilen und ubifs ist noch nicht abgedeckt ...


    ach ja /norun im Flash funktioniert auch nicht und ich habe das aktuelle 0.1.7 Kit getestet