Question:
Utiliser Raspberry Pi pour flasher sa propre carte SD
Jeremiah Rose
2019-06-25 08:02:09 UTC
view on stackexchange narkive permalink

Je développe un OS Buildroot pour le Raspberry Pi, et mon flux de travail nécessite un re-flashage très fréquent de la carte SD pour tester de nouvelles itérations. Le processus de retrait de la carte SD du Pi, de la flasher sur un PC Windows, puis de la réinsérer prend beaucoup de temps.J'aimerais écrire un script qui utilise le système d'exploitation actuellement en cours d'exécution sur le Rpi (accessible via SSH) pour

  1. Télécharger la nouvelle image SD
  2. Flasher sur la SD, en écrasant tous les fichiers du système d'exploitation existants
  3. Redémarrer dans le nouveau système d'exploitation

À l'étape 2, je suis bloqué. Un système d'exploitation peut-il se remplacer?

Vous pouvez envisager d'utiliser le démarrage par réseau pour le développement.
Ceci est un commentaire car je ne sais pas si cela fonctionnerait, mais pouvez-vous avoir deux partitions sur la carte SD, écrire sur la deuxième partition, puis démarrer à partir de cette nouvelle partition la prochaine fois? Au fur et à mesure que vous parcourez les modifications, vous ne faites que démarrer à partir d'une partition ou de l'autre?
@JPhi1618 Oui, c'est possible, sauf que vous ne voudriez pas écrire une image (normative) du système d'exploitation Pi sur l'autre partition - vous voudriez écrire le contenu du système de fichiers racine, que vous pouvez extraire de l'image. Cela nécessite un peu de bricolage manuel (ou scriptable). Ensuite, vous voudrez mettre à jour la partition de démarrage et définir `root =` dans `cmdline.txt`.
Le moyen le plus simple est d'utiliser un lecteur / graveur de carte USB SD.
Sept réponses:
flakeshake
2019-06-25 09:56:22 UTC
view on stackexchange narkive permalink

Pour s’écraser, votre système d’exploitation doit fonctionner entièrement en RAM et ni lire ni écrire à partir de la carte SD après le démarrage. piCore / TinyCore est probablement l'un des rares systèmes d'exploitation Linux à pouvoir le faire.

Est-il nécessaire que le système d'exploitation ne * jamais * lire / écrire sur SD, ou simplement cela ne nécessite pas la SD pendant l'opération dd?
@JeremiahRose Si quelque chose d'autre écrit sur une partie de la carte SD `dd` est terminé, cela va bousiller l'image.
@JeremiahRose À proprement parler, tant que vous pouvez _complètement certainement garantir_ que _absolument aucune modification de la carte SD_ ne se produira pendant que `dd` est en cours d'exécution, alors tout va bien si cela modifie la carte SD en dehors de cela. En pratique, optez pour un système d'exploitation qui ne modifie jamais la carte SD; il sera plus simple de raisonner.
"pendant que dd est en cours d'exécution" - pas seulement pendant son exécution, une fois qu'il est terminé. Le système d'exploitation est susceptible de mettre en cache diverses métadonnées du système de fichiers, telles que _ là où les fichiers vivent sur la carte SD_. Si, après l'exécution de dd, il décide d'écrire dans l'un de ces fichiers (qui ne sont plus là où le système d'exploitation pense qu'ils se trouvent), il écrasera d'autres données arbitraires à la place.
Un système d'exploitation fonctionnant uniquement en RAM est une solution simple et polyvalente, mais d'une certaine manière, je suis un peu déçu s'il n'existe pas de programme qui se verrouillerait simplement lui-même et le fichier image en mémoire, empêchant d'autres processus de s'exécuter ( se définissant pour fonctionner avec une planification en temps réel ou quelque chose), puis écrivez l'image et redémarrez le système.
@ilkkachu,, le problème avec cela est que de nombreux processus aiment écrire une mise à jour quelconque pour eux-mêmes lorsqu'ils s'arrêtent. Empêcher que cela puisse provoquer des RTE, provoquant d'autres erreurs inattendues. Même les systèmes d'exploitation aiment faire cela. Empêcher le système d'exploitation d'une mise à jour à l'arrêt par un programme s'exécutant sur le système d'exploitation ne fonctionnera probablement pas, car le programme sera arrêté avant le système d'exploitation, qui aurait alors accès à la carte, battant le programme sans le vouloir.
Sur la base de vos commentaires, j'essaie de penser à un moyen d'améliorer ma réponse afin 1. qu'il arrête le système immédiatement après dd (sans arrêt) et 2. empêche l'écriture de la carte SD par tout autre processus (il suffit de modifier les autorisations sur le / dev / mmcblk0 devrait le faire?)
@JeremiahRose Peut-être ajouter une couche overlayfs sauvegardée par un ramfs sur la carte SD avant d'exécuter `dd` puis de faire un redémarrage" d'urgence "(un peu comme taper [Alt-SysRq-U puis Alt-SysRq-B] (https: / /en.wikipedia.org/wiki/Magic_SysRq_key))? Juste spéculer, pas sûr que cela puisse être fait à la volée.
@computercarguy, Je dirais que c'est un programme rare qui insiste pour écrire des mises à jour lors de l'arrêt (sauf probablement tout ce qui utilise sqlite ou autre, mais par exemple, les utilitaires de ligne de commande habituels ne tombent pas dans cela). Dans tous les cas, ce dont je parle serait un programme construit dans ce but précis, et demanderait simplement un redémarrage dur et immédiat, pas un arrêt de l'espace utilisateur.
@ilkkachu, s'il a un système de journalisation similaire à Windows, il voudra écrire un journal indiquant pourquoi l'arrêt s'est produit. Si ce n'est pas géré correctement par la disposition actuelle du disque, vous pourriez accidentellement écraser une partie des fichiers système, ou simplement être une entrée bénigne au milieu de ce qui devrait être un espace blanc. Il peut également y avoir une mise à jour automatique du système d'exploitation en cours d'exécution qui démarre après la réimagerie, provoquant le même type de problème. Le fait est qu'en tant qu'utilisateur, vous n'avez pas autant de contrôle que vous le pensez.
@computercarguy, oui, j'avais l'hypothèse cachée ou un système Linux (je pense que c'est ce qui est assez couramment utilisé sur les framboises et autres appareils similaires). Bien sûr, tout le monde n'exécute pas Linux, et des trucs comme ça _est_ dépendants du système d'exploitation, mais il en va de même pour le système d'exploitation depuis la RAM.
@computercarguy, mais en ce qui concerne les mises à jour automatiques et autres, notez que j'ai dit _ "empêcher l'exécution d'autres processus" _.
@ilkkachu "empêche l'exécution d'autres processus", ce n'est généralement pas aussi simple qu'il y paraît. Que se passe-t-il lorsqu'un processus requis pour exécuter l'effacement et la réimage nécessite également un autre processus qui nécessite un autre processus (à l'infini) qui souhaite finalement écrire quelque chose sur le lecteur? C'est trop courant et souvent difficile à contourner ou à réécrire efficacement lorsque les exigences du processus changent sur le système d'exploitation. C'est quelque chose à penser, pas une garantie que cela ne fonctionnera pas.
Roger Jones
2019-06-25 13:45:15 UTC
view on stackexchange narkive permalink

Comme indiqué ailleurs, dd -ing sur un OS en cours d'exécution n'est jamais une bonne idée. Une alternative (et la manière habituelle de développer des systèmes embarqués) consiste à faire servir l'image de votre système d'exploitation à partir d'un lecteur réseau et à la carte cible d'effectuer un démarrage réseau. Cela accélère le développement initial. un serveur sur les pages Fondation: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md

Dans mon cas, dd-ing sur le système d'exploitation en cours d'exécution n'a causé absolument aucun problème
Attention, c'est un peu comme dire que vous conduisez souvent ivre et que vous n'avez aucun problème, ou que vous prenez les escaliers dans le noir tout le temps et que vous n'avez aucun problème, etc. C'est un peu différent de cela, cependant, qu'en cas de problème, vous n'aurez aucune possibilité d'y réagir. OTOH, vous n'allez pas être blessé ou tué, alors "ça marche jusqu'à ce que ça ne marche pas" peut-être bien avec votre flux de travail.
Ceci est similaire à la technique que les gens utilisent pour exécuter des utilitaires comme nwipe pour effacer en toute sécurité un disque dur entier: https://github.com/martijnvanbrummelen/nwipe/
Jeremiah Rose
2019-06-25 13:26:20 UTC
view on stackexchange narkive permalink

À utiliser avec prudence

Cela fonctionne pour moi car j'utilise un système de fichiers racine en lecture seule avec un OS Buildroot personnalisé. Ce script n'a pas encore été testé sur Raspbian, mais fonctionnera probablement. 

  #! / Bin / bashset -eecho "Copie de l'image vers RPi ..." sshpass -p MOT DE PASSE scp / PATH /TO/SDCARD.img USER @ RPI: /tmp/sdcard.imgecho "Image clignotante vers / dev / mmvblk0 sur RPi ..." sshpass -p MOT DE PASSE ssh USER @ RPI 'nice -20 sudo sh -c "sync && dd if = / tmp / sdcard.img of = / dev / mmcblk0 conv = fdatasync && reboot -f "'

Cela doit être exécuté sur l'ordinateur hôte ( pas le RPi) et effectue les opérations suivantes:

  1. Copie l'image SD sur le RPi via scp
  2. Se connecte au RPi via ssh
  3. Synchronise tout opérations d'écriture du système d'exploitation en attente sur la carte SD
  4. Définit la priorité sur -20 pour empêcher d'autres processus de s'exécuter
  5. Flashe l'image sur la carte SD suivie d'une fdatasync
  6. Effectue une réinitialisation matérielle

Limitations:

  • Si des données sont écrites sur la carte SD par un autre processus pendant l'exécution du script , le SD peut devenir corrompu pted. En quelques jours d'utilisation active, je n'ai pas encore rencontré cela - mais je n'utilise pas Raspbian.
  • Assurez-vous de n'utiliser ce script que pour le développement / test, pas pour la mise à niveau de votre système d'exploitation ou de tout autre applications sensibles aux données.
  • Pourrait utiliser certaines améliorations pour empêcher davantage d'autres processus d'accéder à la carte SD - suggestions bienvenues.

À utiliser:

  1. Copiez le script ci-dessus dans un fichier flash.sh sur votre PC hôte
  2. Renseignez vos paramètres de mot de passe, nom d'utilisateur, image SD etc
  3. Rendez-le exécutable avec chmod a + x flash.sh
  4. Installez sshpass et ssh sur l'hôte: sudo apt install sshpass openssh
  5. Assurez-vous que la connexion ssh fonctionne sur le RPi
  6. Exécutez ./flash.sh
Il y a des cas où l'image est plus lourde que la mémoire du râpeux, que pourrions-nous faire dans ces cas?
Ouais, ces cas semblent impossibles à contourner
Monty Harder
2019-06-26 02:43:49 UTC
view on stackexchange narkive permalink

Utilisez une carte SD suffisamment grande pour contenir plusieurs partitions

La carte SD doit contenir une partition de démarrage (0) et trois partitions du système d'exploitation (1-3).

Le chargeur de démarrage sur la partition de démarrage examinerait les étiquettes de partition pour déterminer ce qu'il fallait charger. Supposons que les libellés soient:

0: BOOT
1: OS-0004!
2: OS-0002
3: OS-0003

Le chargeur sait charger le système d'exploitation à partir de la partition 1, car c'est la dernière étiquette quand ils sont triés. Et la première étiquette du système d'exploitation est la partition 2, sur laquelle il écrit la mise à jour

2: OS-0005_

C'est maintenant la dernière étiquette, mais le Le drapeau de soulignement indique au chargeur que c'est la première tentative de démarrage à partir de celui-ci. Il change le libellé pour indiquer qu'il fait un test de démarrage juste avant qu'il ne l'enchaîne:

2: OS-0005? Si le système d'exploitation démarre avec succès et réussit ses propres vérifications, il met à jour l'étiquette une fois de plus, ainsi que l'étiquette de la partition du système d'exploitation précédente: 1: OS-0004 2: OS-0005!

S'il échoue, la prochaine fois qu'il essaiera de démarrer, il verra le? drapeau et revenir au chargement à partir de la partition 1, après quoi la mise à jour recommencera.

Cela semble être un aperçu intéressant, mais avez-vous des détails sur la façon de procéder?
Je ne l'ai pas fait moi-même, mais je sais que les chargeurs de démarrage sont capables de ce genre de chose. Le système Google Chromebook est similaire, en ce sens qu'il possède une partition de démarrage, au moins deux partitions de système d'exploitation et une partition d'espace utilisateur, de sorte que les mises à jour sont toujours appliquées à la partition du système d'exploitation à partir de laquelle le système n'a _pas_ démarré.
Ronny Nilsson
2019-07-24 17:56:04 UTC
view on stackexchange narkive permalink

Toutes vos exigences sont déjà disponibles dans ma distribution Nard SDK. Il fonctionne à partir de la RAM et il existe des scripts prêts à l'emploi pour les mises à niveau d'images à distance.
http://www.nard.se/

Beau projet! J'ai une question: la plupart des [Exemples] (http://www.nard.se/examples.html) répertoriés semblent être des choses qui sont également en cours avec RPi / Raspbian, donc je ne suis pas clair sur le avantages de votre système (Nard). Modifier votre réponse pour élaborer?
@Seamus Là où Nard brille, c'est pour les produits de grand volume. Disons par exemple que vous construisez une sorte de machine avec un Pi intégré. La machine est ensuite vendue à +100 exemplaires. L'absence de tels produits utilisateurs sur le site Web est politique. Les fabricants n'acceptent jamais de devenir une référence. :(
Timothy Baldwin
2019-06-26 23:35:17 UTC
view on stackexchange narkive permalink

Voici une approche approximative:

  1. Remplacez / sbin / init par l'outil de mise à jour.
  2. Dites à init de se réexécuter.
  3. Tuer tous les autres processus restants (par exemple avec kill -9 -1 )
  4. Utilisez pivot_root et chroot pour remplacer la racine système de fichiers.
  5. Si nécessaire exec , l'étape suivante de suppression fait référence à l'ancienne racine.
  6. Démontez récursivement l'ancienne racine.
  7. Écriture la nouvelle image.
  8. Redémarrez.
Benjamin Collins
2019-10-29 06:36:18 UTC
view on stackexchange narkive permalink

J'ai pensé à quelque chose de similaire pour tester le développement / déploiement à partir d'une nouvelle installation de Raspbian. Ma pensée actuelle est une configuration à double carte SD et lecteur USB. Ainsi, à chaque démarrage, le pi démarre d'abord dans la carte SD, fait clignoter une nouvelle installation sur le lecteur USB, puis chroote sur le lecteur USB pour démarrer le système d'exploitation.

Bien que ce ne soit que du texte , je n'y ai pensé que conceptuellement en faisant clignoter manuellement les cartes SD avec d'autres appareils. Je suppose donc que je devrais commencer à me pencher sur la mise en œuvre ..



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...