Domanda:
Utilizzo di Raspberry Pi per eseguire il flashing della propria scheda SD
Jeremiah Rose
2019-06-25 08:02:09 UTC
view on stackexchange narkive permalink

Sto sviluppando un sistema operativo Buildroot per Raspberry Pi e il mio flusso di lavoro richiede un frequente aggiornamento della scheda SD per testare nuove iterazioni. Il processo di rimozione della scheda SD dal Pi, flashing su un PC Windows e quindi reinserimento richiede molto tempo Vorrei scrivere uno script che utilizzi il sistema operativo attualmente in esecuzione su Rpi (accessibile tramite SSH) per

  1. Scaricare la nuova immagine SD
  2. Flash nella SD, sovrascrivendo tutti i file del sistema operativo esistenti
  3. Riavviare nel nuovo sistema operativo

Il passaggio 2 è dove sono bloccato. È possibile che un sistema operativo si sovrascriva?

Puoi considerare di utilizzare l'avvio da rete per lo sviluppo.
Questo è un commento perché non so se funzionerebbe, ma puoi avere due partizioni sulla scheda SD, scrivere sulla seconda partizione e quindi avviare da quella nuova partizione la prossima volta? Mentre esegui l'iterazione delle modifiche, stai solo eseguendo l'avvio da una partizione o dall'altra?
@JPhi1618 Sì, è possibile, tranne per il fatto che non si desidera scrivere un'immagine del sistema operativo Pi (normativa) sull'altra partizione: si vorrebbe scrivere il contenuto del filesystem di root, che è possibile estrarre dall'immagine. Ciò richiede un po 'di armeggiamento manuale (o con script). Quindi si desidera aggiornare la partizione di avvio e impostare "root =" in "cmdline.txt".
Il modo più semplice è utilizzare un lettore / scrittore di schede SD USB.
Sette risposte:
flakeshake
2019-06-25 09:56:22 UTC
view on stackexchange narkive permalink

Per sovrascrivere se stesso, il sistema operativo deve essere eseguito completamente nella RAM e non leggere né scrivere dalla scheda SD dopo l'avvio. piCore / TinyCore è probabilmente uno dei pochi sistemi operativi Linux in grado di farlo.

È necessario che il sistema operativo * non * legga / scriva mai su SD, o semplicemente non richiede la SD durante l'operazione dd?
@JeremiahRose Se qualcos'altro scrive su una parte della scheda SD `dd` è finito, l'immagine rovinerà.
@JeremiahRose A rigor di termini, fintanto che puoi _ completamente certamente garantire_ che _assolutamente nessuna modifica della scheda SD_ accadrà mentre `dd` è in esecuzione, allora va bene se modifica la scheda SD al di fuori di quello. In pratica, basta andare con un sistema operativo che non modifica mai la scheda SD; sarà più semplice ragionare.
"while dd is running" - non solo mentre è in esecuzione, dopo che è finito. È probabile che il sistema operativo memorizzi nella cache vari metadati del file system, ad esempio _dove i file risiedono sulla scheda SD_. Se, dopo che dd è stato eseguito, decide di scrivere su uno di questi file (che non sono più dove il sistema operativo pensa che siano), sovrascriverà invece altri dati arbitrari.
Un sistema operativo in esecuzione esclusivamente nella RAM è una soluzione semplice e generica, ma in qualche modo sono un po 'deluso se non esiste un programma che si blocchi semplicemente e il file immagine in memoria, impedisca l'esecuzione di altri processi ( impostandosi per essere eseguito con pianificazione in tempo reale o qualcosa del genere), quindi scrivere l'immagine e riavviare il sistema.
@ilkkachu, il problema è che molti processi amano scrivere un aggiornamento di qualche tipo a se stessi quando si arrestano. Prevenire ciò potrebbe causare RTE, causando altri errori imprevisti. Anche ai sistemi operativi piace farlo. Impedire al sistema operativo un aggiornamento all'arresto da parte di un programma in esecuzione sul sistema operativo non funzionerà, poiché il programma verrà arrestato prima del sistema operativo, che avrebbe quindi accesso alla scheda, annullando il programma involontariamente.
In base ai tuoi commenti, sto cercando di pensare a un modo per migliorare la mia risposta in modo che 1. arresti il ​​sistema immediatamente dopo dd (senza spegnimento) e 2. blocchi la SD da qualsiasi altro processo (cambiando semplicemente i permessi su / dev / mmcblk0 dovrebbe farlo?)
@JeremiahRose Forse aggiungendo un layer overlayfs supportato da un ramfs sulla scheda SD prima di eseguire `dd` e poi fare un riavvio di" emergenza "(un po 'come digitare [Alt-SysRq-U e poi Alt-SysRq-B] (https: / /en.wikipedia.org/wiki/Magic_SysRq_key))? Sto solo speculando, non sono sicuro che questo possa essere fatto al volo.
@computercarguy, Direi che è un programma raro che insiste sulla scrittura di aggiornamenti durante l'arresto (tranne probabilmente tutto ciò che utilizza sqlite o simili, ma ad esempio le solite utilità della riga di comando non rientrano in questo). In ogni caso, quello di cui sto parlando sarebbe un programma costruito proprio per questo scopo, e chiederebbe solo un riavvio immediato e immediato, non un arresto dello spazio utente.
@ilkkachu, se ha un sistema di registrazione simile a Windows, vorrà scrivere un registro dicendo perché è avvenuto l'arresto. Se non viene gestito correttamente dal layout del disco corrente, potresti sovrascrivere accidentalmente parte dei file di sistema o semplicemente essere una voce benigna nel mezzo di quello che dovrebbe essere uno spazio bianco. Potrebbe anche esserci un aggiornamento automatico per il sistema operativo in esecuzione che si avvia dopo aver ricreato l'immagine, causando lo stesso tipo di problema. Il punto è che, come utente, non hai tutto il controllo che pensi di avere.
@computercarguy, sì, avevo il presupposto nascosto o un sistema Linux (credo che sia quello che è piuttosto comunemente usato anche su Raspberries e altri dispositivi simili). Ovviamente non tutti eseguono Linux e cose del genere dipendono dal sistema operativo, ma lo stesso vale per il sistema operativo dalla RAM.
@computercarguy, ma per quanto riguarda gli aggiornamenti automatici e simili, tieni presente che ho detto _ "impedisce l'esecuzione di altri processi" _.
@ilkkachu "impedisce l'esecuzione di altri processi", di solito non è così facile come sembra. Cosa succede quando un processo richiesto per eseguire il wipe & reimage richiede anche un altro processo che richiede un altro processo (all'infinito) che alla fine vuole scrivere qualcosa sull'unità? È fin troppo comune e spesso difficile da aggirare o riscrivere in modo efficiente quando i requisiti del processo cambiano nel sistema operativo. È qualcosa a cui pensare, non una garanzia che non funzionerà.
Roger Jones
2019-06-25 13:45:15 UTC
view on stackexchange narkive permalink

Come sottolineato altrove, eseguire dd su un sistema operativo in esecuzione non è mai una buona idea. Un'alternativa (e il modo usuale in cui svilupperesti sistemi embedded) è che l'immagine del tuo sistema operativo venga servita da un'unità di rete e la scheda di destinazione esegua un avvio di rete. Questo accelera lo sviluppo iniziale e devi solo scrivere le schede SD man mano che ti avvicini al completamento e devi testare sull'hardware reale.

C'è una scrittura sull'impostazione di PI3B e PI3B + da cui avviare un server sulle pagine della Fondazione: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md

Nel mio caso, dd-ing sul sistema operativo in esecuzione non ha causato assolutamente alcun problema
Attenzione, è un po 'come dire che guidi spesso ubriaco e non hai alcun problema, o prendi le scale al buio tutto il tempo e non hai alcun problema, ecc. È un po' diverso da quello che quelle cose, però, in che quando va storto non avrai alcuna possibilità di reagire. OTOH, non sarai ferito o ucciso, quindi "funziona finché non funziona" forse va bene con il tuo flusso di lavoro.
Questo è simile alla tecnica che le persone usano per eseguire utilità come nwipe per cancellare in modo sicuro un intero disco rigido: https://github.com/martijnvanbrummelen/nwipe/
Jeremiah Rose
2019-06-25 13:26:20 UTC
view on stackexchange narkive permalink

Utilizzare con cautela

Questo funziona per me perché sto utilizzando un filesystem root di sola lettura con un sistema operativo Buildroot personalizzato. Questo script non è stato ancora testato su Raspbian, ma probabilmente funzionerà. 

  #! / Bin / bashset -eecho "Copia immagine su RPi ..." sshpass -p PASSWORD scp / PATH /TO/SDCARD.img USER @ RPI: /tmp/sdcard.imgecho "Immagine lampeggiante in / dev / mmvblk0 su RPi ..." sshpass -p PASSWORD ssh USER @ RPI 'nice -20 sudo sh -c "sync && dd if = / tmp / sdcard.img of = / dev / mmcblk0 conv = fdatasync && reboot -f "'

Deve essere eseguito sul computer host ( non l'RPi) e fa quanto segue:

  1. Copia l'immagine SD sull'RPi tramite scp
  2. Accede all'RPi tramite ssh
  3. Sincronizza tutto operazioni di scrittura del sistema operativo in sospeso sulla scheda SD
  4. Imposta la priorità su -20 per impedire l'esecuzione di altri processi
  5. Lampeggia l'immagine sulla scheda SD seguita da un fdatasync
  6. Esegue un hard reset

Limitazioni:

  • Se i dati vengono scritti sulla scheda SD da un altro processo mentre lo script è in esecuzione , la SD potrebbe diventare corrotta pted. In pochi giorni di utilizzo attivo, non l'ho ancora riscontrato, ma non sto usando Raspbian.
  • Assicurati di utilizzare questo script solo per lo sviluppo / test, non per l'aggiornamento del tuo sistema operativo o di qualsiasi altro applicazioni sensibili ai dati.
  • È possibile utilizzare alcuni miglioramenti per impedire ulteriormente ad altri processi di accedere alla scheda SD - suggerimenti ben accetti.

Per utilizzare:

  1. Copia lo script precedente in un file flash.sh sul tuo PC host
  2. Inserisci le tue impostazioni per password, nome utente, immagine SD ecc.
  3. Rendilo eseguibile con chmod a + x flash.sh
  4. Installa sshpass e ssh sull'host: sudo apt install sshpass openssh
  5. Assicurati che l'accesso ssh funzioni su RPi
  6. Esegui ./flash.sh codice>
Ci sono casi in cui l'immagine è più pesante del ricordo del roco, cosa potremmo fare in quei casi?
Sì, quei casi sembrano impossibili da aggirare
Monty Harder
2019-06-26 02:43:49 UTC
view on stackexchange narkive permalink

Usa una scheda SD abbastanza grande da contenere più partizioni

La scheda SD dovrebbe contenere una partizione di avvio (0) e tre partizioni del sistema operativo (1-3).

Il boot loader sulla partizione di avvio esaminerà le etichette della partizione per determinare cosa caricare. Supponiamo che le etichette siano:

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

Il caricatore sa di caricare il sistema operativo dalla partizione 1, poiché è l'ultima etichetta quando vengono ordinati. E la prima etichetta del sistema operativo è la partizione 2, su cui scrive l'aggiornamento

2: OS-0005_

Questa è ora l'ultima etichetta, ma il Il flag di sottolineatura indica al caricatore che è il primo tentativo di avvio da esso. Cambia l'etichetta per indicare che sta eseguendo un avvio di prova subito prima di collegarsi ad essa:

2: OS-0005? Se il sistema operativo si avvia con successo e supera i propri controlli di integrità, aggiorna l'etichetta ancora una volta, così come l'etichetta della partizione del sistema operativo precedente: 1: OS-0004 2: OS-0005!

Se fallisce, la prossima volta che proverà ad avviarsi, vedrà? flag e ripristina il caricamento dalla partizione 1, dopodiché l'aggiornamento ricomincerà.

Questo sembra essere uno schema interessante, ma hai qualche specifica su come farlo?
Non l'ho fatto da solo, ma so che i boot loader sono capaci di questo genere di cose. Il sistema di Google Chromebook è simile, in quanto ha una partizione di avvio, almeno due partizioni del sistema operativo e una partizione dello spazio utente, in modo che gli aggiornamenti vengano sempre applicati alla partizione del sistema operativo da cui _non_ si è avviato.
Ronny Nilsson
2019-07-24 17:56:04 UTC
view on stackexchange narkive permalink

Tutti i tuoi requisiti sono già disponibili nella mia distribuzione Nard SDK. Funziona dalla RAM e ci sono script già pronti per gli aggiornamenti delle immagini in remoto.
http://www.nard.se/

Bel progetto! Ho una domanda: la maggior parte degli [Esempi] (http://www.nard.se/examples.html) elencati sembrano cose che vengono fatte anche con RPi / Raspbian, quindi non sono chiaro sul vantaggi del tuo sistema (Nard). Modifica la tua risposta per elaborarla?
@Seamus Dove brilla Nard è per i prodotti di grande volume. Supponiamo, ad esempio, che tu costruisca un qualche tipo di macchina con un Pi incorporato. La macchina viene poi venduta in +100 copie. L'assenza di tali prodotti utente nel sito web è politica. I produttori non accettano mai di diventare un riferimento. :(
Timothy Baldwin
2019-06-26 23:35:17 UTC
view on stackexchange narkive permalink

Ecco un approccio approssimativo:

  1. Sostituisci / sbin / init con lo strumento di aggiornamento.
  2. Dì a init di rieseguirsi da solo.
  3. Uccidi tutti gli altri processi rimanenti (ad esempio con kill -9 -1 )
  4. Usa pivot_root e chroot per sostituire la radice filesystem.
  5. Se necessario exec la fase successiva da eliminare fa riferimento alla vecchia root.
  6. Smonta ricorsivamente la vecchia root.
  7. Scrivi la nuova immagine.
  8. Riavvia.
Benjamin Collins
2019-10-29 06:36:18 UTC
view on stackexchange narkive permalink

Ho pensato a qualcosa di simile per testare lo sviluppo / la distribuzione da una nuova installazione di Raspbian. Il mio pensiero attuale è una configurazione con doppia scheda SD e unità USB. Quindi ad ogni avvio, il pi si avvia prima nella scheda sd, esegue una nuova installazione sull'unità USB, quindi esegue il chroot nell'unità USB per avviare il sistema operativo.

Anche se questo è solo testo , Ci ho pensato solo concettualmente mentre lampeggiavo manualmente la scheda SD con altri dispositivi. Quindi immagino che dovrei iniziare a esaminare l'implementazione ..



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...