Rpi-imager: RPi Imager 1.6.1 (и выше) не может быть установлен на Ubuntu 18.04

Боюсь, 20.04 LTS — это новый минимум, потому что я обновился до него. :-)
Тем не менее, вы все равно должны иметь возможность запускать «отладку» из git самостоятельно.

Я уверен, что я не могу быть единственным, кто до сих пор использует Ubuntu 18.04 :wink: И хотя я могу запускать debuild, я уверен, что есть много менее технических пользователей, которые не могут?
Не могли бы вы построить внутри виртуальной машины или что-то в этом роде?

Я поддерживаю оснастку rpi-imager и только что настроил ее для сборки на Ubuntu 20.04, но ее можно установить на Ubuntu 18.04 (на самом деле даже 14.04 и 16.04), а также на другие дистрибутивы.

В качестве интересной точки данных о том, «кто все еще использует 18.04?» вопрос, есть еще справедливое число на нем. Среди пользователей снимков RPI Imager ~ 13% используют Ubuntu 18.04, ~ 56% — 20.04 и даже ~ 2,7% — Ubuntu 16.04!

Если https://github.com/popey/imager-snap/issues/8 не был разрешен, к сожалению, снимок не поддерживает полный набор функций Imager. IIRC, вам также необходимо включить некоторые дополнительные разрешения, чтобы предотвратить другие ошибки. Не очевидно, что вам нужно сделать это или как это сделать. Учитывая, что имидж-сканер предназначен для упрощения, Snap, кажется, создает препятствия.

В идеале было бы здорово использовать его в обычных репозиториях apt.

Если popey/imager-snap#8 не был разрешен

На 1.6.1 работает лучше?

Пробрался в фиксацию ( https://github.com/raspberrypi/rpi-imager/commit/c8409d741939c0af32180c731a86adcdeaba802d ), которая может обойти это, но не было времени выяснить, как создать снап, чтобы протестировать его.

Код ранее предполагал, что как только udisks2 (с которым мы общаемся через DBus) сообщает нам, что съемный том (раздел FAT32) смонтирован, мы можем писать в папку монтирования.
Но к этому моменту он может быть еще не смонтирован внутри snap chroot, который, похоже, отстает.
Поэтому сделайте проверку, которая проверяет, что папка монтирования является точкой монтирования, и задерживает до 3 секунд, если это не так.

Только что попробовал и нет, вроде хуже. Сначала он сказал, что не может смонтировать раздел, поэтому я включил соответствующее разрешение. Та же ошибка, поэтому я включил все разрешения, которые были отключены (хотя их описания не кажутся актуальными) (PEBCAK). Теперь имиджер ведет себя так, как будто все прошло хорошо, но SD-карта в конце пуста.

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

В целом, это не тот опыт, который вы хотели бы получить от любого пользователя.

Не удается создать «README.txt»

Является ли /var/lib/snapd/hostfs/media/shift/F28E-8BF1 недоступным для записи пользователем, запускающим Imager as?

Переместить это на https://github.com/popey/imager-snap/issues/8?

Несмотря на какие-либо проблемы с пакетами Snap, я по-прежнему считаю, что пакет imager_1.6.1_amd64.deb , загружаемый с https://www.raspberrypi.org/software/ , должен быть установлен в Ubuntu 18.04 (который все еще поддерживается до апреля 2023 года).
:slightly_frowning_face:

РЕДАКТИРОВАТЬ: заблокирован # 200

РЕДАКТИРОВАТЬ 2: Для тех, кто все еще использует Ubuntu 18.04, вот сборка RPi Imager 1.6.1 после применения патча № 200.
Используйте на свой страх и риск: rpi-imager_1.6.1_amd64.zip
(не стесняйтесь удалять этот @maxnet , если считаете его неуместным)

https://www.raspberrypi.org/documentation/installation/installing-images/README.md также говорит «Ubuntu 18.04» :wink:

Итак, если RPi Imager определенно не будет поддерживать Ubuntu 18.04 в будущем, я думаю, нам следует обновить и эту документацию? :пожимаю плечами:

Так что, если RPi Imager определенно не будет поддерживать Ubuntu 18.04 в будущем

Не уверен, какова официальная политика поддержки.

Просто имейте в виду, что общая полезность Ubuntu 18 для разработчиков быстро снижается.

• Больше не используется для веб-разработки, так как версия PHP, с которой он поставляется, старше, чем принимают современные фреймворки.
• Не подходит для разработки на низком уровне C. Например, если вы хотите поиграть, скажем, с Raspberry Pico, вы обнаружите, что CMake слишком стар.
• Версия Qt не поддерживает кучу новых методов. И если вы используете более новую версию Qt на других платформах, вы увидите, что она выдает множество предупреждений об «устаревших» методах, если вы используете там более старые методы.

И Ubuntu 20 LTS отсутствует уже год.

По какой причине вы все еще используете 18?

По какой причине вы все еще используете 18?

Чуть более года назад я купил новый ноутбук Dell XPS с предустановленной Ubuntu 18.04, и я не хочу пытаться обновить его до более новой версии, тем более что это все еще активно поддерживаемая версия LTS. Кроме того, запуск более старой, но все еще поддерживаемой ОС полезен для выявления таких крайних случаев, как этот :wink:
Для материала Pico я обновился до более новой версии CMake, используя https://apt.kitware.com/ . И когда мне нужно использовать более новую версию GCC, я просто добавляю свой локальный-установочный-каталог к ​​$PATH. Для всего остального есть VirtualBox.

Выпуски LTS относятся к корпоративному уровню и ориентированы на стабильность. Они для тех, кто _не_ хочет новые версии программного обеспечения. Обновления программного обеспечения, которые вы получаете для выпусков LTS, предназначены только для исправления ошибок и безопасности. Поддержка старого программного обеспечения не бесплатна, она требует работы и ограничивает ваши возможности двигаться вперед. Неразумно ожидать, что старая LTS останется поддерживаемой платформой через год после выпуска текущей.

Они для тех, кто _не_ хочет новые версии программного обеспечения.

Да, это разумная позиция; У меня не было бы проблем, например, с RPi Imager 1.7.x, поддерживающим только Ubuntu 20.04+, а Ubuntu 18.04 ограничен более старым RPi Imager 1.6.x. Мне просто показалось странным, что нарушение совместимости произошло при переходе с 1.6.0 на 1.6.1.
Кроме того, учитывая уровень пользователя, на который нацелен веб-сайт Raspberry Pi, я думаю, маловероятно, что веб-сайт будет предлагать разные варианты загрузки как для «пользователей Ubuntu 20.04+», так и для «пользователей Ubuntu 18.04», поэтому я и предполагал, что когда/если будет принято решение об отказе от поддержки 18.04, это должно быть специально указано в документации.

:man_пожимая плечами:

Мне просто показалось странным, что нарушение совместимости произошло при переходе с 1.6.0 на 1.6.1.

Я согласен, что это странно, что это происходит молча при выпуске точки. По крайней мере, это должно быть добавлено в журнал изменений 1.6.1. Но вы знаете... был год льготного периода! Если вам интересно, мой XPS (13) отлично работает с 20.04 :)

Несмотря на какие-либо проблемы с пакетами Snap, я по-прежнему считаю, что пакет imager_1.6.1_amd64.deb , загружаемый с https://www.raspberrypi.org/software/ , должен быть установлен в Ubuntu 18.04 (который все еще поддерживается до апреля 2023 года).
слегка_хмурое_лицо

~ РЕДАКТИРОВАТЬ: заблокирован # 200 ~

РЕДАКТИРОВАТЬ 2: Для тех, кто все еще использует Ubuntu 18.04, вот сборка RPi Imager 1.6.1 после применения патча № 200.
Используйте на свой страх и риск: rpi-imager_1.6.1_amd64.zip
(не стесняйтесь удалять этот @maxnet , если считаете его неуместным)

Спасибо. работал на Debian Buster для меня, в то время как оригинальная загрузка и привязка не удались

Просто к сведению, что это проблема и в ChromeOS. Если у вас включен режим разработчика Linux, версия 1.6.1, предоставленная @lurch , работает, а загрузка с https://www.raspberrypi.org/software/ — нет.

В интересах всех, кто следит за этой проблемой...

Я только что попытался скомпилировать тег v1.6.2 в Ubuntu 18.04, и он не смог собрать:

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

потому что эта функция была добавлена ​​в Qt 5.10, а Ubuntu 18.04 включает только Qt 5.9.5.
Так что похоже, что моя сборка v1.6.1 — это «конец линии» для пользователей Ubuntu 18.04 :wink:

Они для тех, кто _не_ хочет новые версии программного обеспечения.

Нет. Я использую LTS, потому что обновление или установка новой версии отнимает много времени. После установки многое нужно модифицировать/подправить, установить, настроить и т.д. Это занимает много времени. LTS дает возможность использовать систему гораздо дольше. С моей текущей версии 18.04 я больше не собираюсь использовать Ubuntu (но это уже другая история).

Я использую несколько PPA + некоторые изображения приложений. Для таких вещей, как PHP, я устанавливаю его сам.

Боюсь, 20.04 LTS — это новый минимум, потому что я обновился до него. :-)

Я считаю, что во всей этой дискуссии «18.04 слишком старая» отсутствует огромная, более глубокая проблема с проектом: почему процесс сборки привязан к вашей конкретной версии? Вы сами его составляете и публикуете? Разве rpi-imager не имеет действий CI, PPA, Github или любого подобного инструмента для рабочего процесса сборки в облаке?

Пока инструмент _that_ поддерживает 18.04 (и исходники совместимы), персональная ОС @maxnet не имеет значения. PPA может собираться для _всех_ текущих версий Ubuntu. Travis-CI и Github могут работать со многими платформами. Вы даже можете использовать Windows для разработки и позволить облачной сборке для Fedora, Mac, BSD, ARM, независимо от того, насколько древней или передовой является платформа.

Это сказало...

Пока этот инструмент поддерживает 18.04 (и исходники совместимы)

1) Исходники не будут совместимы в будущем без магии #ifdef.
Более новых методов не существует в старых версиях Qt.
Использование старых методов дает кучу устаревших предупреждений в более новых версиях Qt 5 и исчезнет в Qt 6.

2) Это приложение должно быть подписано кодом как минимум в Windows и Mac OS X, и я не большой поклонник обмена ключами подписи кода с облачными провайдерами.

3) По-прежнему потребуется установка каждой операционной системы, чтобы иметь возможность проверить, правильно ли работает результат.
Этот тип программного обеспечения (с взаимодействием с системными службами и физическим оборудованием, таким как устройства чтения SD-карт) не очень подходит для автоматизированных сред тестирования...

И Ubuntu 20 LTS отсутствует уже год.

А Ubuntu 18 по-прежнему поддерживается еще целых два года. Ваша точка зрения?

Просто имейте в виду, что общая полезность Ubuntu 18 для разработчиков быстро снижается.
...
По какой причине вы все еще используете 18?

Это... не то, как решать эту проблему. Конкретные причины @lurch для использования 18 не должны иметь значения. Есть много. Как у вас было свое переходить на 20.04, а некоторые уже перескакивали на 21.10.

Неразумно ожидать, что старая LTS останется поддерживаемой платформой через год после выпуска текущей.

Это. Это называется LTS не просто так! _Долгосрочная_ поддержка .

прошел год льготного периода!

Ложь. «Годовой льготный период» начнется только в апреле 2022 года, когда у нас будет _затем_ целый год до _2023_ для перехода на Ubuntu 22.04, полностью пропустив 20.04, но при этом используя полностью поддерживаемую систему. Я _действительно_ не хочу возиться с обновлением всей ОС каждые 2 года.

Давайте, ребята... Ubuntu только что полностью приняла Raspberry, выпустив не только серверную версию, но и настольную версию, ядро, все семейство. Они добавили все специфичные для Raspberry пакеты в свои репозитории, больше не требовалось PPA для rpi-eeprom или vcgencmd .

Пожалуйста, полностью поддержите его и для долгого и счастливого брака :1st_place_medal:

А Ubuntu 18 по-прежнему поддерживается еще целых два года. Ваша точка зрения?

«Поддерживается» не означает, что у вас есть более новые версии программного обеспечения.
Все в системе Ubuntu 18 — это версия программного обеспечения 2018 года, и только исправления стабильности и безопасности были добавлены позже в качестве резервных копий.
Вы по-прежнему можете запускать на нем более старые версии Imager, чтобы они соответствовали остальной системе.

1. Это приложение, которое должно быть подписано как минимум в Windows и Mac OS X, и я не большой поклонник обмена ключами для подписи кода с облачными провайдерами.

Разве Raspberry (компания/организация) не предоставляет вам _любую_ инфраструктуру или руководство по этому вопросу? Я имею в виду... IMHO rpi_imager является ключевым компонентом экосистемы Raspi. Это самая _точка входа_ его использования. Он представлен на официальных сайтах _both_ Raspberry и Ubuntu в качестве одобренного имидж-сканера.

Не уверен, какова официальная политика поддержки.

Учитывая высокий статус этого проекта, я действительно удивлен отсутствием официальной политики по этому поводу.

«Поддерживается» не означает, что у вас есть более новые версии программного обеспечения. Все в системе Ubuntu 18 — это версия программного обеспечения 2018 года, и только исправления стабильности и безопасности были добавлены позже в качестве резервных копий.

Справедливое замечание, и я согласен. Я не возражаю против использования устаревшей версии, если моя _текущая_ версия продолжает работать. И это не то, что произошло здесь.

rpi-imager , установленный с snap , вчера просто _сломался_ на ровном месте. Он перестал работать с теми же ошибками $#$2 dmesg #$ о профилях AppArmor и пустых дисках, о которых сообщил @lurch , что и привело меня сюда. Почему на каналы 18.04 была загружена несовместимая версия?

Справедливое замечание, и я согласен. Я не возражаю против использования устаревшей версии

Тогда вы можете попробовать старую версию 1.6.0: https://downloads.raspberrypi.org/imager/imager_1.6_amd64.deb .

rpi-imager, установленный из оснастки, просто вырвался на ровном месте

О проблемах со Snap можно сообщить здесь: https://github.com/popey/imager-snap/issues .
Мы не связаны с этой версией.

Некоторые, возможно, важные уточнения:

rpi-imager , установленный с snap , вчера просто _сломался_ на ровном месте.

Может порвался раньше. Я регулярно использую его для мотыльков, но всегда использую одно и то же (кешированное) изображение. Вчера пробовал новые, может поэтому только сейчас проблема проявилась. Установленная версия — 1.6.2, и IIRC была такой уже как минимум несколько недель.

Я не возражаю против использования устаревшей версии

Не то чтобы мне все равно. Я делаю. Но я знаю, что я ни на что не имею права. Я просто хотел бы, чтобы некоторые проекты использовали более консервативный подход, когда дело доходит до принятия нового API, который может сломать старые (но все еще не EOL'd) выпуски.

Я, например, много занимаюсь разработкой Python и часто сталкиваюсь с одной и той же дилеммой: если в Python 3.9 есть новая великолепная функция, я воздерживаюсь от ее использования, даже если я уже использую Python 3.11, потому что старые дистрибутивы любят CentoOS по-прежнему поставляется со старой версией 3.6 . По крайней мере, у них есть _доступная_ версия 3.8, так что я могу увеличить свою минимальную исходную версию до нее. Можно ли применить аналогичный подход здесь?

Копаясь глубже в журналы, я считаю, что здесь мы имеем дело с двумя отдельными независимыми проблемами:

• Каким-то образом мне (и всегда удавалось) установить и запустить не только 1.6.1, но и 1.6.2 из оснастки. Итак, что бы @popey ни сделал, чтобы скомпилировать его для 18.04, сработало, поздравляю! Это говорит о том, что мои ошибки в AppArmor при написании образов не имеют ничего общего с зависимостями пакетов или проблемами компиляции QT при сборке .deb (похоже, что проблема _this_ связана), хотя оба они проявляются в 18.04.

• Моя проблема, и, кажется, @XECDesign тоже, касается _permissions_, и похоже, что это проблема только для моментальных снимков. Так что я перееду туда, как велено.

Для всех, кто приходит сюда с такими проблемами, как _"Политика AppArmor запрещает этому отправителю отправлять это сообщение..."_, _"Не удалось открыть сетевой сокет"_ или _"операция не разрешена"_, перейдите к этой проблеме , не здесь. Просто с 18.04 в названии много вопросов :-)

умеет устанавливать и запускать не только 1.6.1 но и 1.6.2 из снапа. Итак, что бы @popey ни сделал, чтобы скомпилировать его для 18.04, сработало, поздравляю!

Я думаю, что snap - это "автономный" формат упаковки? Так что, вероятно, он может включать более новую версию библиотек Qt, чем включенная в Ubuntu 18.04? (который должен будет использовать .deb версия RPi Imager)

О проблемах со Snap можно сообщить здесь: https://github.com/popey/imager-snap/issues .
Мы не связаны с этой версией.

@maxnet Кажется, мы получаем довольно много сообщений о проблемах с моментальной версией RPi Imager (вероятно, потому, что это версия, которую устанавливает «магазин программного обеспечения» Ubuntu), с которой мы, очевидно, ничего не можем поделать. Может быть, стоит использовать функцию шаблона задач GitHub, чтобы направлять людей, имеющих проблемы с моментальной версией RPi Imager, непосредственно в репозиторий popey ? :пожимаю плечами:

Старая версия 1.6.0 (на которую ссылается @maxnet) хорошо устанавливается на Linux Mint 19.3 (bionic repo). Спасибо