[BUG] Unable to write custom images / format as FAT32 without Internet

[maxnet]

Describe the bug

It is no longer possible to write custom images or format as FAT32 without Internet.
As also noticed by end-users: https://forums.raspberrypi.com/viewtopic.php?t=359002

To Reproduce

• Disconnect cable or tear down network interface.
• Start Imager
• Press "choose OS"
• Empty screen there

Additional context

Imager was originally designed to still offer the option to write a custom .img file, and format as FAT32, even if the user doesn't have Internet and downloading the os_list therefore fails.
This was done by hard coding those options in the osmodel ListModel in main.qml and pre-pending additional items to it on download.

Commit 3f665e0#diff-6b6066b8c2cfa063e0014db476a9967f054fc913bb71de97644e91e91e3660d3R1400 changes this to only append the custom image options after the OS list is downloaded.
This renders Imager unusable to users that cannot directly use the RPI server for any reason. (Could be no Internet, but also that they are running an old operating system that does not have the right SSL certificates, or that they cannot reach the server directly due to firewall problems, which they may have no control over.)

If this change in behavior was intended then at least the commit log should mention that.
Failing that, I consider this a bug.

[tdewey-rpi]

Definitely a defect. I'll take a look at this today.

Workaround for now is to use the CLI:

rpi-imager --cli $CUSTOM_IMAGE_FILE_PATH $DESTINATION_MEDIA_PATH

[maxnet]

Workaround for now is to use the CLI:

Or drag & drop file from a file manager to Imager GUI window.

[maxnet]

"qml: Return empty object on JSON failures"

It really should have the "use custom" item by default, and user should not have to wait till failure.
It can take a long time to fail in certain situations.

E.g. on embedded it will not start downloading the list until it has received an IP through DHCP. Which may take 30 seconds if STP is active in network.
And it may even never get an IP-address, in some corner cases.
(Embedded edition also allow people to bring their image on USB stick, so user does not always need Internet).

[tdewey-rpi]

That sounds like an orthogonal bug, where the embedded imager should present an OS list immediately and back-fill as it gains more knowledge?

[maxnet]

That sounds like an orthogonal bug, where the embedded imager should present an OS list immediately and back-fill as it gains more knowledge?

Perhaps at least display a big fat warning if STP is in-use and it is going to take a long time for Imager to be functional.

(Can be detected. Like we do with Piserver https://github.com/raspberrypi/piserver/blob/67a1513d8e6b6ec60458a6cfa81e97d046934bca/src/stpanalyzer.cpp )

But regardless of that. I do believe "use custom" should be available in all situations. And not only after a failure.

[tdewey-rpi]

@maxnet Completely agreed. Unfortunately this dovetails with another incoming feature, where we are going to move the OS list fetching and filtering into the C++ layer as part of a refactor to grant more powers to the CLI mode.

[tdewey-rpi]

I now believe the latest PR (#719) should safely resolve this problem - albiet producing slightly different internal JSON representations. Additionally, it sets the ground work for moving more business logic into the C++ layer, where we can verify it ahead of time.