Ratage démarrage Raspberry pi 3 sur clé usb

Bonjour,

Je viens de suivre différents tutaux pour démarrer le raspberry pi 3 sur clé usb. J’ai installé raspbian pixel sur la micro sd en utilisant diskimager. Le raspberry a bien démarré sur la micro sd et tout va bien de ce côté.
J’ai une clé SanDisk Cruzer blade 32G et le tuto pourtant très clair : http://www.framboise314.fr/bootez-votre-raspberry-pi-3-sur-une-cle-usb/.
Alors, je pense pouvoir dire que tout va bien jusqu’au moment de la régénération des ssh et plus précisement le moment où je dois démonter :
pi@raspberrypi:/mnt/target $ sudo umount devumount: /mnt/target/dev: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).)

Je précise que cette clé est sensée fonctionner.
D’autre part en lançant un cat boot/cmdline.txt je vois bien mon root=dev/sda2/

Mais quand j’éteint et que je rallume après avoir enlevé la micro carte il démarre et s’arrête
hid-generic 0003:1C4F:0016.0005: usb_submit_urb9ctrl0 failed: -1

J’utilise le rqspberry pi en classe et l’achat de cartes micro sd commence à me coûter cher:slight_smile:
Dans l’absolu j’aimerais avoir un raspberry “serveur” qui démarre sur clé ou DD et les autres pi en “client” sans micro-sd.

Je suis preneur de tout conseil.

Bonjour,

C’est peux être un peux con ce que je vais dire mais lorsque tu demande à démonter target/dev ça te dis donc que c’est impossible car la ressources target est occupé (ce qui est normal vu que je vois que tu es présent dans ce fameux dossier target “pi@raspberrypi:/mnt/target $”), mais est ce que tu as déjà essayé de revenir à la racine cd / et de refaire
sudo umount /mnt/target/dev ?

Bonjour,

J’ai aussi utilisé ce tuto et la fameuse mise a jour “sudo apt-get update; sudo apt-get install rpi-update
sudo BRANCH=next rpi-update” et depuis mon Pi 3 ne veut plus que du raspbian jessie pas moyen de lui faire "manger autre chose, par contre pour booter sur usb tu peux tenter ce tuto
https://www.g33k-zone.org/post/2016/04/26/Démarrer-son-Raspberry-Pi-sur-un-disque-dur
tu dois laisser la sd en place mais elle n’est plus utilisée qu’en lecture et pour la 1ere partie du boot donc ca la préserve.

Merci beaucoup pour vos reponses. J’ai bien tente et reussi la manip de Dagon et mon raspberry utilise desormais la cle usb. Par contre je me suis recommande une nouvelle cle pour essayer la manip de Zatchbell68 ce week end. Quoiqu’il en soit un grand merci a tous les deux (desole pour les accents clavier qwerty) je reviens dimanche avec le resultat de ce nouvel essaie sur un autre raspberry pi 3 (j’en ai installe 6 dans ma classe de ce1).

par contre avec le boot sur la clé USB tu déporte le soucis je pense que les clé USB sont aussi limité en écriture le mieux est le boot sur disque dur j’ai vu aussi sur un tuto (je ne sais plus lequel) qu’il était possible de lancer le boot sur un réseau ce qui donnerai un Pi équipé de disque dur et les autres venant booter sur celui là avoir aussi. Si je dit une c… sur le boot réseau merci de me le dire.

Oui alors si tu a toujours une carte SD , c’est techniqument pas un boot USB c’est la sd qui boot est la racine root sur la clé USB

non non tu dis juste , tu peux aussi utiliser le réseaux pour mettre tn systéme de fichier comme la clé USB , d’ailleur pour ma part c’est la meuilleur expérience que j’ai faite niveau lecture écriture plus rapide que la SD , juste le boot qui est long si tu est en NFS est que tu fais des requete DHCP

oui tout a fait mais mais bon vu que la carte est mise en lecture seule elle souffre moins pour ne pas dire pas du tout.

Oui mais en lecture seul j’ai pu remarquer (je ne suis pas le seul) que le système avais des difficultés surtout au niveau des updates. Je ne sais pas ci c’est lié, moi j’ai déporté le tout sur hdd swap compris mais j’ai laissé ma carte normal comme ça si jamais il a quand même besoin decrire dans le fat ou je sais pas je n’ai aucun problème.

quand Dagon parle de lecture seul il parle du faite que celle si est utilisé seulement en boot , pas forcément de la permission et donc oui la carte prends moins cher ,

sa peux venir de plusieurs chose la plus frappante , si tu déporte le systéme sur un disque dur brancher en USB , c’est la lenteur du systéme et donc des update , car le port USB est moins performent que le port SD ,

déja les updapte et install sont longs sur pi , par rapport a un PC sur linux , a connexion équivalente

normal me diriez vous a cause fu faite que sur PC on est en SATA et par sur un SD (qui je le rapelle est bridé à 20 mo/s ) et sur disque dur c’est pire .

normalement tu n’a aucunement besoin d’écrire dans la partition /boot (celle en fat )
car celle si est la partition de démarrages , elle n’est pris en compte seulement au démarages(et si il y a une modification dans l’arborescence boot je vais y venir ) ,
si tu regardes bien le contenu de cette partition elle est pratiquement similaire au dossier boot et c’est normal .

si tu modifie à partir du PI le dossier /boot (pas la partition ) celui qui se trouve la

ici nous sommes dans la racine systéme la partition /root en ext4

et bien sa modifira instantanément le contenu de la partition fat

exemple avec le fichier cmdline.txt ,il sera a la fois modifier dans le dossier /boot de la partition EXT 4 et dans la partition /boot en fat 32 .

alors se que tu pourrais te demander à qui sert la partition /boot si c’est pratiquement même chose que
le dossier /boot

comme je l’ai expliquer la partition boot sert au démarages est celle si qui est lu au démarrages et si les fichier sont différent le cmdline par exemple est bien le cmdline va remplacer celui du dossier /boot .

tous simplement pour que tu puisse modifier depuis un ordi est d’ailleur n’importe qu’elle systéme d’exploitation c’est pour sa qu’elle est en fat 32 .

donc quand la partition boot est lu est va vérifier qu’elle a les meme info sur certain fichier entre le dossier et la partition , si c’est pas le cas elle se charges de le faire .
:loudspeaker:pour etre précis elle va modifier le dossier boot de la partition qui est déclaré dans le cmdline

voila comment sa marche j’ai simplifier au maximun ,

il se peut qu’a l’avenir la partition /boot (et c’est déja arriver )change , et sa arive sur certaine mise a jour , sa été le cas par exemple lors de la mise a jour de sécurité (le 30 novembre dernier )

mais dans les cas la t’inquiete pas elle sera modifer car le dossier boot la modifiera lors de la mise a jour :wink:

Bonjour
Alors voici le resultat : umount: mountpoint not found
Apres si je fais sudo umount /mnt/target/dev, j’ai : command not found
Par contre en ignorant les messages d’erreur et en allant jusqu’au bout et sur une nouvelle cle : une sandisk cruzer fit 32 GB cela fonctionne,il demarre maintenant sur la cle avec la sd retiree.
Grand merci a tous pour vos reponses tres eclairantes.

Bonjour,
J’ai eu passablement de problème depuis la dernière MAJ de Raspbian (stretch -> buster) pour redémarer sur clef USB 3 (utilisation de Minitools sur Windows pour reformater et installer la buster.img) mais en vain.
Je pensais même que USB 3 posait problème sur port USB 2, mais NON! C’est mieux d’avoir plus que pas assez :slight_smile:

Si vous voulez éviter de perdre votre temps:
-Formater votre clef USB en ext4 sur linux Xubunut 18.04 Lts
-Créer votre clef USB en écrivant la buster.img dessus.

A la fin de l’écriture, le programme vous demande si vous voulez ajouter un boot, répondez « oui » et le tour est joué (pour autant que vous ayez effectué la fameuse:

echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt
avec la SD (à reformater et installer buster.img)

Normalement, le raspberry démarre sans problème.
PS: J’utilise la même clef USB 3 sur mon Rpi3mB, depuis 1an et 6mois en continu sans soucis, ou presque…