Rpi-imager: RPi Imager 1.6.1 (y superior) no se puede instalar en Ubuntu 18.04

Me temo que 20.04 LTS es un mínimo nuevo, porque lo actualicé. :-)
Sin embargo, aún debería poder ejecutar "debuild" desde git usted mismo.

Estoy seguro de que no puedo ser la única persona que sigue ejecutando Ubuntu 18.04 :wink: Y aunque puedo ejecutar debuild, estoy seguro de que hay muchos usuarios menos técnicos que no pueden.
¿Podría construir dentro de una máquina virtual o algo así?

Mantengo un complemento de rpi-imager, y acabo de actualizarlo para compilarlo en Ubuntu 20.04, pero se puede instalar en Ubuntu 18.04 (de hecho, incluso en 14.04 y 16.04) y otras distribuciones también.

Como un punto de datos interesante sobre "¿quién todavía ejecuta 18.04?" pregunta, todavía hay un buen número en él. Entre los usuarios de RPI Imager snap, ~13% están en Ubuntu 18.04, con ~56% en 20.04 e incluso ~2.7% en Ubuntu 16.04.

A menos que se haya resuelto https://github.com/popey/imager-snap/issues/8 , lamentablemente el complemento no es compatible con el conjunto completo de funciones de Imager. IIRC, también debe habilitar algunos permisos adicionales para evitar otros errores. No es obvio que necesitas hacer eso o cómo hacerlo. Dado que el generador de imágenes está destinado a simplificar las cosas, el complemento parece presentar obstáculos.

Idealmente, sería genial en los repositorios apt normales.

A menos que se haya resuelto popey/imager-snap#8

¿Funciona mejor en 1.6.1?

Se coló en una confirmación ( https://github.com/raspberrypi/rpi-imager/commit/c8409d741939c0af32180c731a86adcdeaba802d ) que puede solucionarlo, pero no tuvo tiempo de averiguar cómo crear un complemento para probarlo.

Anteriormente, el código asumía que tan pronto como udisks2 (al que hablamos a través de DBus) nos decía que el volumen extraíble (partición FAT32) estaba montado, podíamos escribir en la carpeta de montaje.
Pero es posible que aún no esté montado dentro del snap chroot en ese punto, que parece estar rezagado.
Por lo tanto, realice una verificación que verifique que la carpeta de montaje sea un punto de montaje y que se retrase hasta 3 segundos si no lo es.

Acabo de probarlo y no, parece ser peor. Al principio decía que no podía montar la partición, así que habilité el permiso correspondiente. Mismo error, así que habilité todos los permisos que estaban deshabilitados (aunque sus descripciones no parecían relevantes) (PEBCAK). Ahora, el generador de imágenes se comporta como si todo hubiera ido bien, pero la tarjeta SD está en blanco al final.

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

En general, no es la experiencia que le gustaría que tuviera cualquier usuario.

No se puede crear 'README.txt'

¿El usuario no puede escribir en /var/lib/snapd/hostfs/media/shift/F28E-8BF1?

¿Movemos esto a https://github.com/popey/imager-snap/issues/8?

Independientemente de cualquier problema con los paquetes Snap, sigo pensando que el imager_1.6.1_amd64.deb descargable desde https://www.raspberrypi.org/software/ debería poder instalarse en Ubuntu 18.04 (que aún es compatible hasta abril de 2023).
:slightly_frowning_face:

EDITAR: Bloqueado por # 200

EDIT2: Para cualquier otra persona que aún use Ubuntu 18.04, aquí hay una compilación de RPi Imager 1.6.1 después de aplicar el parche del n. ° 200
Use bajo su propio riesgo: rpi-imager_1.6.1_amd64.zip
(no dude en eliminar este @maxnet si cree que es inapropiado)

https://www.raspberrypi.org/documentation/installation/installing-images/README.md también dice "Ubuntu 18.04" :wink:

Entonces, si RPi Imager definitivamente no admitirá Ubuntu 18.04 en el futuro, ¿supongo que también deberíamos actualizar esa documentación? :encogimiento de hombros:

Entonces, si RPi Imager definitivamente no admitirá Ubuntu 18.04 en el futuro

No estoy seguro de cuál es la política de soporte oficial.

Solo tenga en cuenta que la utilidad general de Ubuntu 18 para los desarrolladores está disminuyendo rápidamente.

• Ya no se puede utilizar para el desarrollo web, ya que la versión de PHP con la que se envía es más antigua de lo que aceptan los marcos modernos.
• No se puede utilizar para el desarrollo de C de bajo nivel. Por ejemplo, si quiere jugar con, por ejemplo, Raspberry Pico, descubrirá que CMake es demasiado antiguo.
• La versión Qt no admite muchos métodos más nuevos. Y si usa una versión más nueva de Qt en otras plataformas, verá que arroja una gran cantidad de advertencias de métodos "obsoletos" si usa los métodos más antiguos allí.

Y Ubuntu 20 LTS salió hace un año.

¿Cuál es la razón por la que sigues usando 18?

¿Cuál es la razón por la que sigues usando 18?

Compré una nueva computadora portátil Dell XPS hace poco más de un año que venía con Ubuntu 18.04 preinstalado, y soy reacio a intentar actualizarla a una versión más nueva, especialmente porque todavía es una versión LTS con soporte activo. Además, ejecutar un sistema operativo más antiguo pero aún compatible es útil para descubrir casos extremos como este: guiño:
Para cosas de Pico, actualicé a una versión más nueva de CMake usando https://apt.kitware.com/ Y cuando necesito usar una versión más nueva de GCC, simplemente antepongo mi directorio de instalación local a $PATH. Para cualquier otra cosa, está VirtualBox.

Los lanzamientos de LTS son de "grado empresarial" y se centran en la estabilidad. Son para aquellos que _no_ quieren nuevas versiones de software. Las actualizaciones de software que obtiene para las versiones LTS son solo correcciones de seguridad y errores. La compatibilidad con el software antiguo no es gratuita, requiere trabajo y limita su capacidad para avanzar. No es razonable esperar que una antigua LTS siga siendo una plataforma compatible un año después del lanzamiento de la actual.

Son para aquellos que _no_ quieren nuevas versiones de software.

Sí, esa es una posición razonable a tomar; No tendría ningún problema con, por ejemplo, RPi Imager 1.7.x solo compatible con Ubuntu 20.04+, con Ubuntu 18.04 restringido al antiguo RPi Imager 1.6.x. Me pareció extraño que la interrupción de la compatibilidad ocurriera en el cambio de 1.6.0 a 1.6.1
Además, dado el nivel de usuario al que está dirigido el sitio web de Raspberry Pi, supongo que es poco probable que el sitio web ofrezca diferentes opciones de descarga tanto para "usuarios de Ubuntu 20.04+" como para "usuarios de Ubuntu 18.04", razón por la cual estaba sugiriendo que cuando/si se toma la decisión de retirar el soporte para 18.04, debe mencionarse específicamente en la documentación.

:hombre_encogiéndose de hombros:

Me pareció extraño que la interrupción de la compatibilidad ocurriera en el cambio de 1.6.0 a 1.6.1

Estoy de acuerdo en que es extraño que eso suceda silenciosamente en un lanzamiento puntual. Eso debería al menos agregarse al registro de cambios 1.6.1. Pero ya sabes... ¡ha habido un período de gracia de un año! Si te interesa, mi XPS (13) ejecuta 20.04 perfectamente :)

Independientemente de cualquier problema con los paquetes Snap, sigo pensando que el imager_1.6.1_amd64.deb descargable desde https://www.raspberrypi.org/software/ debería poder instalarse en Ubuntu 18.04 (que aún es compatible hasta abril de 2023).
levemente_frunciendo el ceño

~EDITAR: Bloqueado por #200~

EDIT2: Para cualquier otra persona que aún use Ubuntu 18.04, aquí hay una compilación de RPi Imager 1.6.1 después de aplicar el parche del n. ° 200
Use bajo su propio riesgo: rpi-imager_1.6.1_amd64.zip
(no dude en eliminar este @maxnet si cree que es inapropiado)

gracias. funcionó en Debian Buster para mí, mientras que la descarga original y el complemento fallaron

Solo para su información, esto también es un problema en ChromeOS. Si tiene habilitado el modo de desarrollador de Linux 1.6.1 compartido por @lurch funciona, mientras que la descarga desde https://www.raspberrypi.org/software/ no lo hace.

Para el beneficio de cualquiera que siga este problema...

Acabo de intentar compilar la etiqueta v1.6.2 en Ubuntu 18.04 y no se puede compilar con:

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

porque esa función se agregó en Qt 5.10, pero Ubuntu 18.04 solo incluye Qt 5.9.5.
Así que parece que mi compilación de v1.6.1 es "el final de la línea" para los usuarios de Ubuntu 18.04: guiño:

Son para aquellos que _no_ quieren nuevas versiones de software.

No. Uso LTS porque actualizar o instalar una nueva versión consume mucho tiempo. Después de la instalación, se debe modificar/ajustar mucho, instalar, configurar, etc. Lleva mucho tiempo. El LTS brinda la oportunidad de utilizar un sistema durante mucho más tiempo. A partir de mi 18.04 actual, ya no voy a usar Ubuntu (pero esa es otra historia).

Uso varios PPA + algunas imágenes de aplicaciones. Para cosas como PHP lo instalo yo mismo.

Me temo que 20.04 LTS es un mínimo nuevo, porque lo actualicé. :-)

Creo que a toda esta discusión sobre "18.04 demasiado antigua" le falta un problema enorme y más profundo con el proyecto: ¿por qué el proceso de compilación está vinculado a su versión en particular? ¿Está recopilando y publicando _usted mismo_? ¿ rpi-imager tiene una acción de CI, PPA, Github o alguna herramienta similar para un flujo de trabajo de compilación en la nube?

Siempre que _esa_ herramienta sea compatible con 18.04 (y las fuentes sean compatibles), el sistema operativo personal de @maxnet debería ser irrelevante. Un PPA puede compilarse para _todas_ las versiones actuales de Ubuntu. Travis-CI y Github pueden compilar para muchas plataformas. Incluso puede usar Windows para el desarrollo y dejar que la nube se construya para Fedora, Mac, BSD, ARM, sin importar qué tan antigua o avanzada sea la plataforma.

Dicho esto...

Siempre que esa herramienta sea compatible con 18.04 (y las fuentes sean compatibles)

1) Las fuentes no serán compatibles en el futuro sin la magia de #ifdef.
Los métodos más nuevos no existen en las versiones antiguas de Qt.
El uso de los métodos más antiguos genera un montón de advertencias obsoletas en las versiones más nuevas de Qt 5, y desaparecerá en Qt 6

2) Esta es una aplicación que debe estar firmada con código al menos en Windows y Mac OS X y no soy un gran fanático de compartir claves de firma de código con proveedores de la nube.

3) Todavía necesitaría una instalación de cada sistema operativo para poder probar si el resultado funciona correctamente.
Este tipo de software (con interacción con los servicios del sistema y hardware físico como lectores de tarjetas SD) no es tan adecuado para marcos de prueba automatizados...

Y Ubuntu 20 LTS salió hace un año.

Y Ubuntu 18 todavía es compatible durante más de dos años completos. ¿Tu punto?

Solo tenga en cuenta que la utilidad general de Ubuntu 18 para los desarrolladores está disminuyendo rápidamente.
...
¿Cuál es la razón por la que sigues usando 18?

Eso... no es cómo manejar este problema. Las razones particulares de @lurch para usar 18 no deberían importar. Hay muchos. Como tuviste la tuya de cambiar al 20.04, mientras que algunos ya saltaron al 21.10.

No es razonable esperar que una antigua LTS siga siendo una plataforma compatible un año después del lanzamiento de la actual.

Está. ¡Se llama LTS por una razón! _Apoyo a largo plazo .

ha habido un año de período de gracia!

Falso. El "período de gracia del año" solo _comenzará_ en abril de 2022 , donde _entonces_ tendremos un año completo hasta el _2023_ para migrar a Ubuntu 22.04, omitiendo por completo 20.04, mientras seguimos utilizando un sistema totalmente compatible. Realmente no quiero la molestia de actualizar todo el sistema operativo cada 2 años

Vamos chicos... Ubuntu acaba de abrazar completamente a Raspberry, lanzando no solo una edición de servidor sino también Desktop, Core, toda la familia. Agregaron todos los paquetes específicos de Raspberry a sus repositorios, no se necesitaron más PPA para rpi-eeprom o vcgencmd .

Por favor, apóyelo también por completo para un matrimonio largo y feliz: 1st_place_medal:

Y Ubuntu 18 todavía es compatible durante más de dos años completos. ¿Tu punto?

"Compatible" no significa que pueda tener versiones más nuevas del software.
Todo en un sistema Ubuntu 18 es la versión 2018 del software, con solo correcciones de estabilidad y seguridad agregadas como backports más adelante.
Todavía puede ejecutar versiones anteriores de Imager en él, para que coincida con el resto del sistema.

1. Esta es una aplicación que debe estar firmada con código al menos en Windows y Mac OS X y no soy un gran fanático de compartir claves de firma de código con proveedores de la nube.

¿Frambuesa (la empresa/organización) no le proporciona _alguna_ infraestructura u orientación sobre esto? Quiero decir... En mi humilde opinión rpi_imager es un componente clave en el ecosistema de Raspi. Es el mismo _punto de entrada_ para usarlo. Se muestra en los sitios web oficiales de _tanto_ Raspberry como de Ubuntu como generador de imágenes respaldado.

No estoy seguro de cuál es la política de soporte oficial.

Dado el alto perfil de este proyecto, estoy realmente sorprendido de que no haya una política oficial al respecto.

"Compatible" no significa que pueda tener versiones más nuevas del software. Todo en un sistema Ubuntu 18 es la versión 2018 del software, con solo correcciones de estabilidad y seguridad agregadas como backports más adelante.

Punto justo, y estoy de acuerdo. No me importa usar una versión desactualizada, siempre y cuando mi versión _actual_ siga funcionando. Y eso no es lo que pasó aquí.

rpi-imager , instalado desde snap , acaba de _romper_ de la nada, ayer. Dejó de funcionar, con los mismos errores de AppArmor dmesg los perfiles de AppArmor y las unidades en blanco que informó @lurch , lo que me llevó aquí. ¿Por qué se subió una versión incompatible a los canales 18.04?

Punto justo, y estoy de acuerdo. No me importa usar una versión desactualizada

Luego puede probar el 1.6.0 anterior: https://downloads.raspberrypi.org/imager/imager_1.6_amd64.deb

rpi-imager, instalado desde snap, acaba de aparecer de la nada

Los problemas de Snap se pueden informar aquí: https://github.com/popey/imager-snap/issues
No estamos involucrados con esa versión.

Algunas aclaraciones posiblemente relevantes:

rpi-imager , instalado desde snap , acaba de _romper_ de la nada, ayer.

Tal vez se rompió antes. Lo he estado usando regularmente durante polillas, pero siempre usando la misma imagen (en caché). Ayer probé algunos nuevos, así que tal vez por eso recién ahora se manifestó el problema. La versión instalada es 1.6.2, y IIRC lo ha sido durante al menos algunas semanas.

No me importa usar una versión desactualizada

No es que no me importe. Hago. Pero soy consciente de que no tengo derecho a nada. Solo deseaba que algunos proyectos adoptaran un enfoque más conservador cuando se trata de adoptar una nueva API que podría romper versiones anteriores (pero aún no terminadas).

Yo, por ejemplo, realizo mucho desarrollo en Python y enfrento muchas veces el mismo dilema: si hay una característica nueva y hermosa en Python 3.9, me abstengo de usarla incluso si ya estoy en Python 3.11, porque las distribuciones más antiguas como CentoOS todavía se envía con la versión antigua 3.6 . Al menos tienen 3.8 _disponible_, por lo que puedo aumentar mi versión de fuente mínima a esa. ¿Se puede adoptar un enfoque similar aquí?

Profundizando en los registros, creo que estamos lidiando con 2 problemas distintos e independientes aquí:

• De alguna manera soy (y siempre he sido) capaz de instalar y ejecutar no solo 1.6.1 sino 1.6.2 desde snap. Así que lo que hizo @popey para compilarlo para 18.04 funcionó, ¡felicidades! Esto sugiere que mis errores sobre AppArmor al escribir imágenes no tienen nada que ver con dependencias de paquetes o problemas de compilación QT al compilar .deb (de lo que parece tratarse _este_ problema), aunque ambos se manifiestan en 18.04

• Mi problema, y ​​parece que @XECDesign también, se trata de _permisos_, y parece que este es un problema de solo complemento . Así que me mudaré allí según las instrucciones.

Para cualquiera que venga aquí con problemas como _"Una política de AppArmor impide que este remitente envíe este mensaje..."_, _"No se pudo abrir el socket de red"_ o _"Operación no permitida"_, vaya a este problema , aqui no. Es solo que hay muchos problemas con 18.04 en su título :-)

capaz de instalar y ejecutar no solo 1.6.1 sino 1.6.2 desde snap. Así que lo que hizo @popey para compilarlo para 18.04 funcionó, ¡felicidades!

¿Creo que Snap es un formato de empaque "autónomo"? Entonces, ¿probablemente pueda incluir una versión más nueva de las bibliotecas Qt que las que se incluyen con Ubuntu 18.04? (que necesitaría usar la versión .deb de RPi Imager)

Los problemas de Snap se pueden informar aquí: https://github.com/popey/imager-snap/issues
No estamos involucrados con esa versión.

@maxnet Parece que recibimos bastantes informes de problemas sobre la versión instantánea de RPi Imager (probablemente porque esa es la versión que instala la "tienda de software" de Ubuntu), que obviamente no podemos hacer nada al respecto. ¿Tal vez valga la pena hacer uso de la función de plantilla de problemas de GitHub para dirigir a las personas que tienen problemas con la versión instantánea de RPi Imager directamente al repositorio de popey ? :encogimiento de hombros:

La versión anterior 1.6.0 (referenciada por @maxnet) se instaló bien en Linux Mint 19.3 (repositorio biónico). Gracias