nach heutigem dist-upgrade opengl zerschossen

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hallo liebe Raspi-Freunde,

    ich besitze einen Raspi3 mit Jessie. Das System habe ich am 15.03. das letzte Mal aktualisiert, es lief einwandfrei. Ich hatte auch die experimentelle 3D-Unterstützung installiert, und auch die lief.

    Heute habe ich ein apt-get dist-upgrade gemacht, bei dem unter anderem auch der raspberrypi-bootloader ein Upgrade erfahren hat. Leider funktioniert seitdem opengl nicht mehr - nach dem Neustart bleibt der Bildschirm schwarz. Via ssh kann ich aber noch auf den Raspi zugreifen und opengl viaraspi-config deaktivieren - dann startet er wieder normal und mit Bild via HDMI. Nur funktionieren einige Programme nicht ohne opengl - und ich bekomme es nicht wieder zum Laufen.

    War es falsch, das Update mittels
    apt-get update
    apt-get dist-upgrade
    anzustoßen?

    Hätte ich besser
    rpi-update
    vorher machen sollen?

    Ich habe vom alten System noch ein Image- möchte aber vermeiden, in die gleiche Falle zweimal zu laufen...

    Gibt es ein Problem mit dem neuen bootloader (ich denke, dass dieses Paket den Fehler verursacht)? Oder ist es ein pebcac -Problem :shy:

    Bin für jeden weiterbringenden Tipp dankbar!

    Gruß
    df8oe

  • Servus df8oe,


    ...
    War es falsch, das Update mittels


    apt-get dist-upgrade
    anzustoßen?
    ...

    das dist-upgrade ist schon seit längerem nicht notwendig. Der gesamte Update/Upgrade wird über die "normale" apt-get Geschichte, also

    Code
    pi@rpi-lcurr ~ $ sudo apt-get update && sudo apt-get upgrade


    abgewickelt. Keine Ahnung, was Du Dir da mit dem dist-upgrade installiert hast. Evtl. sogar einen Kernel im Experimentier-Stadium ...


    ...
    Hätte ich besser
    rpi-update
    vorher machen sollen?


    Bloss nicht :@ ... (siehe u.a. -> z.B. hier <-).

    cu,
    -ds-

  • *hihi*

    Aber im Ernst: Es könnte in diesem Usecase ja durchaus sein, dass der TO rpi-update machen möchte und es ihm sogar etwas bringt, denn er nutzt mit dem OpenGL-Gedöns ja ganz bewusst ein experimentelles Feature. Nun hat es ihm das System über den regulären Update-Mechanismus zerbröselt (keine Ahnung wie wichtig ihm das ist, aber ich gehe davon aus, dass ich ein System was einem wichtig ist nicht dazu benutzt experimentelle Funktionen darauf auszuprobieren oder zu nutzen, wenn vermeidbar) - in diesem Fall könnte er mit rpi-update ja sogar Glück haben, dass damit eine Sache gefixt wird, die das durch die Aktualisierung entstandene Problem adressiert. Natürlich sollte man dazu vorher mal versuchen so etwas wie ein Changelog zu beaugäpfeln, aber mit einem Image der µSD kann man auch ein entspanntes "Versuch macht kluch" realisieren.

    An den TO aber dennoch die deutliche Warnung:
    rpi-update spielt quasi haufenweise sehr systemkritische Dinge in Deinen Pi ein, die nur sehr wenig (vielleicht sogar gar nicht) getestet sind - genau deswegen finden sich diese Aktualisierungen auch nicht im regulären Updatepfad. Wenn Du damit herumspielst und es ein Problem für Dich wäre wenn Dein RasPi dabei zerschossen wird, dann solltest Du auf die Aktualität Deiner Backups achten, so dass Du im Fall der Fälle leicht und locker zurückrudern kannst ;) Und da OpenGL auch noch nicht stabil ist, ist es tatsächlich auch so, dass man damit rechnen muss, dass die Funktionen durch Updates aus dem regulären Updatepfad außer Gefecht gesetzt werden können, denn diese werden dafür nicht all zu tiefgreifend überprüft.

    Aus privatem Interesse: Wofür nutzt Du das OpenGL-Gedöns auf dem Pi?

    Just my mustard & Gruß
    JC

    --
    "I know the human being and fish can coexist peacefully."
    G. W. Bush, 29. September 2000

  • WSJTX läuft nur, wenn opengl zur Verfügung steht. Ich mache gerade einen raspi fertig, auf dem Amateurfunkprogramme laufen und WSPR ist eine interessante neue digitale Betriebsart. Es gibt kein fertiges Paket für armhf, aber ich habe mir das Pogramm aus den Quellen problemlos bauen können. Es setzt auf qt5 auf, benötigt aber selbst nur sehr wenig CPU Power. Die Systemlast liegt mit LXDE und laufendem WSJTX unter 20% -also alles im grünen Bereich.

    Ichhabe sehr viel Erfahrung im Umgang mit Debian - aber beim Raspi muss ich noch viel lernen.

    Und aktuelle Backups sind ein MUSS - das gilt für die gesamte IT :)

    Gruß
    df8oe

  • Der Übeltäter war das Paket "raspberrypi-bootloader" - wie schon von mir vermutet. Alle anderen Pakete machen keine Probleme.

    Und gegen ein "dist-upgrade" anstelle eines "upgrade" ist auch nichts einzuwenden. Die beiden unterschieden sich nur dadurch, dass dist-upgrade auch Pakete, die sich durch ein upgrade anderer ergeben und jetzt überflüssig/störend sind, mit rauswirft. Da sind keine "gefährlichen" oder ungetesteten Pakete drin ::)n meinem Fall wurden bei dist-upgrade zwei python-Pakete entfernt und durch neue, anders bezeichnete mit mindestens der gleichen Funktionalität ersetzt.

    Ein rpi-update hat allerdings wie auch das Upgrade des obigen Paketes, zu einem Zerschießen der opengl-Funktion geführt.

    Also, Gefahr erkannt. KEIN rpi-update und für das obige Paket habe ich bis auf Weiteres ein apt-pinning durchgeführt Erklärung Pinning. Nunläuft wieder alles und auch Upgrads können regelmässig gefahren werden.

    ABER:
    Vorsicht ist die Mutter der Porzellankiste bei der Nutzung experimenteller Funktionen! Ein regelmässiges Abbild von der SD erstellt und der Streßfaktor bleibt stets niedrig :D

    Danke für eure Hilfe!
    df8oe

  • Servus df8oe,


    Der Übeltäter war das Paket "raspberrypi-bootloader" ...
    ... bis auf Weiteres ein apt-pinning durchgeführt ...


    ah ja ... das hatte ich vor einiger Zeit mal mit einer Framebuffer-Version gemacht (stand auf der Notro-Seite). Allerdings habe ich da

    Code
    sudo apt-mark hold <Package>
    oder
    sudo aptitude hold <Package>


    bzw. zum "entmarkieren"

    Code
    sudo apt-mark unhold <Package>
    oder
    sudo aptitude unhold <Package>


    (-> siehe auch hier <-)


    ... ein "dist-upgrade" anstelle eines "upgrade" ist auch nichts einzuwenden. ...

    Da schau her ... wieder was dazugelernt. Wobei es mir im Nachherein so vorkommt, als hätte ich diesbezüglich schon mal was gehört ...

    Danke für's feedback bzw. das Posten der Ergebnisse,
    -ds-

  • Ähm hier wird leider einiges durcheinander gewürfelt :(

    "dist-upgrade" ist nicht unbedingt überflüssig, wenn man denn weiß wann es zur Anwendung kommen sollte.
    "dist-upgrade" aktualisiert nicht nur die derzeit aktuell installierten Pakete (abgesehen von Abhängigkeiten dieser) sondern installiert auch zusätzlich Pakete. Kleiner aber Feiner Unterschied.

    "raspberrypi-bootloader" wird mit einem normalen "upgrade" installiert sofern dies aktualisiert wurde und beinhaltet den derzeit als STABLE markierten Bootloader, Firmware sowie Kernel.

    "rpi-update" hingegen installiert einen UNSTABLE Bootloader/Firmware/Kernel an dem aktuell entwickelt wird und eben zur Weiterentwicklung dient - wer das ausführt und dann Probleme hat ist selber Schuld :)

    Es ist folglich Quatsch "raspberrypi-bootloader" aus dem regulären Upgrade auszuschließen.


    OpenGL (auch als MESA-Version bekannt) ist wie bereits erwähnt wurde noch immer in der Erprobungsphase und noch immer UNSTABLE - deshalb auch "experimentelle Unterstützung": public beta test

    Am 09.02.2016 kam ein Raspbian Release mit diesem "experimental OpenGL driver", was aber Standardmäßig ausgeschaltet ist.
    Wer es ausprobieren möchte muss diesen erst einschalten, was beim Pi über "raspi-config" zu erledigen ist: Advanced Options->GL Driver
    Oder /boot/config.txt bearbeiten und "dtoverlay=vc4-kms-v3d" einfügen sowie rebooten.
    Funktioniert aber nur mit Pi2 bzw Pi3! Wer das missachtet darf seinem Pi1 dabei zusehen wie dieser nicht mehr bootet. Desweiteren benötigt dies viel zugewiesenem RAM für die GPU und sorgt zZt dafür das zB die PiCam nicht mehr funktioniert

    Mehr Details dazu: https://www.raspberrypi.org/blog/another-new-raspbian-release/
    Da kann man auch unter "How do I get it?" nachlesen das nicht nur "dist-upgrade" erforderlich ist, weil eben noch nicht installierte Pakete upgraded werden sollen sondern zusätzliche erforderlich sind.

  • Servus,


    ...
    Es ist folglich Quatsch "raspberrypi-bootloader" aus dem regulären Upgrade auszuschließen.
    ...

    naja, ich denke nicht ganz. Bei der Framebuffer-Geschichte musste seinerzeit das package auch zurückgehalten werden, weil sonst die Framebuffer-Unterstützung wieder futsch war. Zumindest war das so, bis die Framebuffer ins offizielle repo übernommen wurden. Ich find' da jetzt leider keinen Link mehr - evtl. hat Notro das bereits geändert, weil es mittlerweile überflüssig ist.
    Und wenn df8oe sagt, dass er nur eine funktionsfähige opengl-Unterstützung hat, wenn er den bootloader (und damit vermutlich auch einen Teil der Firmware) nicht aktualisiert, dann ist das wohl so und es macht imho durchaus Sinn den bootloader zurückzuhalten. Oder welche Option hätte er sonst? Also ich wüsste jetzt keine.

    ciao,
    -ds-

  • Es ist insoweit kein Quatsch, "raspberrypi-bootloader" aus dem regulären Upgrade auszuschliessen, weil es den experimentellen opengl-Treiber zerschießt. Sicher: für den Otto-Normal-Anwender wäre es sicher besser, mit neuerem Bootloader & Kernel zu fahren. Aber wer wie ich darauf ANGEWIESEN ist, dass die experimentelle Funktion "opengl" funktioniert, dem bleibt nichts anderes übrig, als erstmal zu warten. Viele der Programme, die mein Raspi3 abarbeiten soll, laufen nicht ohne opengl-Unterstützung! Also lieber einen nicht ganz so aktuellen Kernel aber opengl als neuerer Kernel und meine Programme laufen nicht mehr...

    Gruß
    df8oe

    EDIT:
    Außerdem bedeutet das ja nicht, dass ich nicht ab und zu mal schaue, ob das Zusammenspiel inzwischen funktioniert :)

    Einmal editiert, zuletzt von df8oe (6. April 2016 um 16:36)

  • Ja, schon... Bei der Framebuffer Geschichte nutzte man einen individuellen Kernel mit fb Unterstützung - wer dann das Paket "raspberrypi-bootloader" aktualisiert hat verlor auch die fb Unterstützung... Stimmt. Aber noch mal: Am 09.02.2016 wurde OpenGL ins Paket "raspberrypi-bootloader" eingefügt, als eine Art Öffentlicher Beta Test. Der Treiber muss aber gesondert aktiviert werden.

    Das sind zwei verschieden paar Schuhe - deshalb "durcheinander gewürfelt" :fies:

    Im Paket "raspberrypi-bootloader" steckt nicht nur ein bootloader. Der Bootloader alleine kann auch an nichts derartigem Schuld sein, ich erinnere an dieser Stelle gerne noch mal an Bootverlauf des RaspberryPI's


    //EDIT: OpenGL Unterstützung hast du auch ohne dieses experimentellen Treiber, wird dann nur von einem "software renderer" behandelt wodurch die CPU viel zu tun hat..

  • ...dann habe ich das falsch forumliert - sorry.

    Die Programme benötigen die Module der Hardwarebeschleunigung - sonst kommt außer der Meldung "kann nicht gestartet werden" GAR NICHTS.

    Und es ist absolut reproduzierbar. Ich habe jetzt alle Pakete upgegradet - außer dem bootloader.

    Ich habe die volle Hardware-3D-Unterstützung. Aktualisiere ich den bootloader, ist sie weg.

    Ich habe während der Einrichtung des bootloaders gesehen, dass zig Umlenkungen gesetzt und wieder gelöscht werden. Irgendwo in den ganzen Aktionen passiert was, was die 3D-Unterstützung auspustet.

    Ich habe absolut keinen Zwang, den Kernel oder den Bootloader zu aktualisieren. Ich weiß nicht, ob Bluetooth geht (oder mit dem neuen Kernel geht) - ich brauche aber auch im Moment kein Bluetooth. Aber die Hardware-3D-Beschleunigung brauche ich...

    "Geht nicht gibts nicht" - weiß ich von meinen Debian-Servern, die ich administriere. Da habe ich auch schon mal ein Paket selbst gebaut und vorher gepatched - aber da braucht ich sowohl die alte Funktion ALS AUCH das Update. Hier liegt die Sache anders - kommt Zeit, kommt Lösung. Keine Eile...

    Gruß
    df8oe

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!