Rpi-imager: Erreur : erreur lors de la création de firstrun.sh sur la partition fat lors de l'exécution sur MacOS

Créé le 8 avr. 2021  ·  23Commentaires  ·  Source: raspberrypi/rpi-imager

Lors de l'utilisation de l'imageur à la v. 1.6.1 sur un système d'exploitation Mac Big Sur (V 11.2.3), nous voyons cette erreur de manière constante.
Error creating firstrun.sh on FAT partition
J'ai vu des rapports sur le même problème sur Windows éventuellement résolu par une version bêta 1.7. Existe-t-il également une telle version bêta pour le Mac?
Les cartes microSD font 16 Go et utilisent un adaptateur de carte SD Anker USB-C.

Commentaire le plus utile

J'ai rencontré le même problème lors de l'utilisation de la version Snap (1.6.2) du rpi-imager. J'ai essayé de l'exécuter peut-être six fois, avec une variété d'erreurs, y compris le problème "firstrun.sh".
J'ai désinstallé la version Snap et téléchargé le .deb (encore une fois, 1.6.2) directement depuis www.raspberrypi.com/software , et cela a fonctionné comme un charme la première fois.
Merci à tous ceux qui ont contribué ici !

Tous les 23 commentaires

La version bêta 1.7 a été renommée 1.6.1, car il n'y avait que de petits changements.
Donc, vous l'exécutez déjà.

Je ne sais pas quel est le problème ici.
Imager est capable de créer le fichier avec succès sur mon Mac Mini (avec un lecteur USB-C de marque inconnue qui ressemble à ceci )

Screenshot 2021-04-08 at 19 23 32

Après l'échec, vous pouvez accéder à l'emplacement "boot" dans "Finder" et ouvrir, disons, config.txt, y ajouter une ligne de texte aléatoire et "menu file" -> "save" le fichier ?
Il ne se plaint pas que l'appareil soit en lecture seule ou quoi que ce soit qui sorte de l'ordinaire ?

Je vois des problèmes similaires aussi. Le fichier firstrun.sh n'existait pas lors de ma première tentative de flash, mais il s'est affiché lors de la deuxième tentative, en utilisant la v1.6.1 de l'imageur. Cependant, je ne parviens toujours pas à me connecter en ssh au Raspberry Pi. J'utilise une carte mémoire microSD Samsung Evo+ 32 Go avec le lecteur de carte microSD USB CanaKit.

Le fichier firstrun.sh n'existait pas lors de ma première tentative de flash, mais il s'est affiché lors de la deuxième tentative, en utilisant la v1.6.1 de l'imageur.

Et vous avez obtenu la même erreur "erreur lors de la création de firstrun.sh sur la partition FAT" en tant que démarreur de problème lors de votre première tentative ?

(Notez que firstrun.sh est supprimé par le Pi au premier démarrage)

Je n'ai jamais vu d'erreur à l'une ou l'autre tentative. J'ai essayé de démarrer avant de regarder le système de fichiers lors de la première tentative, c'est peut-être pourquoi le fichier n'existait pas. En faisant des recherches sur le problème, je suis tombé sur des mentions où les gens avaient des problèmes de connexion aux points d'accès WiFi 5 GHz en général. Lors d'une troisième tentative, j'ai changé le SSID WiFi du point d'accès 5 GHz à la version 2,4 GHz et tout semblait fonctionner correctement. Donc, mon problème peut en fait être lié à un accès WiFi 5 contre 2,4 au lieu du Raspberry Pi Imager lui-même.

Donc, mon problème peut en fait être lié à un accès WiFi 5 contre 2,4 au lieu du Raspberry Pi Imager lui-même.

Oui, cela semble probable. Je ne vois aucune raison pour laquelle RPi Imager lui-même ne fonctionnerait pas lors des deux premières tentatives, mais fonctionnerait comme par magie lors de la 3ème tentative :wink: (surtout si vous n'avez jamais vu de messages d'erreur dans Raspberry Pi Imager)

Désolé pour la réponse tardive. Il s'est avéré qu'il s'agissait bien d'une restriction d'écriture sur un périphérique USB. J'avais négligé cela comme problème dû au fait que le système d'exploitation lui-même écrivait bien. C'était seulement la copie du fichier firstrun qui échouait. Apparemment, la vérification de l'écriture USB doit être effectuée à un niveau supérieur et l'écriture du système d'exploitation de bas niveau était correcte. En tout cas une fois cette restriction levée, tout va bien. Je suis d'accord pour fermer ce sujet, cependant, puisqu'il semble avoir suscité un autre intérêt, je le laisse à d'autres.

Désolé pour la réponse tardive. Il s'est avéré qu'il s'agissait bien d'une restriction d'écriture sur un périphérique USB.

Est-ce un paramètre de Mac OS X lui-même, ou quelque chose introduit par un logiciel de sécurité tiers généralement utilisé uniquement dans les grandes entreprises pour restreindre ce que les utilisateurs peuvent et ne peuvent pas faire ?
Je me demandais simplement, au cas où d'autres utilisateurs signaleraient des problèmes similaires.

C'était ce dernier. Restriction à l'échelle de l'entreprise sur l'écriture USB. Dérogations autorisées pour des cas particuliers. Une fois que nous avons obtenu une exemption, tout allait bien.

Restriction à l'échelle de l'entreprise sur l'écriture USB.

Un peu ironique que le "logiciel de sécurité" ne bloque pas l'écriture de bas niveau, car je suppose que cela pourrait théoriquement être utilisé pour contourner les restrictions d'accès de niveau supérieur :wink:

Merci pour l'info.
Le problème étant résolu, je ferme celui-ci.

Version 1.6.0 et peut confirmer l'échec du processus d'écriture (options avancées/masquées). Le processus d'écriture d'Img fonctionne parfaitement. Ce n'est pas un gros problème mais devrait certainement être résolu car cela ne fait qu'introduire de la confusion et du travail supplémentaire.

Version 1.6.0 et peut confirmer l'échec du processus d'écriture (options avancées/masquées).

Concerne également un ordinateur d'entreprise avec un logiciel de sécurité ?
Sinon, ce n'est pas le même problème.

Version 1.6.0 et peut confirmer l'échec du processus d'écriture (options avancées/masquées).

Concerne également un ordinateur d'entreprise avec un logiciel de sécurité ? Sinon, ce n'est pas le même problème.

Mon mauvais, c'est la nuit et j'ai raté certaines choses/contexte OP.
Ordinateur personnel Windows 10 (avec Bitdefender).

Édition 1.6.0
Ordinateur personnel Windows 10 (avec Bitdefender).

Nous vous suggérons de passer d'abord à la version 1.6.2 et d'ouvrir un nouveau problème répertoriant le message d'erreur exact si cela échoue également.

J'ai rencontré le même problème avec l'imageur 1.6.2 sur une machine Ubuntu sur laquelle aucun logiciel de sécurité particulier n'est installé, donc je ne pense pas que ce soit lié à cela.
Cela s'est produit lors d'une exécution où j'ai défini des options (Ctrl + Maj + X) pour définir un nom d'hôte, activer SSH et Wifi.

Lors de la deuxième tentative, j'ai également défini les options de configuration d'un fuseau horaire et d'un clavier, et ignoré l'assistant de première exécution, mais l'erreur persiste.

Lorsque je ne configure aucune option, l'imageur fonctionne correctement.

Il n'y a pas de sortie d'erreur sur la ligne de commande.

J'ai rencontré le même problème avec l'imageur 1.6.2 sur une machine Ubuntu sur laquelle aucun logiciel de sécurité particulier n'est installé, donc je ne pense pas que ce soit lié à cela.

Ce problème particulier concerne MacOS avec un logiciel de sécurité d'entreprise installé.
Vous voudrez peut-être en ouvrir un autre pour Ubuntu.

Si vous avez installé Imager sur Ubuntu via snap (centre logiciel Ubuntu), le bon endroit serait ici : https://github.com/popey/imager-snap/issues/16
Notez que nous n'avons pas créé ce package snap, il est fourni par un tiers, et comme il s'exécute dans un environnement sandbox, il se comporte différemment de notre version.

Si vous avez téléchargé le package .deb à partir du site Web de Raspberry Pi, essayez s'il fonctionne mieux si vous désactivez le montage automatique dans Ubuntu.
Si cela fonctionne mieux si vous modifiez le paramètre de montage automatique, il est probablement déjà corrigé dans la prochaine version de l'imageur (il existe un correctif pour gérer les conditions de course de montage automatique dans le code source ici sur github, mais cela n'a pas fait dans une version publiée pour le moment).

J'ai rencontré le même problème lors de l'utilisation de la version Snap (1.6.2) du rpi-imager. J'ai essayé de l'exécuter peut-être six fois, avec une variété d'erreurs, y compris le problème "firstrun.sh".
J'ai désinstallé la version Snap et téléchargé le .deb (encore une fois, 1.6.2) directement depuis www.raspberrypi.com/software , et cela a fonctionné comme un charme la première fois.
Merci à tous ceux qui ont contribué ici !

J'ai ce problème sur 1.6.2 installé sur Ubuntu 20.04. J'ai isolé le problème d'avoir des paramètres personnalisés. J'ai essayé de définir le wifi et le ssh et si je fais l'une de ces choses ou les deux, j'obtiens l'erreur firstrun.sh.

J'ai ce problème sur 1.6.2 installé sur Ubuntu 20.04.

Comment avez-vous installé Imager ?
.deb ou snap ?

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

/snap/bin/rpi-imageur

Veuillez signaler ici : https://github.com/popey/imager-snap/issues/16
Vous pouvez également désinstaller le composant logiciel enfichable et obtenir notre package à la place : https://www.raspberrypi.com/software/

Je l'exécute sur Ubuntu 18.04.
La version 1.6 de rpi-imager fonctionne.

Je l'exécute sur Ubuntu 18.04.

En supposant que vous utilisez le composant logiciel enfichable (car notre .deb nécessite au moins Ubuntu 20.04), veuillez signaler ici : https://github.com/popey/imager-snap/issues/16

Cette page vous a été utile?
0 / 5 - 0 notes