Rpi-imager: Fehler: Fehler beim Erstellen von firstrun.sh auf einer Fat-Partition bei Ausführung unter MacOS

Erstellt am 8. Apr. 2021  ·  23Kommentare  ·  Quelle: raspberrypi/rpi-imager

Wenn Sie den Imager in Version 1.6.1 auf einem Mac Big Sur OS (Version 11.2.3) verwenden, sehen wir diesen Fehler ständig.
Error creating firstrun.sh on FAT partition
Ich habe Berichte über das gleiche Problem unter Windows gesehen, das möglicherweise durch eine 1.7-Beta behoben wurde. Gibt es so eine Beta auch für den Mac?
Die microSD-Karten haben 16 GB und verwenden einen Anker USB-C SD-Kartenadapter.

Hilfreichster Kommentar

Ich bin auf dasselbe Problem gestoßen, als ich die Snap-Version (1.6.2) des rpi-imager verwendet habe. Ich habe vielleicht sechs Mal versucht, es auszuführen, mit einer Vielzahl von Fehlern, einschließlich des Problems "firstrun.sh".
Ich habe die Snap-Version deinstalliert und die .deb-Datei (wiederum 1.6.2) direkt von www.raspberrypi.com/software heruntergeladen , und sie lief beim ersten Mal wie ein Zauber.
Danke an alle, die hier mitgewirkt haben!

Alle 23 Kommentare

1.7 Beta wurde in 1.6.1 umbenannt, da es nur kleine Änderungen gab.
Sie führen das also bereits aus.

Nicht sicher, was hier das Problem ist.
Imager kann die Datei erfolgreich auf meinem Mac Mini erstellen (mit einem USB-C-Lesegerät einer unbekannten Marke, das so aussieht)

Screenshot 2021-04-08 at 19 23 32

Nachdem dies fehlschlägt, können Sie auf den „Boot“-Speicherort im „Finder“ zugreifen und beispielsweise config.txt öffnen, dort eine zufällige Textzeile hinzufügen und „Menüdatei“ -> „Datei speichern“?
Es beschwert sich nicht, dass das Gerät schreibgeschützt ist oder irgendetwas Außergewöhnliches?

Ich sehe auch ähnliche Probleme. Die Datei firstrun.sh war bei meinem ersten Flash-Versuch nicht vorhanden, aber beim zweiten Versuch mit v1.6.1 des Imagers tauchte sie auf. Ich kann jedoch immer noch nicht in den Raspberry Pi ssh. Ich verwende eine Samsung Evo+ 32 GB microSD-Speicherkarte mit dem CanaKit USB MicroSD-Kartenleser.

Die Datei firstrun.sh war bei meinem ersten Flash-Versuch nicht vorhanden, aber beim zweiten Versuch mit v1.6.1 des Imagers tauchte sie auf.

Und Sie haben bei Ihrem ersten Versuch den gleichen Fehler beim Erstellen von firstrun.sh auf der FAT-Partition erhalten wie der Problemstarter?

(Beachten Sie, dass firstrun.sh beim ersten Start vom Pi entfernt wird.)

Ich habe bei beiden Versuchen nie einen Fehler gesehen. Ich habe versucht, zuerst zu booten, bevor ich mir beim ersten Versuch das Dateisystem angesehen habe, daher war die Datei möglicherweise nicht vorhanden. Während ich das Problem recherchierte, stieß ich auf einige Erwähnungen, bei denen Leute Probleme hatten, sich mit 5-GHz-WLAN-Zugangspunkten im Allgemeinen zu verbinden. Bei einem dritten Versuch habe ich die WLAN-SSID vom 5-GHz-Zugangspunkt auf die 2,4-GHz-Version geändert und alles schien ordnungsgemäß zu funktionieren. Mein Problem könnte also tatsächlich mit 5 versus 2.4 WiFi-Zugriff zusammenhängen, anstatt mit dem Raspberry Pi Imager selbst.

Mein Problem könnte also tatsächlich mit 5 versus 2.4 WiFi-Zugriff zusammenhängen, anstatt mit dem Raspberry Pi Imager selbst.

Ja, das klingt wahrscheinlich. Ich sehe keinen Grund, warum RPi Imager selbst bei den ersten beiden Versuchen nicht funktioniert, aber dann beim dritten Versuch auf magische Weise funktioniert :wink: (insbesondere, wenn Sie in Raspberry Pi Imager nie Fehlermeldungen gesehen haben)

Entschuldigung für die späte Antwort. Es stellt sich heraus, dass dies tatsächlich eine Einschränkung beim Schreiben auf ein USB-Gerät war. Ich hatte dies als Problem übersehen, da das Betriebssystem selbst gut geschrieben hat. Es war nur die Kopie der Erstlaufdatei, die fehlschlug. Anscheinend muss die Überprüfung auf USB-Schreiben auf einer höheren Ebene durchgeführt werden, und das Schreiben auf niedriger Ebene des Betriebssystems war in Ordnung. Sobald diese Einschränkung aufgehoben ist, ist jedenfalls alles gut. Ich bin damit einverstanden, dieses Thema zu schließen, da es jedoch anscheinend andere Interessenten geweckt hat, überlasse ich es anderen.

Entschuldigung für die späte Antwort. Es stellt sich heraus, dass dies tatsächlich eine Einschränkung beim Schreiben auf ein USB-Gerät war.

Ist das eine Einstellung in Mac OS X selbst oder etwas, das durch Sicherheitssoftware von Drittanbietern eingeführt wurde, die normalerweise nur in größeren Unternehmen verwendet wird, um einzuschränken, was Benutzer tun können und was nicht?
Ich frage mich nur, falls andere Benutzer ähnliche Probleme melden.

Letzteres war es. Unternehmensweite Beschränkung des USB-Schreibens. Ausnahmen für Sonderfälle zulässig. Als wir eine Ausnahmegenehmigung bekamen, war alles gut.

Unternehmensweite Beschränkung des USB-Schreibens.

Irgendwie ironisch, dass die "Sicherheitssoftware" das Schreiben auf niedriger Ebene nicht blockiert, da ich denke, dass dies theoretisch verwendet werden könnte, um die Zugriffsbeschränkungen auf höherer Ebene zu umgehen :wink:

Danke für die Information.
Da das Problem gelöst ist, werde ich dieses hier schließen.

Version 1.6.0 und kann bestätigen, dass der Schreibvorgang fehlschlägt (Erweiterte / versteckte Optionen). Der Schreibvorgang von Img funktioniert jedoch einwandfrei. Dies ist kein großes Problem, sollte aber definitiv behoben werden, da es nur zu Verwirrung und zusätzlicher Arbeit führt.

Version 1.6.0 und kann bestätigen, dass der Schreibvorgang fehlschlägt (Erweiterte / versteckte Optionen).

Betrifft auch einen Firmenrechner mit Sicherheitssoftware?
Wenn nicht, ist es nicht dasselbe Problem.

Version 1.6.0 und kann bestätigen, dass der Schreibvorgang fehlschlägt (Erweiterte / versteckte Optionen).

Betrifft auch einen Firmenrechner mit Sicherheitssoftware? Wenn nicht, ist es nicht dasselbe Problem.

Mein Fehler, es ist Nacht und ich habe einige Dinge/OP-Kontext verpasst.
Persönlicher Windows 10-Computer (mit Bitdefender).

Version 1.6.0
Persönlicher Windows 10-Computer (mit Bitdefender).

Schlagen Sie vor, zuerst auf 1.6.2 zu aktualisieren und ein neues Problem mit der genauen Fehlermeldung zu öffnen, falls dies ebenfalls fehlschlägt.

Ich bin auf dasselbe Problem mit Imager 1.6.2 auf einem Ubuntu-Computer gestoßen, auf dem keine bestimmte Sicherheitssoftware installiert ist, daher glaube ich nicht, dass es damit zusammenhängt.
Es ist bei einem Lauf passiert, bei dem ich Optionen (Strg + Umschalt + X) eingestellt habe, um einen Hostnamen festzulegen, SSH und WLAN zu aktivieren.

Beim zweiten Versuch habe ich auch die Optionen zum Konfigurieren einer Zeitzone und Tastatur eingestellt und den Assistenten für die erste Ausführung übersprungen, aber der Fehler bleibt bestehen.

Wenn ich keine Optionen konfiguriere, läuft der Imager einwandfrei.

Es erfolgt keine Fehlerausgabe auf der Kommandozeile.

Ich bin auf dasselbe Problem mit Imager 1.6.2 auf einem Ubuntu-Computer gestoßen, auf dem keine bestimmte Sicherheitssoftware installiert ist, daher glaube ich nicht, dass es damit zusammenhängt.

In dieser speziellen Ausgabe geht es um MacOS mit installierter Unternehmenssicherheitssoftware.
Vielleicht möchten Sie ein separates für Ubuntu öffnen.

Wenn Sie Imager auf Ubuntu über Snap (Ubuntu Software Center) installiert haben, wäre der richtige Ort hier: https://github.com/popey/imager-snap/issues/16
Beachten Sie, dass wir dieses Snap-Paket nicht erstellt haben, es von einem Drittanbieter bereitgestellt wird und sich, da es in einer Sandbox-Umgebung ausgeführt wird, anders verhält als unsere Version.

Wenn Sie stattdessen das .deb-Paket von der Raspberry Pi-Website heruntergeladen haben, versuchen Sie, ob es besser funktioniert, wenn Sie das automatische Mounten in Ubuntu deaktivieren.
Wenn es besser funktioniert, wenn Sie die Auto-Mount-Einstellung ändern, ist es wahrscheinlich bereits in der nächsten Imager-Version behoben (es gibt einen Fix für den Umgang mit Auto-Mount-Race-Conditions im Quellcode hier auf GitHub, aber das hat es nicht geschafft es noch in einer veröffentlichten Version).

Ich bin auf dasselbe Problem gestoßen, als ich die Snap-Version (1.6.2) des rpi-imager verwendet habe. Ich habe vielleicht sechs Mal versucht, es auszuführen, mit einer Vielzahl von Fehlern, einschließlich des Problems "firstrun.sh".
Ich habe die Snap-Version deinstalliert und die .deb-Datei (wiederum 1.6.2) direkt von www.raspberrypi.com/software heruntergeladen , und sie lief beim ersten Mal wie ein Zauber.
Danke an alle, die hier mitgewirkt haben!

Ich habe dieses Problem auf 1.6.2, das auf Ubuntu 20.04 installiert ist. Ich habe das Problem auf benutzerdefinierte Einstellungen beschränkt. Ich habe versucht, wifi und ssh einzustellen, und wenn ich eines oder beides tue, erhalte ich den Fehler firstrun.sh.

Ich habe dieses Problem auf 1.6.2, das auf Ubuntu 20.04 installiert ist.

Wie hast du Imager installiert?
.deb oder snap?

which rpi-imager 
/snap/bin/rpi-imager

/snap/bin/rpi-imager

Bitte hier melden: https://github.com/popey/imager-snap/issues/16
Deinstallieren Sie alternativ Snap und holen Sie sich stattdessen unser Paket: https://www.raspberrypi.com/software/

Ich führe das auf Ubuntu 18.04 aus.
rpi-imager 1.6 Release funktioniert.

Ich führe das auf Ubuntu 18.04 aus.

Angenommen, Sie verwenden Snap (da unsere .deb-Datei mindestens Ubuntu 20.04 benötigt), melden Sie dies bitte hier: https://github.com/popey/imager-snap/issues/16

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen