New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error: error creating firstrun.sh on fat partition when running on MacOS #205
Comments
1.7 beta was renamed to 1.6.1, as there were only small changes. Not sure what is the problem here. After it fails, you do are able to access the "boot" location in "Finder" and open say config.txt, add a random line of text there and "menu file" -> "save" the file? |
I am seeing similar issues too. The firstrun.sh file did not exist on my first flash attempt, but it did show up on the second attempt, using v1.6.1 of the imager. However, I am still unable to ssh into the Raspberry Pi. I am using a Samsung Evo+ 32GB microSD memory card with the CanaKit USB MicroSD Card Reader. |
And you did get the same "error creating firstrun.sh on the FAT partition" error as the issue starter on your first attempt? (Do note firstrun.sh gets removed by the Pi on first boot) |
I never actually saw an error on either attempt. I did try to boot first before looking at the file system on the first attempt, so that may be why the file did not exist. While researching the issue, I came across some mentions where people had problems connecting to 5 GHz WiFi access points in general. On a third attempt, I changed the WiFi SSID from the 5 GHz access point to the 2.4 GHz version and everything seemed to work properly. So my issue may actually be related to 5 versus 2.4 WiFi access instead of the Raspberry Pi Imager itself. |
Yes, that sounds likely. I can't see any reason why RPi Imager itself wouldn't work on the first two attempts, but then magically work on the 3rd attempt 😉 (especially if you never saw any error messages in Raspberry Pi Imager) |
Sorry for the late reply. It turns out that this was indeed a restriction on writing to USB device. I had overlooked this as the problem due to the fact that the OS itself wrote out fine. It was only the copy of the firstrun file that was failing. Apparently the checking for USB write must be done at a higher level and the low level OS write was ok. At any rate once this restriction was removed, all is well. I am fine with closing this issue, however, since it seems to have generated other interest, I leave it to others. |
Is that a setting in Mac OS X itself, or something introduced by third-party security software typically only used in larger companies to restrict what users can and cannot do? |
It was the latter. Company wide restriction on USB writing. Exemptions allowed for special cases. Once we got an exemption, all was good. |
Kinda ironic that the "security software" doesn't block low-level writing, as I guess that could theoretically be used to bypass the higher-level access restrictions 😉 |
Thanks for the info. |
Version 1.6.0 and can confirm the write process fails (Advanced / hidden options). Write process of Img works flawlessly though. This is not a big issue but should definitely be fixed as it just introduces confusion and extra work. |
Concerns a company computer with security software as well? |
My bad, it's night time and I missed some things/OP context. |
Suggest you upgrade to 1.6.2 first, and open a new issue listing the exact error message if that fails as well. |
I ran into this same issue with imager 1.6.2 on a Ubuntu machine that has no particular security software installed, so I don't think it's related to that. On the second attempt, I also set the options for configuring a timezone and keyboard, and skipping the first run wizard, but the error persists. When I don't configure any options, the imager runs fine. There is no error output on the command line. |
This particular issue is about MacOS with corporate security software installed. If you installed Imager on Ubuntu through snap (Ubuntu software center) the right place would be here: https://github.com/popey/imager-snap/issues/16 If you did download the .deb package from the Raspberry Pi website instead, try if it works better if you disable auto-mount in Ubuntu. |
I ran into this same problem when using the Snap version (1.6.2) of the rpi-imager. I tried to run it maybe six times, with a variety of errors, including the "firstrun.sh" issue. |
I am having this issue on 1.6.2 installed on Ubuntu 20.04. I have isolated the issue to having custom settings. I tried to set wifi and ssh and if I do either or both of those things I get the firstrun.sh error. |
How did you install Imager? |
|
Please report here: https://github.com/popey/imager-snap/issues/16 |
I am running that on Ubuntu 18.04. |
Assuming you are using the snap (as our .deb needs at least Ubuntu 20.04), please report here: https://github.com/popey/imager-snap/issues/16 |
This is the answer that allowed me to solve the issue. Ubuntu 22 + apt install rpi-imager (1.7.2) Thank you @knipknap for your answer |
That's an old version, newer versions are available at https://github.com/raspberrypi/rpi-imager/releases |
I did what the Readme says :
I got the 1.7.2 version and didn't check if it was the latest version available, thanks for pointing that out 👍 |
"Raspberry Pi OS" != "Ubuntu 22" 😉 |
Outch, my bad ! Thank you (again) ❤️ |
When using the imager at v. 1.6.1 on a Mac Big Sur OS (V 11.2.3) we are seeing this error consistently.
Error creating firstrun.sh on FAT partition
I have seen reports of the same issue on Windows possibly fixed by a 1.7 beta. Is there such a beta for the Mac as well?
The microSD cards are 16gb and are using an Anker USB-C SD card adapter.
The text was updated successfully, but these errors were encountered: