Rpi-imager: RPi Imager 1.6.1 (und höher) kann nicht auf Ubuntu 18.04 installiert werden

Ich fürchte, 20.04 LTS ist ein neues Minimum, weil ich darauf aktualisiert habe. :-)
Sollte jedoch immer noch in der Lage sein, "debuild" von git selbst auszuführen.

Ich bin mir sicher, dass ich nicht die einzige Person sein kann, die noch Ubuntu 18.04 ausführt :wink: Und obwohl ich debuild ausführen kann, bin ich mir sicher, dass es viele weniger technisch versierte Benutzer gibt, die das nicht können?
Könnten Sie in einer VM oder so etwas bauen?

Ich betreue einen Schnappschuss von rpi-imager und habe ihn gerade so erweitert, dass er auf Ubuntu 20.04 aufbaut, aber er kann auch auf Ubuntu 18.04 (tatsächlich sogar 14.04 und 16.04) und anderen Distributionen installiert werden.

Als interessanter Datenpunkt zum "Wer läuft noch 18.04?" Frage, da ist noch eine ordentliche Zahl drauf. Unter den Benutzern von RPI Imager Snap verwenden ~13 % Ubuntu 18.04, ~56 % Ubuntu 20.04 und sogar ~2,7 % Ubuntu 16.04!

Sofern https://github.com/popey/imager-snap/issues/8 nicht behoben wurde, unterstützt der Snap leider nicht alle Imager-Funktionen. IIRC müssen Sie auch einige zusätzliche Berechtigungen aktivieren, um andere Fehler zu vermeiden. Es ist nicht offensichtlich, dass Sie das tun müssen oder wie. Da der Imager die Dinge vereinfachen soll, scheint der Snap Hürden einzuführen.

Im Idealfall wäre es großartig, es stattdessen in den normalen apt-Repos zu verwenden.

Es sei denn, popey/imager-snap#8 wurde gelöst

Funktioniert es unter 1.6.1 besser?

Ein Commit ( https://github.com/raspberrypi/rpi-imager/commit/c8409d741939c0af32180c731a86adcdeaba802d ) eingeschlichen, das es möglicherweise umgeht, aber keine Zeit hatte, herauszufinden, wie man einen Snap erstellt, um es zu testen.

Der Code ging bisher davon aus, dass sobald udisks2 (mit dem wir über DBus sprechen) uns mitteilt, dass der Wechseldatenträger (FAT32-Partition) gemountet ist, wir in den Mount-Ordner schreiben können.
Aber zu diesem Zeitpunkt ist es möglicherweise noch nicht in der Snap-Chroot gemountet, die hinterherzuhinken scheint.
Haben Sie also eine Überprüfung, die überprüft, ob der Mount-Ordner ein Mount-Punkt ist, und bis zu 3 Sekunden verzögert, wenn dies nicht der Fall ist.

Gerade ausprobiert und nein, es scheint schlimmer zu sein. Zuerst hieß es, die Partition könne nicht gemountet werden, also habe ich die entsprechende Berechtigung aktiviert. Gleicher Fehler, also habe ich alle Berechtigungen aktiviert, die deaktiviert waren (obwohl ihre Beschreibungen nicht relevant zu sein schienen) (PEBCAK). Jetzt verhält sich der Imager so, als wäre alles gut gegangen, aber die SD-Karte ist am Ende leer.

Qt: Session management error: Could not open network socket
QObject::setParent: Cannot set parent, new parent is in a different thread
Drive: "/org/freedesktop/UDisks2/drives/Generic__USB3_2e0_CRW____SD_201506301013_1"
Device: "/org/freedesktop/UDisks2/block_devices/sdc" belongs to same drive
Device: "/org/freedesktop/UDisks2/block_devices/sdc1" belongs to same drive
Unmounted "/org/freedesktop/UDisks2/block_devices/sdc1" successfully
Repartitioning drive
Telemetry done. cURL status code = 0
Adding partition
New partition: "/org/freedesktop/UDisks2/block_devices/sdc1"
Formatting drive as FAT32
Mounting partition
Mounted new file system at: "/media/shift/F28E-8BF1"
Image URL: "https://github.com/raspberrypi/rpi-eeprom/releases/download/v2020.09.03-138a1-imager/rpi-boot-eeprom-recovery-2020-09-03-vl805-000138a1-usb.zip"
Received header: HTTP/2 302 

Received header: server: GitHub.com
...
Can't create 'README.txt'
Can't create 'pieeprom.bin'
Can't create 'pieeprom.sig'
Can't create 'recovery.bin'
Can't create 'vl805.bin'
Can't create 'vl805.sig'
Hash of compressed multi-file zip: "84b73785a93720621136e23ee766e2e56a516902baaccebe3e055106471029ff"
mountutils: Reading /proc/mounts
mountutils: Mount point /dev/sdc1 belongs to drive /dev/sdc
mountutils: Mount point /dev/sdc1 belongs to drive /dev/sdc
mountutils: Closing /proc/mounts
mountutils: Unmounting /media/shift/F28E-8BF1...
mountutils: Unmount MNT_EXPIRE /media/shift/F28E-8BF1: EAGAIN
mountutils: Unmount MNT_EXPIRE /media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_DETACH /media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_FORCE /media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmounting /var/lib/snapd/hostfs/media/shift/F28E-8BF1...
mountutils: Unmount MNT_EXPIRE /var/lib/snapd/hostfs/media/shift/F28E-8BF1: EAGAIN
mountutils: Unmount MNT_EXPIRE /var/lib/snapd/hostfs/media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_DETACH /var/lib/snapd/hostfs/media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_FORCE /var/lib/snapd/hostfs/media/shift/F28E-8BF1 failed: Operation not permitted
Download done in 3 seconds

Insgesamt nicht die Erfahrung, die Sie jedem Benutzer wünschen würden.

„README.txt“ kann nicht erstellt werden

Ist /var/lib/snapd/hostfs/media/shift/F28E-8BF1 nicht für den Benutzer beschreibbar, den Snap Imager ausführt als?

Sollen wir das nach https://github.com/popey/imager-snap/issues/8 verschieben?

Unabhängig von Problemen mit Snap-Paketen denke ich immer noch, dass das von https://www.raspberrypi.org/software/ herunterladbare imager_1.6.1_amd64.deb auf Ubuntu 18.04 (das noch bis April 2023 unterstützt wird) installierbar sein sollte.
:slightly_srunning_face:

EDIT: Blockiert durch #200

EDIT2: Für alle anderen, die noch Ubuntu 18.04 verwenden, hier ist ein Build von RPi Imager 1.6.1 nach Anwendung des Patches von #200
Nutzung auf eigene Gefahr: rpi-imager_1.6.1_amd64.zip
(Fühlen Sie sich frei, dieses @maxnet zu löschen, wenn Sie es für unangemessen halten)

https://www.raspberrypi.org/documentation/installation/installing-images/README.md sagt auch "Ubuntu 18.04" :wink:

Wenn also RPi Imager Ubuntu 18.04 in Zukunft definitiv nicht mehr unterstützen wird, sollten wir diese Dokumentation wohl auch aktualisieren? :zucken:

Also, wenn RPi Imager Ubuntu 18.04 definitiv nicht mehr unterstützt

Nicht sicher, was die offizielle Support-Richtlinie ist.

Beachten Sie jedoch, dass die allgemeine Nützlichkeit von Ubuntu 18 für Entwickler rapide abnimmt.

• Nicht mehr für die Webentwicklung verwendbar, da die mitgelieferte PHP-Version älter ist, als moderne Frameworks akzeptieren.
• Nicht verwendbar für Low-Level-C-Entwicklung. Wenn Sie zB mit dem Raspberry Pico spielen wollen, werden Sie feststellen, dass CMake zu alt ist.
• Die Qt-Version unterstützt eine Reihe neuerer Methoden nicht. Und wenn Sie eine neuere Qt-Version auf anderen Plattformen verwenden, werden Sie sehen, dass es eine Menge "veralteter" Methodenwarnungen auswirft, wenn Sie dort die älteren Methoden verwenden.

Und Ubuntu 20 LTS ist seit einem Jahr draußen.

Was ist der Grund, warum Sie immer noch 18 verwenden?

Was ist der Grund, warum Sie immer noch 18 verwenden?

Ich habe vor etwas mehr als einem Jahr einen neuen Dell XPS-Laptop gekauft, auf dem Ubuntu 18.04 vorinstalliert war, und ich zögere, ihn auf eine neuere Version zu aktualisieren, zumal es sich immer noch um eine aktiv unterstützte LTS-Version handelt. Auch das Ausführen eines älteren, aber immer noch unterstützten Betriebssystems ist nützlich, um Grenzfälle wie diesen aufzudecken :wink:
Für Pico-Zeug habe ich mit https://apt.kitware.com/ auf eine neuere Version von CMake aktualisiert. Und wenn ich eine neuere GCC-Version verwenden muss, stelle ich einfach mein lokales Installationsverzeichnis $PATH voran. Für alles andere gibt es VirtualBox.

LTS-Releases sind „Enterprise-Grade“ und auf Stabilität ausgerichtet. Sie sind für diejenigen, die keine neuen Softwareversionen wollen. Die Software-Updates, die Sie für LTS-Releases erhalten, sind nur Sicherheits- und Fehlerbehebungen. Die Unterstützung alter Software ist nicht kostenlos, es erfordert Arbeit und schränkt Ihre Möglichkeiten ein, voranzukommen. Es ist nicht vernünftig zu erwarten, dass ein altes LTS ein Jahr nach der Veröffentlichung des aktuellen eine unterstützte Plattform bleibt.

Sie sind für diejenigen, die keine neuen Softwareversionen wollen.

Ja, das ist eine vernünftige Position; Ich hätte kein Problem damit, dass zB RPi Imager 1.7.x nur Ubuntu 20.04+ unterstützt, wobei Ubuntu 18.04 auf den älteren RPi Imager 1.6.x beschränkt ist. Es kam mir nur komisch vor, dass der Kompatibilitätsbruch beim Wechsel von 1.6.0 auf 1.6.1 passiert ist
Angesichts der Benutzerebene, auf die sich die Raspberry Pi-Website richtet, ist es unwahrscheinlich, dass die Website sowohl für „Ubuntu 20.04+-Benutzer“ als auch für „Ubuntu 18.04-Benutzer“ unterschiedliche Download-Optionen anbietet, weshalb ich das vorgeschlagen habe Wann/falls die Entscheidung fällt, die Unterstützung für 18.04 einzustellen, muss dies ausdrücklich in der Dokumentation erwähnt werden.

:mann_achselzuckend:

Es kam mir nur komisch vor, dass der Kompatibilitätsbruch beim Wechsel von 1.6.0 auf 1.6.1 passiert ist

Ich stimme zu, dass es seltsam ist, dass dies bei einer Punktveröffentlichung stillschweigend geschieht. Das sollte zumindest dem 1.6.1 Changelog hinzugefügt werden. Aber weißt du ... es gibt eine einjährige Gnadenfrist! Wenn es Sie interessiert, mein XPS (13) läuft perfekt mit 20.04 :)

Unabhängig von Problemen mit Snap-Paketen denke ich immer noch, dass das von https://www.raspberrypi.org/software/ herunterladbare imager_1.6.1_amd64.deb auf Ubuntu 18.04 (das noch bis April 2023 unterstützt wird) installierbar sein sollte.
leicht_stirnrunzelndes_gesicht

~EDIT: Blockiert durch #200~

EDIT2: Für alle anderen, die noch Ubuntu 18.04 verwenden, hier ist ein Build von RPi Imager 1.6.1 nach Anwendung des Patches von #200
Nutzung auf eigene Gefahr: rpi-imager_1.6.1_amd64.zip
(Fühlen Sie sich frei, dieses @maxnet zu löschen, wenn Sie es für unangemessen halten)

Vielen Dank. hat für mich an Debian Buster gearbeitet, während der ursprüngliche Download und Snap fehlgeschlagen sind

Nur zur Info, dass dies auch unter ChromeOS ein Problem ist. Wenn Sie den Linux-Entwicklermodus aktiviert haben, funktioniert 1.6.1 von @lurch freigegeben , während der Download von https://www.raspberrypi.org/software/ nicht funktioniert.

Zum Nutzen aller, die dieses Problem verfolgen ...

Ich habe gerade versucht, das v1.6.2-Tag auf Ubuntu 18.04 zu kompilieren, und es kann nicht erstellt werden mit:

rpi-imager/main.cpp:250:19: error: ‘class QApplication’ has no member named ‘screenAt’; did you mean ‘screens’?
         if ( !app.screenAt(QPoint(x,y)) || !app.screenAt(QPoint(x+w,y+h)) )
                   ^~~~~~~~
                   screens
rpi-imager/main.cpp:250:49: error: ‘class QApplication’ has no member named ‘screenAt’; did you mean ‘screens’?
         if ( !app.screenAt(QPoint(x,y)) || !app.screenAt(QPoint(x+w,y+h)) )
                                                 ^~~~~~~~
                                                 screens

weil diese Funktion in Qt 5.10 hinzugefügt wurde, aber Ubuntu 18.04 nur Qt 5.9.5 enthält.
Es sieht also so aus, als wäre mein Build von v1.6.1 für Benutzer von Ubuntu 18.04 "end of the line" :wink:

Sie sind für diejenigen, die keine neuen Softwareversionen wollen.

Nein. Ich verwende LTS, weil ein Upgrade oder die Installation einer neuen Version sehr viel Zeit in Anspruch nimmt. Nach der Installation muss viel modifiziert/optimiert, installiert, eingerichtet usw. werden. Das kostet viel Zeit. Das LTS bietet die Möglichkeit, ein System über einen viel längeren Zeitraum zu nutzen. Ab meinem aktuellen 18.04 werde ich Ubuntu nicht mehr verwenden (aber das ist eine andere Geschichte).

Ich verwende mehrere PPAs + einige Appimages. Dinge wie PHP installiere ich selbst.

Ich fürchte, 20.04 LTS ist ein neues Minimum, weil ich darauf aktualisiert habe. :-)

Ich glaube, dass dieser ganzen „18.04 zu alt“-Diskussion ein riesiges, tieferes Problem mit dem Projekt fehlt: Warum ist der Build-Prozess an Ihre spezielle Version gebunden? Kompilieren und veröffentlichen Sie es _selbst_? Verfügt rpi-imager nicht über eine CI-, PPA-, Github-Aktion oder ein ähnliches Tool für einen Cloud-Build-Workflow?

Solange _dass_ Tool 18.04 unterstützt (und die Quellen kompatibel sind), sollte das persönliche Betriebssystem von @maxnet irrelevant sein. Ein PPA kann für _alle_ aktuellen Ubuntu-Versionen erstellt werden. Travis-CI und Github können für viele Plattformen bauen. Sie können sogar Windows für die Entwicklung verwenden und die Cloud für Fedora, Mac, BSD, ARM erstellen lassen, egal wie alt oder modern die Plattform ist.

Das gesagt...

Solange dieses Tool 18.04 unterstützt (und die Quellen kompatibel sind)

1) Quellen werden in Zukunft ohne #ifdef-Magie nicht kompatibel sein.
Neuere Methoden gibt es in alten Qt-Versionen nicht.
Die Verwendung der älteren Methoden gibt bei neueren Qt 5-Versionen eine Reihe veralteter Warnungen aus und verschwindet in Qt 6

2) Dies ist eine Anwendung, die zumindest unter Windows und Mac OS X Code-signiert werden muss, und ich bin kein großer Fan davon, Code-Signaturschlüssel mit Cloud-Anbietern zu teilen.

3) Würde immer noch eine Installation jedes Betriebssystems benötigen, um testen zu können, ob das Ergebnis korrekt funktioniert.
Diese Art von Software (mit Interaktion mit Systemdiensten und physischer Hardware wie SD-Kartenlesern) ist nicht so gut für automatisierte Testframeworks geeignet ...

Und Ubuntu 20 LTS ist seit einem Jahr draußen.

Und Ubuntu 18 wird noch zwei ganze Jahre lang unterstützt. Dein Punkt?

Beachten Sie jedoch, dass die allgemeine Nützlichkeit von Ubuntu 18 für Entwickler rapide abnimmt.
...
Was ist der Grund, warum Sie immer noch 18 verwenden?

Das ist ... nicht , wie man mit diesem Problem umgeht. Die besonderen Gründe von @lurch für die Verwendung von 18 sollten keine Rolle spielen. Es gibt viele. Da musste man bei Ihnen auf den 20.04 wechseln, während manche schon auf den 21.10 sprangen.

Es ist nicht vernünftig zu erwarten, dass ein altes LTS ein Jahr nach der Veröffentlichung des aktuellen eine unterstützte Plattform bleibt.

Es ist. Es heißt nicht umsonst LTS ! _Langfristige_ Unterstützung .

Es gibt ein Jahr Gnadenfrist!

Falsch. Die „Jahresschonfrist“ wird erst im April 2022 _beginnen_, wo wir _dann_ ein ganzes Jahr bis _2023_ Zeit haben, um auf Ubuntu 22.04 zu migrieren, wobei 20.04 vollständig übersprungen wird, während wir immer noch ein vollständig unterstütztes System verwenden. Ich möchte _wirklich_ nicht den Aufwand haben, alle 2 Jahre das gesamte Betriebssystem zu aktualisieren

Kommt schon Leute... Ubuntu hat gerade Raspberry vollständig angenommen und veröffentlicht nicht nur eine Server-Edition, sondern auch Desktop, Core, die ganze Familie. Sie haben alle Raspberry-spezifischen Pakete zu ihren Repositories hinzugefügt, es werden keine PPAs mehr für rpi-eeprom oder vcgencmd benötigt.

Bitte unterstützen Sie es auch voll und ganz für eine lange und glückliche Ehe :1st_place_medal:

Und Ubuntu 18 wird noch zwei ganze Jahre lang unterstützt. Dein Punkt?

„Unterstützt“ bedeutet nicht, dass Sie neuere Softwareversionen erhalten.
Alles auf einem Ubuntu 18-System ist die Softwareversion 2018, wobei nur Stabilitäts- und Sicherheitsfixes später als Backports hinzugefügt werden.
Sie können immer noch ältere Versionen von Imager darauf ausführen, um sie an den Rest des Systems anzupassen.

1. Dies ist eine Anwendung, die zumindest unter Windows und Mac OS X Code-signiert werden muss, und ich bin kein großer Fan davon, Code-Signaturschlüssel mit Cloud-Anbietern zu teilen.

Bietet Ihnen Raspberry (das Unternehmen / die Organisation) keine _irgendeine_ Infrastruktur oder Anleitung dazu? Ich meine ... IMHO ist rpi_imager eine Schlüsselkomponente im Ökosystem von Raspi. Es ist der _Einstiegspunkt_, es zu benutzen. Es wird auf den offiziellen Websites von _sowohl_ Raspberry als auch Ubuntu als empfohlener Imager präsentiert.

Nicht sicher, was die offizielle Support-Richtlinie ist.

Angesichts des hohen Bekanntheitsgrades dieses Projekts bin ich wirklich überrascht, dass es keine offizielle Richtlinie dazu gibt.

„Unterstützt“ bedeutet nicht, dass Sie neuere Softwareversionen erhalten. Alles auf einem Ubuntu 18-System ist die Softwareversion 2018, wobei nur Stabilitäts- und Sicherheitsfixes später als Backports hinzugefügt werden.

Fairer Punkt, und ich stimme zu. Es macht mir nichts aus, eine veraltete Version zu verwenden, solange meine _aktuelle_ Version weiterhin funktioniert. Und das ist hier nicht passiert.

rpi-imager , installiert von snap , ist gestern aus heiterem Himmel _pleite_ geworden. Es funktionierte nicht mehr, mit den gleichen dmesg Fehlern zu AppArmor Profilen und ausgeblendeten Laufwerken wie @lurch berichtete, was mich hierher führte. Warum wurde eine inkompatible Version auf die 18.04-Kanäle hochgeladen?

Fairer Punkt, und ich stimme zu. Ich habe nichts dagegen, eine veraltete Version zu verwenden

Dann können Sie die ältere 1.6.0 ausprobieren: https://downloads.raspberrypi.org/imager/imager_1.6_amd64.deb

rpi-imager, installiert von snap, brach gerade aus heiterem Himmel aus

Snap-Probleme können hier gemeldet werden: https://github.com/popey/imager-snap/issues
An dieser Version sind wir nicht beteiligt.

Einige möglicherweise relevante Klarstellungen:

rpi-imager , installiert von snap , ist gestern aus heiterem Himmel _pleite_ geworden.

Vielleicht ist es früher kaputt gegangen. Ich habe es regelmäßig für Motten verwendet, aber immer das gleiche (gecachte) Bild. Gestern habe ich ein paar neue ausprobiert, vielleicht ist das Problem deshalb erst jetzt aufgetreten. Installierte Version ist 1.6.2, und IIRC ist es seit mindestens ein paar Wochen.

Ich habe nichts dagegen, eine veraltete Version zu verwenden

Es ist nicht so, dass es mir egal wäre. Ich mache. Aber ich bin mir bewusst, dass ich zu nichts _berechtigt_ bin. Ich wünschte nur, einige Projekte würden einen konservativeren Ansatz verfolgen, wenn es darum geht, neue APIs zu übernehmen, die ältere (aber immer noch nicht EOL-)Versionen beschädigen könnten.

Ich zum Beispiel mache viel Python-Entwicklung und stehe oft vor dem gleichen Dilemma: Wenn es in Python 3.9 ein neues, großartiges Feature gibt, verwende ich es nicht, selbst wenn ich bereits bei Python 3.11 bin, weil ältere Distributionen es mögen CentoOS wird immer noch mit dem alten 3.6 ausgeliefert. Zumindest haben sie 3.8 _verfügbar_, also kann ich meine minimale Quellversion darauf erhöhen. Kann man hier ähnlich vorgehen?

Wenn ich tiefer in die Protokolle eintauche, glaube ich, dass wir es hier mit zwei verschiedenen, unabhängigen Problemen zu tun haben:

• Irgendwie bin ich (und war es immer) in der Lage, nicht nur 1.6.1, sondern 1.6.2 von Snap aus zu installieren und zu starten. Was auch immer @popey getan hat, um es für 18.04 zu kompilieren, hat funktioniert, Glückwunsch! Dies deutet darauf hin, dass meine Fehler bezüglich AppArmor beim Schreiben von Bildern nichts mit Paketabhängigkeiten oder QT-Kompilierungsproblemen beim Erstellen von .deb zu tun haben (um die es bei _diesem_ Problem anscheinend geht), obwohl sich beide in 18.04 manifestieren

• Bei meinem Problem, und anscheinend auch bei @XECDesign , geht es um _permissions_, und es sieht so aus, als wäre dies ein reines Snap-Problem . Also werde ich mich wie angewiesen dorthin bewegen.

Für alle, die hierher kommen und Probleme wie _„Eine AppArmor-Richtlinie hindert diesen Absender daran, diese Nachricht zu senden …“_, _„Netzwerk-Socket konnte nicht geöffnet werden“_ oder _„Vorgang nicht zulässig“_ haben, gehen Sie zu dieser Ausgabe , nicht hier. Es gibt nur viele Probleme mit 18.04 im Titel :-)

in der Lage, nicht nur 1.6.1, sondern 1.6.2 von Snap aus zu installieren und zu starten. Was auch immer @popey getan hat, um es für 18.04 zu kompilieren, hat funktioniert, Glückwunsch!

Ich denke, Snap ist ein "in sich geschlossenes" Verpackungsformat? Es ist also wahrscheinlich möglich, eine neuere Version der Qt-Bibliotheken einzuschließen, als sie in Ubuntu 18.04 enthalten sind? (was die .deb Version von RPi Imager verwenden müsste)

Snap-Probleme können hier gemeldet werden: https://github.com/popey/imager-snap/issues
An dieser Version sind wir nicht beteiligt.

@maxnet Wir scheinen einige Problemmeldungen über die Snap-Version von RPi Imager zu erhalten (wahrscheinlich, weil das die Version ist, die Ubuntus "Software Store" installiert), gegen die wir offensichtlich nichts unternehmen können. Vielleicht lohnt es sich, die Issue-Template-Funktion von GitHub zu nutzen, um Leute, die Probleme mit der Snap-Version von RPi Imager haben, direkt zu Popeys Repo zu leiten? :zucken:

Die ältere Version 1.6.0 (referenziert von @maxnet) installierte sich gut auf Linux Mint 19.3 (bionic repo). Vielen Dank