Rpi-imager: Erweiterte Optionen funktionieren nicht unter Windows 10

Welches Bild hast du geschrieben?

Und haben Sie tatsächlich auf dem Pi überprüft, dass der sshd-Prozess nicht lief?
(Nur nicht in der Lage zu sein, eine Verbindung herzustellen, kann andere Gründe haben).

Wenn Sie die SD-Karte nicht in den Pi stecken, sondern sofort nach dem Schreiben wieder in Ihren Computer stecken, hat er dann eine Datei namens firstrun.sh auf der FAT-Partition erstellt?

Und wenn nicht, gibt es einen Unterschied, je nachdem, ob Sie das Kontrollkästchen „Medien auswerfen, wenn fertig“ aktiviert haben?

Danke für die Antwort!

Das Bild ist das ursprüngliche Rasberry Pi OS (32-BIT) Erscheinungsdatum 2021-01-11
Ich habe auf dem Pi selbst nach dem ssh gesucht. Aber es ist nicht nur die Funktion ssh enable, die nicht funktioniert. Nichts im Optionsmenü funktioniert. Habe auch die anderen Möglichkeiten probiert. Zur Sicherheit auch verschiedene SD-Karten probiert ;)

Ich habe gerade eine andere SD-Karte überprüft und verwendet, alles genau wie zuvor gemacht und es wurde keine Datei namens firstrun.sh erstellt.
Medienbox auswerfen war deaktiviert.

OK. Ich sehe mir dieses Problem etwas genauer an und es scheint, dass der Imager ein Problem mit großen SD-Karten und USB-Laufwerken hat.

Ich habe eine 16 GB SD-Karte ausprobiert und mit diesem Card Imager die gewünschte firstrun.sh-Datei erstellt. Die ersten SD-Karten, die ich benutzte, waren 32 und 128 GB. Als nächstes versuchte ich es mit einem externen 250-GB-USB-Laufwerk, aber ohne Erfolg. Keine firstrun.sh-Datei.
Das Problem ist also vielleicht die Größe der SD-Karte?

Medienbox auswerfen war deaktiviert

Kontrollieren bringt nichts?

Ihr Laufwerk behält vor und nach dem Imaging denselben Laufwerksbuchstaben?

Kontrollkästchen Medien auswerfen aktivieren oder deaktivieren macht keinen Unterschied. Mein Laufwerksbuchstabe bleibt gleich.

Im Moment ist es keine große Sache, da ich OS nicht täglich auf SD-Karten schreibe. Aber hey, das Festlegen dieser Optionen macht die Installation des Betriebssystems für mich praktischer, da das standardmäßige Aktivieren von ssh bedeutet, dass Sie das Betriebssystem installieren können, ohne einen Bildschirm mit dem RPI verbinden zu müssen. Sie können ein RPI vollständig per Fernverbindung über ssh einrichten

Die ersten SD-Karten, die ich benutzte, waren 32 und 128 GB. Als nächstes versuchte ich es mit einem externen 250-GB-USB-Laufwerk, aber ohne Erfolg. Keine firstrun.sh-Datei.
Das Problem ist also vielleicht die Größe der SD-Karte?

Es wurde auf einer 64 GB Samsung SD-Karte und 32 GB Toshiba getestet, also sollte die Größe selbst kein Problem sein.

Neuere USB-Laufwerke können ein Problem darstellen, wenn sie das UASP-Protokoll anstelle des standardmäßigen USB-Massenspeicherprotokolls sprechen.
Ich habe eine Samsung T7 SSD, die Windows nicht als Wechseldatenträger, sondern als internes Laufwerk behandelt und ihr daher nach dem Imaging keinen Laufwerksbuchstaben automatisch zuweist. Stattdessen müssen Sie in die Windows-Datenträgerverwaltung gehen und manuell einen Laufwerksbuchstaben zuweisen, damit sie die Dateien auf der FAT-Partition überhaupt sehen kann.
Bei Verwendung dieses Laufwerks kann Imager die Dateien natürlich nicht automatisch reparieren, zeigt in diesem Fall jedoch eine eindeutige Fehlermeldung an:

Dies unterscheidet sich von Ihrem Fall, dass die Änderungen, die wir auf die Festplatte schreiben, verloren gehen.

Ich habe ähnliche Probleme. Ich erhalte die Fehlermeldung „firstrun.sh kann nicht geschrieben werden“. Ich würde aber einen Screenshot einfügen++X steht in Konflikt mit Snagit 2021, daher musste ich es deaktivieren. ;)

Der Fehler trat bei einer 32GB SD Karte auf aber nicht bei einem 16GB USB Stick.

Ich habe ähnliche Probleme. Ich erhalte die Fehlermeldung „firstrun.sh kann nicht geschrieben werden“.

Das bedeutet, dass Windows angezeigt hat, dass der FAT-Partition ein Laufwerksbuchstabe zugewiesen wurde (andernfalls erhalten Sie stattdessen „Betriebssystem hat FAT32-Partition nicht bereitgestellt“), aber das Öffnen der Datei zum Schreiben ist immer noch fehlgeschlagen.
Möglicherweise gibt es eine Verzögerung bei der Zuweisung eines Laufwerksbuchstabens durch Windows und wenn das Dateisystem das Mounten beendet hat.
In diesem Fall müssen wir es möglicherweise mehrmals wiederholen.

Nachdem Sie den Fehler erhalten haben, können Sie die Dateien auf der FAT-Partition im Explorer sehen, ohne die Karte erneut anschließen oder etwas Besonderes tun zu müssen?

Ich kann die FAT32-Partition sehen, aber natürlich keine firstrun.sh-Datei. Auf meinem Rechner ist es E: da ich 2 Partitionen auf meiner Festplatte habe (nicht fragen). Aber es ist auch E: für den USB-Stick.

Ich kann die FAT32-Partition sehen, aber natürlich keine firstrun.sh-Datei.

OK.
Können Sie versuchen, ob dieser besser funktioniert?

imager-1.7beta.zip

Wartet bis zu 3 Sekunden und überprüft, ob config.txt auf dem Laufwerksbuchstaben vorhanden ist, bevor mit dem Schreiben der Änderungen fortgefahren wird.

Funktioniert wie erwartet. Getestet mit 32-GB-SD-Karte von der Erstellung bis zum Startzyklus auf Pi 4.

Danke.

Funktioniert wie erwartet.

Gut zu hören.

@TeeSee64 kannst du auch die Beta ausprobieren?
(Keine Ahnung, ob es etwas für Ihr Problem tut, da Sie unterschiedliche Symptome haben).

@maxnet
Jawohl! Ich kann bestätigen, dass das Problem mit der 1.7beta-Version behoben ist. Es schreibt jetzt die Datei firstrun.sh und alle Optionen funktionieren. Funktioniert sowohl mit 128 GB SD-Karte als auch mit einem 250 GB USB-Laufwerk

Danke !!

Hallo @maxnet , ich hatte das gleiche Problem wie @CharlesGodwin. Habe auch die 1.7beta probiert, aber leider funktioniert es bei mir nicht. Nur die Fehlermeldung hat sich aufgrund Ihrer Änderungen geändert. Es zeigt jetzt "Anpassen nicht möglich. Datei 'I:\/config.txt' existiert nicht.".
Das Problem könnte sein, dass die FAT32-Partition auf „J:\“ statt auf „I:\“ gemountet ist.
Es tut mir leid, aber ich bin derzeit nicht in der Lage, weiter zu analysieren, warum es auf "J:\" gemountet ist oder warum der Imager denkt, dass es auf "I:\" gemountet ist, aber zumindest wollte ich dies mit Ihnen teilen .

Das Problem könnte sein, dass die FAT32-Partition auf „J:\“ statt auf „I:\“ gemountet ist.

Hmm, ich glaube, wir hatten Berichte darüber, dass Laufwerksbuchstaben nicht freigegeben wurden und dem Laufwerk zuvor ein neuer Laufwerksbuchstabe zugewiesen wurde.
Wie: https://github.com/raspberrypi/rpi-imager/issues/31
Habe es aber nie geschafft, solche Probleme zu reproduzieren. Also keine Ahnung woran das liegt.
Vielleicht hält etwas eine Sperre auf dem Laufwerk (ein Systemdienst oder Virenscanner?)

Oder war die Karte noch nie bei I: erhältlich?
Welcher Laufwerksbuchstabe wurde angezeigt, als Sie das Laufwerk in Imager ausgewählt haben?

Imager geht davon aus, dass das erste Volume, von dem Windows uns mitteilt, dass es mit dem Laufwerk verknüpft ist, die FAT-Partition ist, nach der wir suchen.
Ich bin mir nicht sicher, ob es einen besseren Mechanismus gibt, wie zum Beispiel alle mit dem Laufwerk verbundenen Volumes nach config.txt zu durchsuchen.

Wenn Sie "diskpart" an einer Eingabeaufforderung starten und "list volume" eingeben, werden dort sowohl I: als auch J: angezeigt?
Versuchen Sie auch, sie mit "Volume auswählen [Nummer des Volumes]" auszuwählen, und prüfen Sie, ob "Detail Volume" (und "Detail Partition" "Detail Disk") etwas Ungewöhnliches druckt.

Vielleicht hält etwas eine Sperre auf dem Laufwerk (ein Systemdienst oder Virenscanner?)

Denke nicht.

Welcher Laufwerksbuchstabe wurde angezeigt, als Sie das Laufwerk in Imager ausgewählt haben?

Auf der bereits abgebildeten Karte steht „Mounted as I:\,J:\“ (übersetzt, mit deutscher Version).
Habe es auch mit einer unbenutzten Karte probiert. Es zeigt "Mounted as J:\" an (I:\ fehlt komplett, auch im Explorer. Frag mich nicht warum...)

Wenn Sie "diskpart" an einer Eingabeaufforderung starten und "list volume" eingeben, werden dort sowohl I: als auch J: angezeigt?

Nein, dort wird nur J:\ angezeigt. Aber im Explorer zeigt es beides, I:\ und J:\.

Imager geht davon aus, dass das erste Volume, von dem Windows uns mitteilt, dass es mit dem Laufwerk verknüpft ist, die FAT-Partition ist, nach der wir suchen.

Das scheint das Problem zu sein.

@maxnet Nur eine Idee ...
Vielleicht der Windows-Suchindexer? Manchmal, wenn ich versuche, eine SD-Karte sicher von meinem Computer zu entfernen, ist es unmöglich, weil der Suchindexer von windwos auf dieser Karte beschäftigt ist. nach wenigen Augenblicken ist der Indexer bereit und ein sicheres Entfernen ist möglich.

Vielleicht der Windows-Suchindexer?

Wir lagern das Löschen der Partitionstabelle beim Start von Imaging an das diskpart-Dienstprogramm von Microsoft aus, in der Hoffnung, dass es weiß, wie man jeden Microsoft-Dienst dazu bringt, die Verwendung des Laufwerks einzustellen und alle Sperren/Laufwerksbuchstaben ordnungsgemäß freizugeben.
Abgesehen von Systemdiensten gibt es auch Programme von Drittanbietern, die gerne eine Datei in "\System Volume Information" auf jedem Laufwerk beanspruchen und offen halten.
Ich erinnere mich zB, dass Symantec Endpoint Security dafür bekannt ist, Buch darüber zu führen, welche Dateien es bereits gescannt hat, und Signaturen dieser Dateien dort.
Deshalb habe ich Virenscanner erwähnt.

@CRGer

Können Sie versuchen, ob dieser besser funktioniert?

imager-20210322.zip

Sollte alle Mountpoints, die mit dem Laufwerk verbunden sind, nach config.txt durchsuchen, anstatt nur nach dem ersten.

@maxnet Selbst wenn sich der automatisch gemountete Laufwerksbuchstabe vor und nach dem Schreiben des Images ändert, gehe ich davon aus, dass sich die Nummer der physischen Festplatte nicht ändert? Vielleicht könnten Sie einige der WMI-Sachen verwenden, um Laufwerksbuchstaben vor und nach dem Flashen des Images zu korrelieren? :shrug: Alternativ könnten Sie wohl auch die Raw-Laufwerksgröße verwenden, da es wahrscheinlich unwahrscheinlich ist, dass der Benutzer zwei Laufwerke mit genau derselben Raw-Größe angeschlossen hat? (und das ändert sich auch nicht vor/nach dem flashen)

@maxnet Auch wenn sich der automatisch gemountete Laufwerksbuchstabe vor und nach dem Schreiben des Images ändert, gehe ich von der Nummer der physischen Festplatte aus
wird sich nicht ändern? Vielleicht könnten Sie einige der WMI-Sachen verwenden, um Laufwerksbuchstaben vor und nach dem Flashen des Images zu korrelieren?

Wir rufen bereits nach dem Imaging die Liste der Volumes ab, die zu dieser physischen Laufwerksnummer gehören.

Im Fall von CRGer werden jedoch zwei Volumes (I: und J:) als zu diesem physischen Laufwerk gehörend zurückgegeben.
Unser Code ging zuvor davon aus, dass die erste eine FAT-Partition ist, aber in seinem Fall ist die zweite das einzig gültige Volume.
Neuer Code sollte beide zurückgegebenen Volumes nach config.txt scannen

Es kann zu einem Maulwurfspiel werden. vielleicht Code in einem Dialogfeld "Welches Laufwerk ist es, bitte", wenn alles andere fehlschlägt.

Ahh, falsch verstanden, Entschuldigung für den Lärm! :zwinkern:

Können Sie versuchen, ob dieser besser funktioniert?

Habe es ausprobiert und es funktioniert wie erwartet. "firstrun.sh" wurde auf meiner FAT-Partition mit allen ausgewählten Konfigurationen erstellt. Gute Arbeit @maxnet , danke!

Ich sehe dieses Problem auf Ubuntu, das versucht, Raspberry PI OS Lite zu schreiben. Es scheint, als würde es nicht lange genug warten, bis die Boot-Partition bereitgestellt wird, bevor versucht wird, firstrun.sh auf die Partition zu schreiben. Gibt es einen Build mit einer längeren Verzögerung für Ubuntu?

Anstelle einer willkürlichen Wartezeit von 3 Sekunden, was wäre, wenn Sie einfach testen würden, ob Sie in einer Schleife für beispielsweise 60 Sekunden auf die Partition zugreifen können, bevor Sie einen Fehler machen oder so?

Ich sehe dieses Problem auf Ubuntu, das versucht, Raspberry PI OS Lite zu schreiben, es scheint, als würde es nicht lange genug auf den Start warten
zu mountende Partition, bevor Sie versuchen, firstrun.sh auf die Partition zu schreiben. Gibt es einen Build mit einer längeren Verzögerung für Ubuntu?

Funktioniert dieser besser?

rpi-imager-ubuntu-20210324.zip

Anstatt willkürlich 3 Sekunden zu warten, was wäre, wenn Sie einfach testen würden, ob Sie in einer Schleife für beispielsweise 60 auf die Partition zugreifen können
Sekunden vor dem Fehler oder so?

Als Referenz: Es dauert 0,008 Sekunden, bis die FAT-Partition auf meinem Ubuntu-Computer gemountet ist.

Ich sehe dieses Problem auf Ubuntu, das versucht, Raspberry PI OS Lite zu schreiben, es scheint, als würde es nicht lange genug auf den Start warten
zu mountende Partition, bevor Sie versuchen, firstrun.sh auf die Partition zu schreiben. Gibt es einen Build mit einer längeren Verzögerung für Ubuntu?

Übrigens haben Sie zuvor die .deb-Datei von der Raspberry Pi-Website oder den von Canonical bereitgestellten Snap verwendet?

Wie jemand anderes erwähnt, tritt das Problem nur beim Snap auf: https://www.raspberrypi.org/forums/viewtopic.php?f=63&p=1842486

warum wird der Ubuntu rpi-imager in einer Ausgabe mit dem Titel „ Erweiterte Optionen, die unter Windows 10 nicht funktionieren “ diskutiert

niemand wird es finden

warum wird der Ubuntu rpi-imager in einer Ausgabe mit dem Titel „Erweiterte Optionen, die unter Windows 10 nicht funktionieren“ diskutiert

Das ist eher ein Problem mit dem Titel, als dass es andere Probleme sind.

Das Problem ist in beiden Fällen das gleiche.
Das Betriebssystem meldet, dass ein Mount fertig ist, obwohl es eigentlich noch nicht bereit ist.

Dies sollte auf normalen Linux-Systemen NICHT passieren.
Kann aber in Snap-Paketen von Drittanbietern vorkommen, die wir nicht erstellt haben.
Na ja, als Nebeneffekt der Umgehung dieses Problems unter Windows kann es auch das Snap-Problem umgehen ...

Ich schätze, das Problem _könnte_ in „Erweiterte Optionen, die keine Einstellungen auf die SD-Karte schreiben“ umbenannt werden, aber es scheint sich nicht zu lohnen, wenn @maxnet bereits eine mögliche Lösung in der Hand hat? :leicht_lächelndes_gesicht:

Ich denke, das Problem könnte in "Erweiterte Optionen, die keine Einstellungen auf die SD-Karte schreiben" umbenannt werden, aber es scheint sich nicht zu lohnen, wenn @maxnet
hat bereits eine mögliche Lösung in der Hand?

Ich vermute, dass das Problem bereits behoben ist.
Aber lassen Sie dies vorerst offen, um zu verhindern, dass andere, die 1.6 (anstelle von Git Latest) verwenden, ein neues Problem eröffnen.

Behoben in 1.6.1