raspberrypi
[BUG]: Suspicious UI performance on macOS 15.5+
What happened?
macOS 15.5+ users are reporting that with both 1.9.6 and 1.8.5, when Imager starts to ask the OS about the storage devices, the UI begins to jank - in some cases freezing for indeterminate periods of time.
1.9.6 included an always-in-the-background drive polling scheme, but 1.8.5 only polled the drives during selection.
Both appear to freeze at the start of the write.
Version
1.9.6 (Default)
What host operating system were you using?
macOS
Host OS Version
15.5
Selected OS
Irrelevant
Which Raspberry Pi Device are you using?
Raspberry Pi 5, 500, and Compute Modules 5
What kind of storage device are you using?
Other
OS Customisation
- [ ] Yes, I was using OS Customisation when the bug occurred.
Relevant log output
From @geerlingguy:
I've just updated to 1.9.6, and today some of the UI on my Mac (M4 Max Mac Studio, rebooted to be sure nothing else was funky) is stuck frozen for a looooong time. Like just clicking 'Yes' on the 'Would you like to apply OS customization settings?' takes minutes, and I've had to force quit a bit.
Not sure what's going on, but I've flashed about 15 microSD cards and USB drives today, and it started getting really sluggish in the past hour.
Symptoms that are only exposed after multiple back-to-back writes suggest a resource releasing issue. Curious that I've not observed it myself, however.
Yeah; it's a weird thing, and only started running into this today/yesterday after never hitting it before.
It feels like something is just blocking the UI for a while. No CPU usage, it's just sitting with the spinning rainbow wheel.
I flashed a couple more NVMe SSDs today (all from local .xz img file), and still had some slowdown in the dialogs (but after about 3 minutes waiting it went through).
I'm sure that it's an entirely different problem, but it's not the first time that we've run into problems with macOS behaving oddly with removable drives 😉 https://www.raspberrypi.com/news/the-ventura-problem/
@geerlingguy In 1.9.6, I allowed virtual disk images to be selected as storage media for Imager (helps development greatly).
Testing against that, I can't reproduce the slow down as reported - and putting 4 writes through a Realtek nVME to USB adapter didn't reproduce it either.
If you get chance, could you see if you can reproduce it with a virtual disk? I used Disk Utility to create a 16gb writable DMG, which suffices for testing.
Strangely a similar problem might happen when stopping the verification step, this can take several seconds... Maybe I should figure out how to disable the verification step in the first place...
Same issue on MAC 15.6 (x86) did a lot of imaging today. Then started to freeze as mentioned. I use the custom settings for wifi and ssh. Now the slowness of getting started - seems wifi and ssh settings are not making it to the final image. Where are the settings storred (as I can't seem to find any). Reboot does not resolve the issue.
More info - the allow public-key authentication only selection seems to "grow" when it should not. I have it selected in the enable ssh section "allow...".
My sequence: Open app select board select os select disk (always same disk type)
Next: edit - change host +1 save write
select disk (always same disk type)
Next: edit - change host +1 save write select disk (always same disk type)
Next: edit - change host +1 save write
......
at some point if I review authorized keys for ... I have 2 now. duplicate.
I believe I had 100's at one point (where there should have been only one.
Something in my sequence save out or read and double saves the public key.
Theory massive duplication over time kill gui responsiveness due to size or shape of the key data being duplicated many times. Could be 2 4 8 16 progression not sure.
I'm having a similar issue and may be reading this wrong. When I run Imager, on the 1st step, when I click on "Choose Device," it freezes. I'm not clear, from reading this, if that's when it's freezing for people or if it's freezing when they pick "Choose Storage," where you point to an actual device.
Basically, instead of getting a list of OSes for a Pi, I get a blank new window. This was happening on 1.8.??? and I updated to 1.9.6 and it's still happening.
Again, this is the 1st step, where Imager should be downloading a json file with a list of devices and OSes. It's not even when or after I would select the media to install to.
I'm having a similar issue and may be reading this wrong. When I run Imager, on the 1st step, when I click on "Choose Device," it freezes. I'm not clear, from reading this, if that's when it's freezing for people or if it's freezing when they pick "Choose Storage," where you point to an actual device.
For me it was after selecting board os and disk. Everything after NEXT button. To fix I cleared all the accumulated keys. Saved and re-started. Sorry no tthe same issue you describe.
This is a handy command to see the profile.
defaults read "org.raspberrypi.imager"
For me it was after selecting board os and disk. Everything after NEXT button. To fix I cleared all the accumulated keys. Saved and re-started. Sorry no tthe same issue you describe.
Okay, I'm not sure I'm following what you're saying precisely (which is likely me). When you say "board os and disk," just what do you mean by "board os?" Is that the first choice, when you select if you're using a Pi 3 or Pi 4 or something in that category? That's what I'm not seeing.
And what do you mean "accumulated keys?"
This is a handy command to see the profile.
defaults read "org.raspberrypi.imager"
Used that. I have 2 Mac Minis, one in my study, one in my workshop (which is for my business), in the barn, about 500' from the house. I checked the profiles with that command. The only differences were the hash for the last image downloaded info, the password hashes, and the Wifi SSID. (Since the barn is so far from the house, it's on a separate wifi, so a different password. But - in case it sounds like that could be the issue, both buildings are connected by 500' of fiber optic cable and are on the same LAN with the same address space and same gateway. So they should be working the same in terms of networking and retrieving the json file listing the info for device OS and so on.
More info - the allow public-key authentication only selection seems to "grow" when it should not. I have it selected in the enable ssh section "allow...".
@mcyork That's a known problem (see #1152 ) which I believe will be fixed in 1.9.7
When you say "board os and disk," just what do you mean
@TangoOversway I suspect that they mean that they've done each of the "Choose Device", "Choose OS" and "Choose Storage" steps https://www.raspberrypi.com/documentation/computers/getting-started.html#raspberry-pi-imager Do both of your Mac Minis have the same problem with RPi Imager? What versions of macOS and RPi Imager are each of them running? Do you see any error-logs if you try running Raspberry Pi Imager from the terminal?
Check the Imager.conf. I'll bet you it's very large by this point with the SSH key copied repeatedly-- as it's what was the cause for me here.
Do both of your Mac Minis have the same problem with RPi Imager? What versions of macOS and RPi Imager are each of them running? Do you see any error-logs if you try running Raspberry Pi Imager from the terminal?
No, one Mac is fine, one has the issue I mentioned. They're both on the same OS version (15.5) and both on 1.9.6 for Imager.
As to errors - well, first I was reading about similar issues elsewhere and deleted the cache directory - hoping that'd clear settings. (I couldn't find info on a settings file location on Mac, but could find cache info.) I figured, since I never did a configuration on install, that RPi Imager would look, find no files, and create its own configuration. Then I ran it from the command line and tried to get a list of systems and here's the logging:
Loading cache settings: Caching enabled: true Last file name: "" Uncompressed hash (extract_sha256): "aa4cfc1a13c97bdb12e6f37c40756e227b2ebfdd8773c9dec3b6de601c390281" Compressed hash (image_download_sha256): "(empty)" CacheManager initialized with background thread Starting background cache operations Background: Checking disk space for cache operations Background: Cache directory: "/Users/hal/Library/Caches/Raspberry Pi/Imager" Background: Available space: 55 GiB OSX most preferred language: "en_US" Disk space check complete: 55 GiB available in "/Users/hal/Library/Caches/Raspberry Pi/Imager" Unrecognised QT error: QNetworkReply::SslHandshakeFailedError , explainer: "SSL handshake failed: SSLHandshake failed: -9806"
I also want to point out I found a post that gave the URL for the json file Imager uses and I can load that in my browser with no issue - so it's not a proxy or VPN or any issue like that.
Thanks for the extra info @TangoOversway - it sounds like your problem is different to the one being discussed here, so could you open a separate issue please? Thanks.
Thanks for the extra info @TangoOversway - it sounds like your problem is different to the one being discussed here, so could you open a separate issue please? Thanks.
I'll do that in the next day or so. Thank you.
tl;dr: I deleted ~/Preferences/org.raspberrypi.Imager.plist (the Imager configuration file for macOS), which had contained 65,535 instances of my public key, and after restarting Imager, everything is as responsive as ever.
Ref: https://github.com/raspberrypi/rpi-imager/issues/1111#issuecomment-3220681446
Perhaps this should be closed as a duplicate of #1159 ? Thanks for your sleuthing @geerlingguy