Rpi-imager: RPi Imager 1.6.1 (and above) can't be installed on Ubuntu 18.04

Am afraid 20.04 LTS is new minimum, because I upgraded to that. :-)
Should still be able to run "debuild" from git yourself though.

I'm sure I can't be the only person still running Ubuntu 18.04 :wink: And whilst I can run debuild, I'm sure there are many less-technical users who can't?
Could you build inside a VM or something?

I maintain a snap of rpi-imager, and have just bumped it to build on Ubuntu 20.04, but it's installable on Ubuntu 18.04 (indeed even 14.04 & 16.04) and other distros too.

As an interesting datapoint on the "who still runs 18.04?" question, there's still a fair number on it. Among RPI Imager snap users, ~13% are on Ubuntu 18.04, with ~56% on 20.04 and even ~2.7% on Ubuntu 16.04!

Unless https://github.com/popey/imager-snap/issues/8 has been resolved, unfortunately the snap doesn't support the full set of Imager's features. IIRC, you also need to enable some additional permissions to prevent other errors. It's not obvious that you need to do that or how to. Given that the imager is meant to simplify things, the snap seems to introduce hurdles.

Ideally, it would be great to it in the normal apt repos instead.

Unless popey/imager-snap#8 has been resolved

Is it working any better under 1.6.1 ?

Sneaked in a commit ( https://github.com/raspberrypi/rpi-imager/commit/c8409d741939c0af32180c731a86adcdeaba802d ) that may workaround it, but didn't had time to figure out how to build a snap to test it.

Code previously assumed that as soon as udisks2 (to which we talk over DBus) told us the removable volume (FAT32 partition) is mounted, we are able to write to the mount folder.
But it may not be mounted inside the snap chroot yet by that point, which seems to lag behind.
So have a check that checks the mount folder is a mount point, and delays up to 3 seconds if it is not.

Just tried it and no, it seems to be worse. At first it said it couldn't mount the partition, so I enabled the relevant permission. Same error, so I enabled all the permissions that were disabled (although their descriptions didn't seem relevant) (PEBCAK). Now imager behaves like everything went well, but the SD card is blank at the end.

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

Overall, not the experience you'd want any user to have.

Can't create 'README.txt'

Is /var/lib/snapd/hostfs/media/shift/F28E-8BF1 not writable by the user snap runs Imager as?

Shall we move this over to https://github.com/popey/imager-snap/issues/8?

Regardless of any problems with Snap packages, I still think that the imager_1.6.1_amd64.deb downloadable from https://www.raspberrypi.org/software/ ought to be installable on Ubuntu 18.04 (which is still supported until April 2023).
:slightly_frowning_face:

EDIT: Blocked by #200

EDIT2: For anyone else still using Ubuntu 18.04, here's a build of RPi Imager 1.6.1 after applying the patch from #200
Use at your own risk: rpi-imager_1.6.1_amd64.zip
(feel free to delete this @maxnet if you feel it's inappropriate)

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

So if RPi Imager definitely won't be supporting Ubuntu 18.04 going forwards, I guess we ought to update that documentation too? :shrug:

So if RPi Imager definitely won't be supporting Ubuntu 18.04 going forwards

Not sure what the official support policy is.

Just be aware that the overall usefulness of Ubuntu 18 for developers is rapidly decreasing.

• Not usable for web development anymore, as the PHP version it ships with is older than modern frameworks accept.
• Not usable for low level C development. E.g. if you want to play with say the Raspberry Pico, you will find out that CMake is too old.
• Qt version does not support a bunch of newer methods. And if you do use a newer Qt version on other platforms, you will see it throws a load of "deprecated" method warnings if you use the older methods there.

And Ubuntu 20 LTS has been out for a year.

What is the reason you are still using 18?

What is the reason you are still using 18?

I bought a new Dell XPS laptop just over a year ago which came with Ubuntu 18.04 pre-installed, and I'm reluctant to try upgrading it to a newer version, especially as it's still an actively-supported LTS version. Also, running an older-but-still-supported OS is useful for uncovering edge cases like this :wink:
For Pico stuff, I updated to a newer version of CMake using https://apt.kitware.com/ And when I need to use a newer GCC version I just prepend my local-install-dir to $PATH. For anything else, there's VirtualBox.

LTS releases are 'enterprise grade' and focused on stability. They are for those who _don't_ want new versions of software. The software updates you get for LTS releases are security and bug fixes only. Supporting old software doesn't come for free, it takes work and it limits your ability to move forward. It's not reasonable to expect an old LTS to remain a supported platform a year after the current one is released.

They are for those who _don't_ want new versions of software.

Yeah, that's a reasonable position to take; I'd have no problem with e.g. RPi Imager 1.7.x only supporting Ubuntu 20.04+, with Ubuntu 18.04 being restricted to the older RPi Imager 1.6.x. It just felt weird to me that the compatibility-break happened in the change from 1.6.0 to 1.6.1
Also, given the level of user that the Raspberry Pi website is aimed at, I guess it's unlikely that the website would offer different download options for both "Ubuntu 20.04+ users" and "Ubuntu 18.04 users", which was why I was suggesting that when/if the decision to drop support for 18.04 happens, it needs to be specifically mentioned in the documentation.

:man_shrugging:

It just felt weird to me that the compatibility-break happened in the change from 1.6.0 to 1.6.1

I agree that it's odd for that to happen silently on a point release. That should at least be added to the 1.6.1 changelog. But you know... there's been a year grace period! If it's any interest to you, my XPS (13) runs 20.04 perfectly :)

Regardless of any problems with Snap packages, I still think that the imager_1.6.1_amd64.deb downloadable from https://www.raspberrypi.org/software/ ought to be installable on Ubuntu 18.04 (which is still supported until April 2023).
slightly_frowning_face

~EDIT: Blocked by #200~

EDIT2: For anyone else still using Ubuntu 18.04, here's a build of RPi Imager 1.6.1 after applying the patch from #200
Use at your own risk: rpi-imager_1.6.1_amd64.zip
(feel free to delete this @maxnet if you feel it's inappropriate)

thx. worked on debian buster for me, while original download and snap failed

Just an FYI that this is an issue on ChromeOS too. If you have Linux Developer mode enabled 1.6.1 shared by @lurch works while the download from https://www.raspberrypi.org/software/ doesn't.

For the benefit of anybody following this issue...

I just tried compiling the v1.6.2 tag on Ubuntu 18.04 and it fails to build with:

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

because that function was added in Qt 5.10, but Ubuntu 18.04 only includes Qt 5.9.5.
So it looks like my build of v1.6.1 is "end of the line" for Ubuntu 18.04 users :wink:

They are for those who _don't_ want new versions of software.

No. I use LTS because upgrading or installing new release is a huge time consumer. After install a lot has to be modified/tweaked, installed, set up etc. It takes a lot of time. The LTS gives the opportunity to use a system for a much longer time. As of my current 18.04 I'm not going to use Ubuntu anymore (but that is another story).

I use several PPAs + some appimages. For things like PHP I install it myself.

Am afraid 20.04 LTS is new minimum, because I upgraded to that. :-)

I believe this whole "18.04 too old" discussion is missing a huge, deeper issue with the project: why the build process is tied your particular version? Are you compiling and publishing it _yourself_? Doesn't rpi-imager have a CI, PPA, Github action or any such tool for a cloud build workflow?

As long as _that_ tool supports 18.04 (and the sources are compatible), @maxnet 's personal OS should be irrelevant. A PPA can build for _all_ current Ubuntu versions. Travis-CI and Github can build for many platforms. You can even use Windows for development and let the cloud build for Fedora, Mac, BSD, ARM, no matter how ancient or bleeding edge the platform is.

That said...

As long as that tool supports 18.04 (and the sources are compatible)

1) Sources will not be compatible in the future without #ifdef magic.
Newer methods do not exist in ancient Qt versions.
Using the older methods give a bunch of deprecated warnings on newer Qt 5 versions, and will go away in Qt 6

2) This is an application that needs to be code signed on at least Windows and Mac OS X and I am not a big fan of sharing code signing keys with cloud providers.

3) Would still need an installation of every operating system to be able to test if result works correctly.
This type of software (with interaction with system services and physical hardware like SD card readers) is not so suitable for automated testing frameworks...

And Ubuntu 20 LTS has been out for a year.

And Ubuntu 18 is still supported for more two whole years. Your point?

Just be aware that the overall usefulness of Ubuntu 18 for developers is rapidly decreasing.
...
What is the reason you are still using 18?

That's... not how to handle this issue. @lurch 's particular reasons for using 18 should not matter. There are many. As you had yours to switch to 20.04, while some already jumped on 21.10.

It's not reasonable to expect an old LTS to remain a supported platform a year after the current one is released.

It is. It's called an LTS for a reason! _Long-Term_ Support.

there's been a year grace period!

False. The "year grace period" will only _begin_ on April 2022, where we'll _then_ have a whole year until _2023_ to migrate to Ubuntu 22.04, entirely skipping 20.04, while still using a fully-supported system. I _really_ don't want the hassle of upgrading the whole OS every 2 years

Come on guys... Ubuntu has just fully embraced Raspberry, releasing not only a Server edition but also Desktop, Core, the whole family. They added all Raspberry-specific packages to their repositories, no more PPAs needed for rpi-eeprom or vcgencmd.

Please fully support it too for a long and happy marriage :1st_place_medal:

And Ubuntu 18 is still supported for more two whole years. Your point?

"Supported" does not mean you get to have newer versions of software.
Everything on an Ubuntu 18 system is the 2018 version of software, with only stability and security fixes added as backports later.
You can still run older versions of Imager on it, to match the rest of system.

1. This is an application that needs to be code signed on at least Windows and Mac OS X and I am not a big fan of sharing code signing keys with cloud providers.

Doesn't Raspberry (the company / organization) provide you _any_ infrastructure or guidance on this? I mean... IMHO rpi_imager is a key component in Raspi's ecosystem. It's the very _entry point_ of using it. It is showcased in the official websites of _both_ Raspberry and Ubuntu as the endorsed imager.

Not sure what the official support policy is.

Given the high profile of this project, I'm really surprised that there's no official policy on that.

"Supported" does not mean you get to have newer versions of software. Everything on an Ubuntu 18 system is the 2018 version of software, with only stability and security fixes added as backports later.

Fair point, and I agree. I don't mind using an outdated version, as long as my _current_ version keeps working. And that's not what happened here.

rpi-imager, installed from snap, just _broke_ out of the blue, yesterday. It stopped working, with the same dmesg errors about AppArmor profiles and blanked drives as @lurch reported, which led me here. Why an incompatible version was uploaded to the 18.04 channels?

Fair point, and I agree. I don't mind using an outdated version

Then you can try the older 1.6.0: https://downloads.raspberrypi.org/imager/imager_1.6_amd64.deb

rpi-imager, installed from snap, just broke out of the blue

Snap issues can be reported here: https://github.com/popey/imager-snap/issues
We are not involved with that version.

Some possibly relevant clarifications:

rpi-imager, installed from snap, just _broke_ out of the blue, yesterday.

Maybe it broke earlier. I've been using it regularly for moths, but always using the same (cached) image. Yesterday I tried some new ones, so maybe that's why only now the problem manifested. Installed version is 1.6.2, and IIRC it's been so for at least a few weeks.

I don't mind using an outdated version

It's not that I don't care. I do. But I'm aware I'm not _entitled_ to anything. I just wished some projects took a more conservative approach when it comes to adopting new API that might break older (but still not EOL'd) releases.

I, for example, do a lot of Python development, and face the same dilemma a lot: if there's a new, gorgeous feature in Python 3.9, I refrain from using it even if I'm already at Python 3.11, because older distros like CentoOS still ships with the ancient 3.6. At least they have 3.8 _available_, so I can bump my minimum source version to that. Can a similar approach be taken here?

Digging deeper into the logs, I believe we're dealing with 2 distinct, independent issues here:

• Somehow I am (and has always been) able to install and launch not only 1.6.1 but 1.6.2 from snap. So whatever @popey did to compile it for 18.04 worked, congrats! This suggests my errors about AppArmor when writing images have nothing to do with package dependencies or QT compilation problems when building the .deb (that _this_ issue seems to be about), although both manifest in 18.04

• My issue, and it seems @XECDesign 's too, is about _permissions_, and it looks like this is a snap-only issue. So I'll move there as instructed.

For anyone coming here with problems such as _"An AppArmor policy prevents this sender from sending this message ..."_, _"Could not open network socket"_, or _"operation not permitted"_, go to this issue, not here. It's just there are a lot of issues with 18.04 in its title :-)

able to install and launch not only 1.6.1 but 1.6.2 from snap. So whatever @popey did to compile it for 18.04 worked, congrats!

I think snap is a "self-contained" packaging format? So it's probably able to include a newer version of the Qt libraries than are included with Ubuntu 18.04 ? (which the .deb version of RPi Imager would need to use)

Snap issues can be reported here: https://github.com/popey/imager-snap/issues
We are not involved with that version.

@maxnet We seem to get quite a few problem-reports about the snap version of RPi Imager (probably because that's the version that Ubuntu's "software store" installs), which we obviously can't do anything about. Maybe it's worth making use of GitHub's issue-template feature, to direct people having problem with the snap version of RPi Imager directly to popey's repo? :shrug:

The older version 1.6.0 (referenced by @maxnet) installed good on Linux Mint 19.3 (bionic repo). Thx