[BUG]: Small edge-case bug causing Imager error

[lurch]

What happened?

I've got a Pi5 set up to boot from a USB3 SSD, which means the Pi5's internal microSD slot is empty. I use the Pi's (spare) internal microSD slot to write OS images because it's faster than my USB SD card-reader 🙂

I've discovered a very specific sequence of steps (which is why I'm classing this as an edge-case) which can cause Imager to display an "Error" window:

1. Insert a microSD card into the Pi5's microSD slot
2. Start up Raspberry Pi Imager
3. Ignore the "CHOOSE DEVICE" button/dialog
4. In the "CHOOSE OS " button/dialog select "Use custom" and choose a local .img file
5. In the "CHOOSE STORAGE" button/dialog select the "Internal SD card reader"
6. Click "NEXT"
7. Select "NO" when asked "Would you like to apply OS customisation settings?"
8. Select "YES" that you're happy to overwrite all existing data
9. A dialog box will pop up asking you to enter your password
10. Don't enter your password yet!
11. Open up a File Manager window, and click on one of the SD card's partitions
12. Flip back to Imager and enter your password in the dialog, click "Authenticate"
13. Imager displays an "Error" window saying "Cannot open storage device '/dev/mmcblk0'.
14. If you press "Continue" and then click on "NEXT" again (i.e. looping back to step 6), this time it works!

I suspect that this bug will be triggered regardless of what I choose in steps 3, 4 & 5. What I think is happening is:

• in step 1 the SD card's partition (i.e. /dev/mmcblk0p1) gets auto-mounted
• in step 8 Imager unmounts the SD card's partition (which presumably doesn't need sudo access)
• in step 9 Imager wants to write to the SD card (i.e. /dev/mmcblk0), which needs sudo access, so the password dialog pops up
• in step 11 the partition on the SD card (i.e. /dev/mmcblk0p1) gets re-mounted
• in step 13 Imager tries to use its newly-gained sudo access to write to /dev/mmcblk0, but this fails because /dev/mmcblk0p1 is still mounted
• in step 14 (i.e. when I try this again), Imager already has sudo access, and so the SD card partition gets unmounted in step 8 (and I don't have time to subvert the process by remounting the /dev/mmcblk0p1 partiition 😂 )

Given that this is such an edge-case, I'm happy for it to be closed as Won'tFix, but I thought I'd point it out anyway. It might be easy to fix by checking that the partitions are still unmounted after Imager gains sudo access, and if they are mounted then try unmounting them again before writing to the raw block device?

Version

1.8.5 (Default)

What host operating system were you using?

Debian and derivatives (eg Ubuntu)

Host OS Version

Raspberry Pi OS Bookworm

Selected OS

Custom

Which Raspberry Pi Device are you using?

Raspberry Pi 5

What kind of storage device are you using?

microSD Card in an internal reader

OS Customisation

• Yes, I was using OS Customisation when the bug occurred.

Relevant log output

No response

[maxnet]

"sudo access" is not really the right term.
We ask the udisks2 system service (running as root) through a DBus call to open the device for us, and pass us the file descriptor.
In most cases that DBus call will indeed prompt for password (whether it does depends on the system's policykit settings).

At no point does the Imager program itself run privileged under Linux and OSX.
(On Windows it does run privileged. But ideally that should be fixed as well, as it comes with downsides. Like that in some cases it cannot access .img files that the normal user do can access. E.g. if they are on a network share that normal user can access, but admin cannot).

[lurch]

"sudo access" is not really the right term.

Yeah, I suspected it probably wasn't the right term, but hopefully you knew what I meant 😉