Rpi-imager: les options avancées ne fonctionnent pas sur windows 10

Quelle image écrivais-tu ?

Et avez-vous réellement vérifié sur le Pi que le processus sshd ne fonctionnait pas?
(Le simple fait de ne pas pouvoir se connecter peut avoir d'autres raisons).

Si au lieu de mettre la carte SD dans le Pi, vous la remettez dans votre ordinateur immédiatement après l'écriture, a-t-il créé un fichier nommé firstrun.sh sur la partition FAT ?

Et si ce n'est pas le cas, y a-t-il une différence selon que vous cochez ou non la case "éjecter le support une fois terminé" ?

Merci pour la réponse!

L'image est l'original Rasberry Pi OS (32-BIT) Date de sortie 2021-01-11
J'ai vérifié sur le Pi lui-même pour le ssh. Mais ce n'est pas seulement la fonction ssh enable qui ne fonctionne pas. Rien dans le menu des options ne fonctionne. J'ai également essayé les autres options. J'ai également essayé différentes cartes SD juste pour être sûr ;)

Je viens de vérifier et d'utiliser une autre carte SD, j'ai tout fait exactement comme avant et cela n'a pas créé de fichier appelé firstrun.sh.
la boîte d'éjection du support n'a pas été cochée.

D'ACCORD. Je regarde ce problème un peu plus loin et il semble que l'imageur ait un problème avec les grosses cartes SD et les clés USB.

J'ai essayé une carte SD de 16 Go et avec cet imageur de carte, j'ai produit le fichier firstrun.sh recherché. Les premières cartes SD que j'utilisais étaient de 32 et 128 Go. Ensuite, j'ai essayé un lecteur USB externe de 250 Go, mais sans succès. Pas de fichier firstrun.sh.
Donc le problème c'est peut-être la taille de la carte sd ?

la boîte d'éjection du support n'a pas été cochée

Le vérifier ne change rien ?

Votre lecteur conserve-t-il la même lettre de lecteur avant et après l'imagerie ?

cochez ou décochez la case d'éjection du support ne fait aucune différence Ma lettre de lecteur reste la même.

Pour l'instant, ce n'est pas un gros problème car je n'écris pas quotidiennement le système d'exploitation sur les cartes SD. Mais bon, la définition de ces options rend le processus d'installation du système d'exploitation plus pratique pour moi, car l'activation de ssh par défaut signifie que vous pouvez installer le système d'exploitation sans avoir besoin de connecter un écran au RPI. Vous pouvez configurer un RPI complètement par connexion à distance via ssh

Les premières cartes SD que j'utilisais étaient de 32 et 128 Go. Ensuite, j'ai essayé un lecteur USB externe de 250 Go, mais sans succès. Pas de fichier firstrun.sh.
Donc le problème c'est peut-être la taille de la carte sd ?

Il a été testé sur une carte SD Samsung de 64 Go et une carte Toshiba de 32 Go, donc la taille elle-même ne devrait pas être un problème.

Les clés USB plus récentes peuvent poser problème si elles utilisent le protocole UASP au lieu du protocole de stockage de masse USB standard.
J'ai un SSD Samsung T7, que Windows ne traite pas comme un stockage amovible mais comme un lecteur interne, et il ne lui attribue donc pas automatiquement de lettre de lecteur après l'imagerie. Au lieu de cela, vous devez accéder à la gestion des disques Windows et attribuer manuellement une lettre de lecteur pour qu'il puisse voir les fichiers sur la partition FAT.
Lors de l'utilisation de ce lecteur, Imager ne peut évidemment pas réparer les fichiers automatiquement, mais il affiche un message d'erreur clair dans ce cas :

Ce qui est différent de votre cas où les modifications que nous écrivons sur le disque sont perdues.

J'ai des problèmes similaires. J'obtiens une erreur "impossible d'écrire firstrun.sh". J'inclurais une capture d'écran mais++X est en conflit avec Snagit 2021, j'ai donc dû le désactiver. ;)

L'erreur s'est produite avec une carte SD de 32 Go mais pas avec une clé USB de 16 Go.

J'ai des problèmes similaires. J'obtiens une erreur "impossible d'écrire firstrun.sh".

Cela signifie que Windows a indiqué que la partition FAT a reçu une lettre de lecteur (sinon, vous obtenez "Le système d'exploitation n'a pas monté la partition FAT32"), mais l'ouverture du fichier en écriture a toujours échoué.
Peut-être y a-t-il un retard dans l'attribution d'une lettre de lecteur par Windows et lorsque le système de fichiers a terminé le montage.
Si tel est le cas, nous devrons peut-être réessayer plusieurs fois.

Après avoir reçu l'erreur, êtes-vous en mesure de voir les fichiers sur la partition FAT dans l'explorateur sans avoir à rebrancher la carte ou à faire quoi que ce soit de spécial ?

Je peux voir la partition FAT32 mais bien sûr pas de fichier firstrun.sh. Sur ma machine, c'est E: car j'ai 2 partitions sur mon disque dur (ne demandez pas). Mais c'est aussi E: pour la clé USB.

Je peux voir la partition FAT32 mais bien sûr pas de fichier firstrun.sh.

D'accord.
Pouvez-vous essayer si celui-ci fonctionne mieux?

imager-1.7beta.zip

Attend jusqu'à 3 secondes pour vérifier si config.txt existe sur la lettre de lecteur avant de procéder à l'écriture des modifications.

Fonctionne comme prévu. Testé avec une carte SD de 32 Go de la création au cycle de démarrage sur Pi 4.

Merci.

Fonctionne comme prévu.

Bon à entendre.

@ TeeSee64 pouvez-vous également essayer la version bêta ?
(Aucune idée si cela fait quelque chose pour votre problème, car vous avez des symptômes différents).

@maxnet
Oui! Je peux confirmer que le problème est résolu avec la version 1.7beta. Il écrit maintenant le fichier firstrun.sh et toutes les options fonctionnent. Fonctionne avec une carte SD de 128 Go et une clé USB de 250 Go

Merci !!

Salut @maxnet , j'ai eu le même problème que @CharlesGodwin. J'ai également essayé la version 1.7beta, mais malheureusement cela ne fonctionne pas pour moi. Seul le message d'erreur a changé en raison de vos modifications. Il affiche maintenant "Impossible de personnaliser. Le fichier 'I:\/config.txt' n'existe pas.".
Le problème peut être que la partition FAT32 est montée sur "J:\" au lieu de "I:\".
Je suis désolé mais je ne suis actuellement pas en mesure de faire d'autres analyses sur la raison pour laquelle il est monté sur "J:\" ou pourquoi l'imageur pense qu'il est monté sur "I:\", mais au moins je voulais partager cela avec vous .

Le problème peut être que la partition FAT32 est montée sur "J:\" au lieu de "I:\".

Hmm, je pense que nous avons eu des rapports sur des lettres de lecteur non publiées et qu'une nouvelle lettre de lecteur avait été attribuée au lecteur auparavant.
Comme : https://github.com/raspberrypi/rpi-imager/issues/31
Je n'ai jamais réussi à reproduire de tels problèmes. Donc aucune idée de ce qui le cause.
Peut-être quelque chose qui verrouille le lecteur (un service système ou un antivirus ?)

Ou la carte n'était-elle jamais disponible chez I: avant ?
Quelle lettre de lecteur s'est affichée lorsque vous avez sélectionné le lecteur dans Imager ?

Imager suppose que le premier volume que Windows nous dit est associé au lecteur est la partition FAT que nous recherchons.
Je ne sais pas s'il existe un meilleur mécanisme, comme rechercher tous les volumes associés au lecteur pour config.txt à la place.

Si vous démarrez "diskpart" à partir d'une invite de commande et que vous tapez "list volumes", affiche-t-il à la fois I: et J: ?
Peut également essayer de les sélectionner avec "select volume [number of volume]", et voir si "detail volume" (et "detail partition" "detail disk") imprime quelque chose qui sort de l'ordinaire.

Peut-être quelque chose qui verrouille le lecteur (un service système ou un antivirus ?)

Ne pense pas.

Quelle lettre de lecteur s'est affichée lorsque vous avez sélectionné le lecteur dans Imager ?

La carte, qui a déjà été imagée, affiche "Mounted as I:\,J:\" (traduit, en utilisant la version allemande).
J'ai aussi essayé avec une carte inutilisée. Il affiche "Mounted as J:\" (I:\ manque complètement, également dans l'explorateur. Ne me demandez pas pourquoi ...)

Si vous démarrez "diskpart" à partir d'une invite de commande et que vous tapez "list volumes", affiche-t-il à la fois I: et J: ?

Non, il n'y a que J:\. Mais dans l'explorateur, il affiche les deux, I:\ et J:\.

Imager suppose que le premier volume que Windows nous dit est associé au lecteur est la partition FAT que nous recherchons.

Cela semble être le problème.

@maxnet Juste une idée...
Peut-être l'indexeur de recherche Windows ? Parfois, lorsque j'essaie de retirer en toute sécurité une carte SD de mon ordinateur, c'est impossible car l'indexeur de recherche Windwos est occupé sur cette carte. après quelques instants, l'indexeur est prêt et le retrait en toute sécurité est possible.

Peut-être l'indexeur de recherche Windows ?

Nous sous-traitons l'effacement de la table de partition au démarrage de Imaging à l'utilitaire diskpart de Microsoft, dans l'espoir qu'il sache comment faire en sorte que chaque service Microsoft cesse d'utiliser le lecteur et libère correctement tous les verrous/lettres de lecteur.
Outre les services système, il existe également des programmes tiers qui aiment réclamer et garder ouvert un fichier dans "\System Volume Information" sur chaque lecteur.
Par exemple, je me souviens que Symantec Endpoint Security est connu pour tenir une comptabilité sur les fichiers déjà analysés et les signatures de ces fichiers là-bas.
C'est pourquoi j'ai mentionné les antivirus.

@CRGer

Pouvez-vous essayer si celui-ci fonctionne mieux?

imager-20210322.zip

Devrait rechercher tous les points de montage associés au lecteur pour config.txt au lieu du premier.

@maxnet Même si la lettre de lecteur montée automatiquement change avant et après l'écriture de l'image, je suppose que le numéro de disque physique ne changera pas? Alors peut-être pourriez-vous utiliser certains éléments WMI pour corréler les lettres de lecteur avant et après le flashage de l'image? :shrug: Alternativement, je suppose que vous pourriez utiliser la taille du disque brut, car il est probablement peu probable que l'utilisateur ait deux disques avec la même taille brute exacte connectés ? (et cela ne changera pas non plus avant/après le clignotement)

@maxnet Même si la lettre de lecteur montée automatiquement change avant et après l'écriture de l'image, je suppose que le numéro de disque physique
ne changera pas ? Alors peut-être pourriez-vous utiliser certains éléments WMI pour corréler les lettres de lecteur avant et après le flashage de l'image?

Nous récupérons déjà la liste des volumes appartenant à ce numéro de lecteur physique après la création d'image.

Cependant, dans le cas de CRGer, deux volumes sont renvoyés (I: et J:) comme appartenant à ce lecteur physique .
Notre code supposait auparavant que le premier était la partition FAT, mais dans son cas, le second est le seul volume valide.
Le nouveau code doit analyser les deux volumes renvoyés pour config.txt

Cela peut se terminer par un jeu de wack a taupe. peut-être coder dans une boîte de dialogue "De quel lecteur s'agit-il, s'il vous plaît" lorsque tout le reste échoue.

Ahh, j'ai mal compris, désolé pour le bruit ! :clin d'œil:

Pouvez-vous essayer si celui-ci fonctionne mieux?

Je l'ai essayé et cela fonctionne comme prévu. "firstrun.sh" a été créé sur ma partition FAT avec toutes les configurations sélectionnées. Bon travail @maxnet , merci !

Je vois ce problème sur Ubuntu en essayant d'écrire Raspberry PI OS Lite, il semble qu'il n'attende pas assez longtemps pour que la partition de démarrage se monte, avant d'essayer d'écrire le firstrun.sh sur la partition. Existe-t-il une version avec un délai plus long pour Ubuntu ?

De plus, plutôt qu'une attente arbitraire de 3 secondes, qu'en est-il simplement de tester si vous pouvez accéder à la partition en boucle pendant, disons, 60 secondes avant de commettre une erreur ou quelque chose du genre ?

Je vois ce problème sur Ubuntu en essayant d'écrire Raspberry PI OS Lite, il semble qu'il n'attende pas assez longtemps pour le démarrage
partition à monter, avant d'essayer d'écrire le firstrun.sh sur la partition. Existe-t-il une version avec un délai plus long pour Ubuntu ?

Celui-ci fonctionne-t-il mieux ?

rpi-imager-ubuntu-20210324.zip

De plus, plutôt qu'une attente arbitraire de 3 secondes, qu'en est-il simplement de tester si vous pouvez accéder à la partition en boucle pendant, disons, 60
secondes avant erreur ou quelque chose?

Pour référence : il faut 0,008 seconde avant que la partition FAT ne soit montée sur mon ordinateur Ubuntu.

Je vois ce problème sur Ubuntu en essayant d'écrire Raspberry PI OS Lite, il semble qu'il n'attende pas assez longtemps pour le démarrage
partition à monter, avant d'essayer d'écrire le firstrun.sh sur la partition. Existe-t-il une version avec un délai plus long pour Ubuntu ?

BTW avez-vous déjà utilisé le .deb du site Web Raspberry Pi, ou le composant logiciel enfichable fourni par canonique ?

Comme quelqu'un d'autre le mentionne, le problème ne se produit que sur le snap: https://www.raspberrypi.org/forums/viewtopic.php?f=63&p=1842486

pourquoi l'imageur rpi d'Ubuntu est-il discuté dans un problème intitulé les options avancées ne fonctionnent pas sur Windows 10

personne ne le trouvera

pourquoi l'imageur rpi d'Ubuntu est-il discuté dans un problème intitulé les options avancées ne fonctionnent pas sur Windows 10

C'est plus un problème avec le titre, que ce sont des problèmes différents.

Le problème dans les deux cas est le même.
Le système d'exploitation signale qu'un montage est terminé, alors qu'il n'est pas encore prêt.

Cela ne devrait PAS arriver sur les systèmes Linux normaux.
Mais cela peut arriver dans le package snap tiers que nous n'avons pas créé.
Eh bien, en tant qu'effet secondaire de la résolution de ce problème sous Windows, cela peut également résoudre le problème de snap ...

Je suppose que le problème _pourrait_ être renommé en "options avancées n'écrivant pas les paramètres sur la carte SD", mais cela ne semble pas en valoir la peine si @maxnet a déjà un correctif potentiel en main ? :visage_légèrement_souriant:

Je suppose que le problème pourrait être renommé en "options avancées n'écrivant pas les paramètres sur la carte SD", mais cela ne semble pas en valoir la peine si @maxnet
a déjà une solution potentielle en main ?

Je soupçonne que le problème est déjà résolu.
Mais laissez cela ouvert pour l'instant, pour empêcher les autres utilisateurs de 1.6 (au lieu de git latest) d'ouvrir un nouveau problème.

Corrigé dans 1.6.1