Sto sviluppando un'appliance basata su Linux utilizzando un alix 2d13.Firmware basato su Linux, come implementare un buon metodo di aggiornamento?
Ho sviluppato uno script che si occupa della creazione di un file immagine, della creazione delle partizioni, dell'installazione del boot loader (syslinux), del kernel e dell'initrd e, che si occupa di mettere i file del filesystem di root nella partizione corretta .
I file di configurazione sono sul filesystem tmpfs e vengono creati all'avvio del sistema da un software che legge un file XML che risiede su una propria partizione.
che sto cercando un modo per aggiornare il file system e ho considerato due soluzioni:
- l'aggiornamento del firmware è un file compresso che potrebbe contenere il kernel, initrd e/o la partizione rootfs, in questo modo, al riavvio, initrd si prenderà cura di dd l'immagine rootfs nella partizione corretta;
- l'aggiornamento del firmware è un file compresso che può contenere due archivi tar, uno per l'avvio e uno per il filesystem di root.
Ogni soluzione ha i suoi vantaggi: - un'immagine del filesystem mi permette di eliminare tutti i file inutilizzati, ma ha bisogno di un sacco di tempo e ucciderà la memoria compact flash velocemente; - un archivio è più piccolo, ha bisogno di meno tempo per l'aggiornamento, ma avrò il caos sul filesystem di root in breve tempo.
Una soluzione alternativa potrebbe essere quella di inserire un elenco di file e di inserire uno script pre/post update nell'archivio tar, in modo tale che qualsiasi file che non risiede nell'elenco dei file verrà eliminato.
Cosa ne pensi?
mi piace molto la tua soluzione, alla fine ho fatto qualcosa di molto simile ma senza rilevamento errori di avvio, ma penso che implementerò qualcosa di simile: - riserverò un settore per la scrittura del rilevamento errori di avvio utilizzando le operazioni dirette io e sincronizzazione - il kernel di avvio avvierà un initrd che segnalerà un tentativo di avvio, con timestamp e montare l'immagine os - durante il processo di avvio, il nuovo initrd riporterà, passo dopo passo con i timestamp, le fasi di avvio per identificare i problemi - alla fine segnalerà nel settore di rilevamento degli errori di avvio "tutto fatto" –
Per l'aggiornamento preferisco scaricare il tarball in la partizione dati e, al riavvio, se il primo initrd rileva il tarball di aggiornamento, gestirà il tarball (potrebbe essere tu Seful aggiunge due file speciali per identificare i file da eliminare e per eseguire uno script di aggiornamento). Dopo l'aggiornamento, il primo initrd eseguirà kexec nel nuovo kernel, riportando l'avvio come aggiornamento (in modo che il tarball possa essere eliminato). Il tarball, per motivi di sicurezza, deve essere firmato con una chiave privata. Per segnalare errori potrebbe utilizzare il precedente settore del disco (rilevamento errori di avvio), è sufficiente eseguire la sincronizzazione di scrittura per evitare problemi –
Mi piace l'idea del "settore stato". Almeno sposta alcuni dei punti di errore in una singola posizione del disco, e se quel settore fallisce, si potrebbe probabilmente avere settori di riserva e si potrebbe tentare un ripristino, o almeno offrire una "modalità di ripristino." – Patrick