v1.6.2 crashes and quits in Macbook Air with M1 chip and Big Sur

[asemev]

I've seen issue #202 and tried the version from that post but it also crashes as soon as i try to open it.
I guess its not compatible with Apple Silicon? Thanks.

[maxnet]

I guess its not compatible with Apple Silicon?

Can you check if this one does work: https://github.com/raspberrypi/rpi-imager/releases/tag/v1.5

That did run on their developer transition kit.
Later versions have not been tested on their silicon (at least not by me), as I no longer have the hardware.
(although it was supposed to be a 1 year rental, Apple cancelled their program prematurely and wanted their gear back).

[asemev]

Hi, unfortunately v1.5 also crashes :(

[maxnet]

That version certainly worked before...

Will ask Apple dev support what the "attachment of code code signature supplement failed: 1" message means exactly.
May take a while to get a reply though:

Developer Technical Support will not be reviewing requests between June 5, 2021 and June 13, 2021 due to WWDC.

Please note that support requests submitted after June 2, 2021 may not be answered prior to the shutdown, and responses
may be delayed leading up to and after the shutdown.

There do are other similar reports for other applications, e.g.: https://www.fantasygrounds.com/forums/showthread.php?68503-FGU-crashing
But those mention the problem started after a MacOS v11.3 update, and went away after updating to v11.4, which you are already running...

[asemev]

Ok cool thank you for looking into this. Yes indeed I'm running 11.4.
Let me know if you need the whole crash report.
Good luck and thanks.

[maxnet]

Let me know if you need the whole crash report.

Yes, that may be helpful, as support said they cannot reproduce the issue on their side (with Imager v1.6.2 and OS X 11.3 and 11.4)

And would also like any other logs that may be relevant (in "finder" -> "applications" -> utilities -> "console" you can find some. Can right click on say "system.log", and select "show in finder" to access file and copy).

[asemev]

You know what, an idea came to my mind. I think i did not install rosetta 2, maybe i skipped it when i got the prompt one day, dont remember. But i installed now manually and then re-installed the imager and voila, it works! maybe its somehow related...

[avni]

On a related note, we are seeing a similar problem with one the most popular applications we use for Internet-in-a-Box, kiwix-serve, on Macs with an M1 chip. We've tested with a number of VMs on the M1 Mac and can't get kiwix-serve to start on Ubuntu 20.04 ARM64: iiab/iiab#3039

[holta]

Does anybody know how complicated it would be to recompile Raspberry Pi Imager for M1 Mac CPU's ?

[maxnet]

Does anybody know how complicated it would be to recompile Raspberry Pi Imager for M1 Mac CPU's ?

Recall M1 is only officially supported on Qt version 6, and we use 5 currently.

No idea how well Imager compiles against Qt 6.
Probably requires replacing some deprecated methods we still call (for support with older Linux distributions) with there more modern equivalents. May need some changes like: #134

Question do would be, what would you gain by building natively for M1?
Do not expect any performance gains.
And running the Intel binaries under emulation does work correctly for most.

[holta]

@maxnet wrote:

running the Intel binaries under emulation does work correctly for most

I did not know that!

Which kind of emulation is recommended on M1 Macs to allow Raspberry Pi Imager to run, if you know?

[maxnet]

Which kind of emulation is recommended on M1 Macs to allow Raspberry Pi Imager to run, if you know?

Rosetta 2

You should be prompted for installation automatically on first Imager use, but if you accidentally declined there is a report it does not ask again.
So in that case just install Rosetta manually.

[maxnet]

Rosetta can be manually installed (if you declined earlier) from terminal with:

softwareupdate --install-rosetta

Video instructions: https://www.youtube.com/watch?v=fQ0xVOVmiLs

[avni]

@maxnet THANK YOU SO MUCH!!!!! That worked. 🎉

[asemev]

Manually install rosetta for M1 Macs to provide compatability. Thank you @maxnet!

[holta]

Manually install rosetta for M1 Macs to provide compatability. Thank you @maxnet!

Does anybody know why the above sometimes runs 100X more slowly to flash microSD cards?

The result is that Rosetta 2 on an M1 Mac somehow causes Raspberry Pi Imager to take many hours to flash a simple image to a microSD card.

As @avni (above) has confirmed.

This painfully intermittent pattern is baffling.

Does anybody have suggestions for how to monitor/resolve intermittent bugs like this?

[maxnet]

Does anybody know why the above sometimes runs 100X more slowly to flash microSD cards?

Did you test that with the exact same USB SD card reader and SD card as on an Intel Mac?

While I do not have any production M1 gear to test on, when I borrowed Apple pre-release hardware earlier, it used to run at around same speed as on Intel.

And you mention sometimes.
So sometimes it does is the same speed?

Does it matter if the image is being downloaded from the Internet, or are you using locally stored ones?

And you do are comparing the speed between Mac OS on Intel and on M1, right?
(As it does is known that Imager does run a lot faster on Linux than on Mac OS and Windows.
That is not Intel/M1 related.)

As @avni (above) has confirmed.

Tested what way exactly?

I don't know what column is CPU usage in the partial screenshot in the post above (is it 4,20% ?), but since none is anywhere near 100%, I don't think it is short on processing power.
That is usually the first thing that maxes out if something is not running properly under emulation, and I do not see that being the case.

[holta]

So sometimes it does is the same speed?

Yes. Sometimes it runs full speed.

Other times (with the very same .img.zip), the writing-to-microSD phase runs at a glacial pace (about 100X more slowly than it should, on any other machine) taking many hours to complete.

Almost as if the underlying dd layer is not engaging properly, mysteriously at certain times (in the end writing out kbits/sec instead of Mbits/sec).

(In any case, Baffling Indeed: one of those very annoying intermittent bugs that are hard to diagnose for sure!)

Does it matter if the image is being downloaded from the Internet, or are you using locally stored ones?

Good question. I'll ask @avni if she has time in the coming week to try to monitor & try to better understand this painfully unpredictable 😖 pattern!

[holta]

Did you test that with the exact same USB SD card reader and SD card as on an Intel Mac?

@avni can hopefully clarify the exact make & model of the SD card reader she used, as she struggled to understand why on earth this was happening (over the past 2+ weeks).

It's extremely time-consuming to test over many hours.

(So if there are other ways to help her debug this more efficiently, she would greatly appreciate that!)

[maxnet]

So if there are other ways to help her debug this more efficiently, she would greatly appreciate that!

I am afraid there is no easy way to pinpoint problems like that.

Naturally, you do can use standard unix tools like "iostat" on the terminal to show at what speed it is writing to card exactly.
But that will not tell you where the problem is, if things are under-performing.
And that problem could be both in our code, with the emulation, something unrelated in Apple's kernel (which is hard for us to debug) or be hardware specific...

As for what write speed is being normal:

• Using a newer generation Samsung EVO Plus 64 GB SD card.
• With this reader: https://www.amazon.de/-/en/gp/product/B07D1J88CF/ref=ppx_od_dt_b_asin_title_s00
• Using an image that was last written before and therefore is cached on disk instead of downloaded. (Note that if you do download from the Internet it will download and write simultaneously, so any glitch in connectivity will also delay the write.).

On an Intel Mac Mini if you let "iostat 10" print out the average speed over the last 10 seconds, it shows read/write speeds between 61 and 65 MB/sec
(disk2 = SD card. disk0 is where it reads the compressed .zip from. writes are 1 MB block size, reads from SD card for verification 128 KB block size. so during verification tps is a lot higher).

Maxs-Mac-mini:~ max$ iostat 10
              disk0               disk2       cpu    load average
    KB/t  tps  MB/s     KB/t  tps  MB/s  us sy id   1m   5m   15m
  129.96  171 21.73   607.40   16  9.61  83 10  6  6.24 3.39 2.39
  185.02  160 28.93  1024.00   61 61.00  80  9 11  6.97 3.64 2.49
  237.41  169 39.10  1024.00   66 65.78  84  9  7  7.67 3.90 2.59
  178.15  135 23.52   388.77  172 65.22  83  9  8  8.10 4.11 2.68
  104.91  163 16.69   128.00  506 63.19  73 11 16  7.87 4.19 2.73
  149.62  112 16.38   128.00  501 62.66  79 12 10  7.69 4.27 2.77

That is slightly slower than Imager on Linux where the same card writes at a more steady 66 MB/sec.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.18    0.06    1.09    8.36    0.00   90.32

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
[...]
sdd             118.90         0.00     66741.60         0.00          0     667416          0

And verifies at 86 MB/sec.

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.02    0.06    0.94    1.11    0.00   96.87

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
[...]
sdd             677.70     86745.60         0.00         0.00     867456          0          0

Also if you start Imager from the command-line, it will print to console the number of seconds it took to write the image.
E.g. when writing RPI OS lite:

Maxs-Mac-mini:~ max$ /Applications/Raspberry\ Pi\ Imager.app/Contents/MacOS/rpi-imager 
[...]
Zeroing out first and last MB of drive
Done zeroing out start and end of drive. Took 0 seconds
Hash of uncompressed image: "2bc2b6ed6844cf492e3026e526431620669c823e1503017338d4132599b4ca21"
Write done in 28 seconds
Verify hash: "2bc2b6ed6844cf492e3026e526431620669c823e1503017338d4132599b4ca21"
Verify done in 32.091 seconds

Again, if it is slower in your case, I am afraid that will only confirm that things are slow, but not tell you why it is slow....

[holta]

@maxnet those debugging suggestions are incredibly helpful, Thank You !!

Somehow this will be solved in coming months...

[maxnet]

The result is that Rosetta 2 on an M1 Mac somehow causes Raspberry Pi Imager to take many hours to flash a simple image
to a microSD card.

If you really believe the issues are caused by the emulation (which I have my doubts about), here is a native build, you can try.

• It is a universal build that has been compiled for both x86_64 and arm64:

$ file Raspberry\ Pi\ Imager.app/Contents/MacOS/rpi-imager 
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture x86_64):    Mach-O 64-bit executable x86_64
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture arm64):     Mach-O 64-bit executable arm64

But I have NOT tested if it actually runs at all on arm64, as I do not have M1 gear...
(So yes, it is a "if it compiles, ship it" build)

• Being an universal build, it does have the downside that the application is twice as large in size...
• And it using Qt 6, has the downside it requires at least Mac OS X 10.14, leaving users that still use the older Mac OS X 10.13 behind...
  (And some may not be able to upgrade easily. E.g. due to insufficent disk space, which is a common problem on entry model Macs)
  That may not be desirable, so I do not expect this type of build to become an official release anytime soon.

imager-universal.dmg

[holta]

Please give a Nobel Prize to @maxnet so https://Internet-in-a-Box.org installs (and similar school/clinic grassroots empowerment) can accelerate across the developing world.

I do not ask why all the Fancy Pants people professing to fight poverty have the fanciest M1 computers & iPhones imaginable — but that's obviously the warped world we live in — so let's make it happen...

@avni do you have the phone number for the Nobel Committee ?

[avni]

Thanks @maxnet and @holta! And thanks @maxnet for the universal build and debugging tips!

Did you test that with the exact same USB SD card reader and SD card as on an Intel Mac

Test 1: M1 Mac Remote File

• Computer: M1 Macbook Pro, 8GB RAM
• Reader: https://www.amazon.com/gp/product/B07X5YM12G/
• SD Card: SanDisk Ultra 64GB
• File: Remote: https://download.iiab.io/7.2/iiab-7.2preview3-211226-SMALL-raspios-11-lite-ge1de8eb1.img.zip
• File Size: 1.6GB (believe this is the compressed file size. The image itself is 7.36GB)
• RPI-imager was opened using a wrapper iiab-imager script from the command line so it didn't print the number of seconds it took to write the image to the console so this is just an approximation:
• -- Write Time: ~7 minutes; Verification: 1-2 minutes

iostat 10 (disk4 is the SD card) much slower than @maxnet's:

[avni@Avnis-MBP ~ % iostat 10
              disk0               disk4       cpu    load average
    KB/t  tps  MB/s     KB/t  tps  MB/s  us sy id   1m   5m   15m
   28.70   15  0.41    60.75    0  0.00   7  3 90  2.92 2.02 1.73
   10.66   26  0.27  1024.00   16 15.59   2  3 95  2.63 1.99 1.72
   50.60  189  9.32  1024.00   16 16.30   5  4 91  2.30 1.94 1.71
   43.22  510 21.53  1024.00   17 17.49   8  6 86  2.02 1.89 1.69
   84.41   66  5.41  1024.00   14 13.70   3  3 94  1.86 1.86 1.68
  149.72   39  5.64  1024.00   15 14.69   2  2 96  1.89 1.86 1.69
   84.88   93  7.69  1024.00   15 14.60   4  3 94  1.67 1.82 1.67
  131.25   23  2.95  1024.00   15 14.60   1  2 97  1.73 1.82 1.67
  208.29   29  5.92  1024.00   15 14.70   2  2 97  1.62 1.79 1.67
  421.67   13  5.23  1024.00   15 14.79   1  2 97  1.45 1.75 1.65

Test 2: M1 Mac Local File

• Computer: M1 Macbook Pro, 8GB RAM
• Reader: https://www.amazon.com/gp/product/B07X5YM12G/
• SD Card: SanDisk Ultra 64GB
• File: Local: Downloaded and unzipped: https://download.iiab.io/7.2/iiab-7.2preview3-211226-SMALL-raspios-11-lite-ge1de8eb1.img.zip
• File Size: 7.36GB
• (from terminal) Write done in 479 seconds (~8 min), Verify done in 93.553 seconds (~1.5 min)

iostat 10 (disk4 is the SD card) still much slower than @maxnet's:

[avni@Avnis-MBP ~ % iostat 10
              disk0               disk4       cpu    load average
    KB/t  tps  MB/s     KB/t  tps  MB/s  us sy id   1m   5m   15m
   29.23   15  0.42    54.06    0  0.00   7  3 90  2.10 1.53 1.46
  399.41   42 16.30  1024.00   16 15.89   3  4 92  2.00 1.53 1.46
  167.23   95 15.56  1024.00   14 14.40   2  4 94  2.00 1.54 1.47
  161.75   98 15.51  1024.00   14 14.50   4  5 92  1.77 1.51 1.45
  284.91   53 14.74  1024.00   14 14.40   4  4 91  1.73 1.51 1.45
  329.95   46 14.78  1024.00   14 14.39   5  5 90  1.61 1.49 1.45
  197.33   79 15.31  1024.00   15 14.59   4  5 91  1.67 1.51 1.45
  279.18   55 15.07  1024.00   15 14.59   4  4 92  1.71 1.52 1.46
  374.27   41 14.95  1024.00   15 14.60   4  5 91  1.69 1.52 1.46
  243.31   65 15.35  1024.00   15 14.60   5  4 91  1.66 1.52 1.46
  103.05  173 17.37  1024.00   15 14.59   7  4 90  1.64 1.52 1.46
  349.67   43 14.57  1024.00   15 14.59   4  4 92  1.54 1.50 1.45
  209.89   75 15.45  1024.00   15 14.70   4  4 91  1.54 1.50 1.45
  350.24   44 15.04  1024.00   15 14.69   5  5 90  1.61 1.52 1.46
  276.11   55 14.77  1024.00   15 14.59   3  3 94  1.56 1.51 1.46

Will do a remote and local file test on an Intel Mac with the same reader and card next. I suspect too it is not the emulation and something else. I did several rounds of Test #1 on the M1 and am not able to reproduce the use case where the write took ~4 hours that happened the first 1-2 tests on the M1. One other thought, could an empty vs non-empty SD card make a difference?

Thanks so much for your help! No connection to a Nobel committee but can provide emoticons - does that count?
🥇 💯 🎉 Thank you again.

[avni]

Test 3: Intel Mac Remote File

• Computer: Intel Macbook Pro, 16GB RAM
• Reader: https://www.amazon.com/gp/product/B07X5YM12G/
• SD Card: SanDisk Ultra 64GB
• File: Remote: https://download.iiab.io/7.2/iiab-7.2preview3-211226-SMALL-raspios-11-lite-ge1de8eb1.img.zip
• File Size: 1.6GB (believe this is the compressed file size. The image itself is 7.36GB)
• (from terminal) Write done in 481 seconds (~8 minutes), Verify done in 153.66 seconds (~2.5 min)

iostat 10 (disk2 is the SD card):

[MBP ~ % iostat 10
              disk0               disk2       cpu    load average
    KB/t  tps  MB/s     KB/t  tps  MB/s  us sy id   1m   5m   15m
   20.27   30  0.60     7.68    0  0.00  10  5 85  1.71 2.37 2.47
   33.46  464 15.17     0.00    0  0.00  20  8 72  1.99 2.41 2.48
   25.10  105  2.58     1.32   10  0.01  11  9 79  2.22 2.44 2.49
   26.02  173  4.41   865.42   13 10.90  10  8 82  2.56 2.51 2.52
   20.87   71  1.46  1024.00   15 15.30   8  5 87  2.70 2.54 2.53
  132.57   18  2.28  1024.00   14 13.69   6  5 89  2.60 2.52 2.52
  320.66   18  5.70  1024.00   15 14.59   8  6 86  2.43 2.49 2.51
   98.13   64  6.15  1024.00   13 13.40   8  6 87  2.60 2.52 2.52
   67.51   80  5.30  1024.00   15 14.80   8  6 86  2.51 2.51 2.51
  119.27   61  7.15  1024.00   14 14.49   8  7 85  2.72 2.55 2.53
   54.45   78  4.13  1024.00   14 14.20   8  5 86  2.67 2.55 2.53
  224.28   22  4.93  1024.00   16 16.09   7  5 87  2.58 2.53 2.52
  326.22   18  5.67  1024.00   15 15.19   8  6 86  2.33 2.48 2.50

Test 4: Intel Mac Local File

• Computer: Intel Macbook Pro, 16GB RAM
• Reader: https://www.amazon.com/gp/product/B07X5YM12G/
• SD Card: SanDisk Ultra 64GB
• File: Local: Downloaded and unzipped: https://download.iiab.io/7.2/iiab-7.2preview3-211226-SMALL-raspios-11-lite-ge1de8eb1.img.zip
• File Size: 7.36GB
• (from terminal) Write done in 484 seconds (~8 min), Verify done in 157.645 seconds (~2.5 min)

iostat 10 (disk2 is the SD card)

[MBP ~ % iostat 10
              disk0               disk2       cpu    load average
    KB/t  tps  MB/s     KB/t  tps  MB/s  us sy id   1m   5m   15m
   20.33   30  0.60    56.45    0  0.00  10  5 85  2.80 2.29 2.34
  198.48   77 15.00  1024.00   14 14.00   6  4 89  2.52 2.24 2.32
  244.17   58 13.92  1024.00   13 13.29  10  6 84  2.43 2.24 2.32
  315.06   44 13.69  1024.00   14 13.79   7  4 89  2.22 2.19 2.30
  231.13   76 17.20  1024.00   17 16.60   7  4 88  2.18 2.19 2.30
  341.17   48 16.09  1024.00   16 16.10   9  4 87  2.08 2.16 2.29
  248.18   51 12.33  1024.00   12 12.50  10  6 85  2.06 2.16 2.28
  191.08   80 14.91  1024.00   14 14.50   9  5 86  1.97 2.14 2.27
  266.82   56 14.59  1024.00   14 14.40   6  3 90  1.82 2.10 2.26
  307.94   46 13.80  1024.00   13 13.20   7  4 89  1.77 2.08 2.25
   67.27  258 16.93  1024.00   15 14.90  12  7 81  1.94 2.11 2.26
  325.50   46 14.62  1024.00   14 14.50   8  5 87  1.88 2.09 2.25
  187.65   82 15.12  1024.00   15 14.60   8  5 87  2.11 2.13 2.26

There does not seem to be a material difference between remote vs local file on either the Intel or M1 Mac. Given these results, thinking the culprit may be the reader or the SD card that was causing the glacial write to the SD Card the first couple of times on the M1 Mac?

[imanuelcostigan]

If you really believe the issues are caused by the emulation (which I have my doubts about), here is a native build, you can try.

• It is a universal build that has been compiled for both x86_64 and arm64:

$ file Raspberry\ Pi\ Imager.app/Contents/MacOS/rpi-imager 
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture x86_64):    Mach-O 64-bit executable x86_64
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture arm64):     Mach-O 64-bit executable arm64

But I have NOT tested if it actually runs at all on arm64, as I do not have M1 gear... (So yes, it is a "if it compiles, ship it" build)

• Being an universal build, it does have the downside that the application is twice as large in size...
• And it using Qt 6, has the downside it requires at least Mac OS X 10.14, leaving users that still use the older Mac OS X 10.13 behind...
  (And some may not be able to upgrade easily. E.g. due to insufficent disk space, which is a common problem on entry model Macs)
  That may not be desirable, so I do not expect this type of build to become an official release anytime soon.

imager-universal.dmg

This seems to have fixed it for me, including some pesky verification issue that comes up. My setup

[lurch]

Being an universal build, it does have the downside that the application is twice as large in size...
And it using Qt 6, has the downside it requires at least Mac OS X 10.14, leaving users that still use the older Mac OS X 10.13 behind...
(And some may not be able to upgrade easily. E.g. due to insufficent disk space, which is a common problem on entry model Macs)
That may not be desirable, so I do not expect this type of build to become an official release anytime soon.

I know very little about Macs, and it'd obviously be a bit of a hacky solution, but would it be possible to build a universal binary where the x86_64 part is compiled against Qt5 and the arm64 part is compiled against Qt6? 🤷‍♂️

[maxnet]

I know very little about Macs, and it'd obviously be a bit of a hacky solution, but would it be possible to build a universal binary
where the x86_64 part is compiled against Qt5 and the arm64 part is compiled against Qt6?

I know too little about the Mac specific internals to pull that off easily.

Current universal build experiment was a matter of:

• search and replace "qt5" for "qt6" and link in "Qt::Core5Compat" in the CMakeLists.txt.
• add a CMAKE_OSX_ARCHITECTURES define (set(CMAKE_OSX_ARCHITECTURES "x86_64;arm64" CACHE STRING "" FORCE))

And CMake/Xcode takes care of compiling for the two architectures itself.
No idea what is done under the hood exactly to construct an universal build, and how to do that manually.

Also don't know if the native M1 build brings any advantage, other than that it then also works if the user declined installation of Rosetta
Hard to say if the "verification issue" being solved is really thanks to the M1 build.
There are other reports about verification issues, appearing spontaneously and not being so reproducible.
(And not sure if that is a problem in Imager or it is actually a correct report. And there was something wrong with reader/SD card/communication instead.)

[danielktdoranie]

If you really believe the issues are caused by the emulation (which I have my doubts about), here is a native build, you can try.

• It is a universal build that has been compiled for both x86_64 and arm64:

$ file Raspberry\ Pi\ Imager.app/Contents/MacOS/rpi-imager 
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture x86_64):    Mach-O 64-bit executable x86_64
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture arm64):     Mach-O 64-bit executable arm64

But I have NOT tested if it actually runs at all on arm64, as I do not have M1 gear... (So yes, it is a "if it compiles, ship it" build)

• Being an universal build, it does have the downside that the application is twice as large in size...
• And it using Qt 6, has the downside it requires at least Mac OS X 10.14, leaving users that still use the older Mac OS X 10.13 behind...
  (And some may not be able to upgrade easily. E.g. due to insufficent disk space, which is a common problem on entry model Macs)
  That may not be desirable, so I do not expect this type of build to become an official release anytime soon.

imager-universal.dmg

This seems to have fixed it for me, including some pesky verification issue that comes up. My setup

Would be good to post this on the releases page and give those of us who do own M1 Macs the option of using installing this (versus having to search through GitHub threads to find the native arm binary).

Apple is out of the Intel “game”, they only sell one Intel Mac now (the Mac Pro), it was first released in December 2019, it will soon be replaced with an M1 Mac Pro come Spring.

My point is that any Intel Mac only release is de facto legacy support at this stage.

Apple themselves stated Rosetta 2 is only a temporary solution and they will kill it eventually (just as they killed Rosetta 1 in 2008, that version helped with the Power PC to Intel transition).

It would be advantageous to embrace this new M1 Mac architecture, after all it is arm and Raspberry Pi uses arm too.

[maxnet]

Would be good to post this on the releases page and give those of us who do own M1 Macs the option of using installing this

I don't think putting UNTESTED stuff on the release page is a good idea.
And I don't know whether or not multiple releases are desired. (not sure what the number of people that have something against installing Rosetta is versus the number of Mac users that may accidently download the wrong file).

Apple is out of the Intel “game”, they only sell one Intel Mac now (the Mac Pro), it was first released in December 2019, it will
soon be replaced with an M1 Mac Pro come Spring.

Well, I don't feel the urgency to replace the Mac Mini I bought in 2018, and that would normally not be written off until 2023.

And think I am not the only freelance developer that feels that way.
Others can just rent some M1 time at Amazon AWS to develop and test though.
Which is not possible with this kind of software. Cannot connect a USB card reader to that..

[danielktdoranie]

Beta is beta, I am using it now on an M1 Mac and it is working perfectly

[shubhamshah02]

The result is that Rosetta 2 on an M1 Mac somehow causes Raspberry Pi Imager to take many hours to flash a simple image
to a microSD card.

If you really believe the issues are caused by the emulation (which I have my doubts about), here is a native build, you can try.

• It is a universal build that has been compiled for both x86_64 and arm64:

$ file Raspberry\ Pi\ Imager.app/Contents/MacOS/rpi-imager 
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture x86_64):    Mach-O 64-bit executable x86_64
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture arm64):     Mach-O 64-bit executable arm64

But I have NOT tested if it actually runs at all on arm64, as I do not have M1 gear... (So yes, it is a "if it compiles, ship it" build)

• Being an universal build, it does have the downside that the application is twice as large in size...
• And it using Qt 6, has the downside it requires at least Mac OS X 10.14, leaving users that still use the older Mac OS X 10.13 behind...
  (And some may not be able to upgrade easily. E.g. due to insufficent disk space, which is a common problem on entry model Macs)
  That may not be desirable, so I do not expect this type of build to become an official release anytime soon.

imager-universal.dmg

Is there a more later version of Imager that is universal? Would be very appreciated

[danielktdoranie]

The result is that Rosetta 2 on an M1 Mac somehow causes Raspberry Pi Imager to take many hours to flash a simple image
to a microSD card.

If you really believe the issues are caused by the emulation (which I have my doubts about), here is a native build, you can try.

• It is a universal build that has been compiled for both x86_64 and arm64:

$ file Raspberry\ Pi\ Imager.app/Contents/MacOS/rpi-imager 
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture x86_64):    Mach-O 64-bit executable x86_64
Raspberry Pi Imager.app/Contents/MacOS/rpi-imager (for architecture arm64):     Mach-O 64-bit executable arm64

But I have NOT tested if it actually runs at all on arm64, as I do not have M1 gear... (So yes, it is a "if it compiles, ship it" build)

• Being an universal build, it does have the downside that the application is twice as large in size...
• And it using Qt 6, has the downside it requires at least Mac OS X 10.14, leaving users that still use the older Mac OS X 10.13 behind...
  (And some may not be able to upgrade easily. E.g. due to insufficent disk space, which is a common problem on entry model Macs)
  That may not be desirable, so I do not expect this type of build to become an official release anytime soon.

imager-universal.dmg

Just wanted to post that I use this weekly and it's never crashed. It works perfect on the latest macOS build too (as of typing this macOS Ventura 13.2.1).

It really should be officially released and put on the software download page (https://www.raspberrypi.com/software/). IMHO the only reason we don't have an official build is because some people dislike Apple and frankly that is silly and obtuse.

Anyway, thank you @maxnet !

[maxnet]

If you want a newer universal build to test: Imager 1.7.4.1.dmg

With Qt 6.4 and the M1 stuff the size of the application did grow to 350 MB (uncompressed).