Per favore pubblica le tue idee di pensiero o qualsiasi cosa tu possa inventare. Sarei molto interessato a vedere cosa sta pensando qualcun altro.

Il problema generale

Quando installo una semplice applicazione Java (che ho scritto) per eseguire all'avvio (in background) tramite /etc/init.d/, funziona sul liveUSB su cui l'ho installato esplicitamente. Quando faccio una copia di quel bastone, non si avvia mai con successo. Quando si avvia la copia liveUSB, l'applicazione Java si bloccherà sempre quando il processo di avvio liveUSB raggiunge il mio script. Il mio script, che fa esattamente quello che dovrebbe fare, anche ogni 5 minuti e continuerà a funzionare per sempre fino a quando non si spegne la macchina.

1. La mia sceneggiatura sta bloccando tutto il resto
2. Niente di molto oltre il mio copione
3. Non puoi cancellare il mio script
4. Non c'è GUI
5. L'unico testo che puoi vedere è l'output da riga di comando del mio script

Setup & amp; Test - Tutto va bene :)

Ho un liveUSB Linux con 3 partizioni. Viene caricata un'immagine standard Xubuntu semplice.

• sda1 & gt; 2 GB di spazio di archiviazione
• sda2 & gt; Sistema da 2 GB
• sda3 & gt; gb rimanente per Casper

Ho creato una semplice applicazione Java che viene eseguita in background all'avvio. Per arrivare a questo punto, ho seguito questi passaggi:

1. Applicazione Java compilata in classi
2. File di classe inseriti in / home / utente / cartella /
3. Copiato il mio script startup.sh in /etc/init.d/
4. Mentre si trova in /etc/init.d/
   • Digitato "update-rc.d startup.sh start 20 2 5. Stop 20 0 1 6."
   • Questo livello aggiornato funziona correttamente
5. Ora posso riavviare / riavviare / spegnere qualsiasi operazione e tutto funziona perfettamente!

La copia - Ecco dove diventa complicato!

Quando creo una copia di questo stick, seguo questi passaggi:

1. Mount sda2
   • copia tutto da quella cartella in / home / utente / desktop / tmp-system /
2. Mount sda3
   • copia tutto da quella cartella in / home / utente / desktop / tmp-casper /
3. Vai in / home / utente / desktop / tmp-system /
   • Digita "tar -cvf system.tar".
4. Vai in / home / utente / desktop / tmp-casper /
   • Digita "tar -cvf casper.tar".
5. umount
   • sda2
   • sda3
6. Collegare USB vuoto (sdb per esempio)
   • Configurare le partizioni (come la penna da cui si copia)
   • Untar in partizioni
     • tar -xvf system.tar ... in sdb2
     • tar -xvf casper.tar ... in sdb3

analisi - Ecco dove va tutto storto!

1. Collega il liveUSB appena creato al computer
2. Avvio da USB
3. Tutto inizia ad avviarsi
4. L'applicazione Java che ho scritto viene attivata
   • Il processo di avvio si blocca per sempre
   • Nessun prompt cmd disponibile
   • Nessuna GUI disponibile
   • È come se il thread fosse in esecuzione (ed è! L'output può essere visualizzato ogni 5 minuti - che è esattamente come dovrebbe essere)

Tentativi di soluzione & amp; gotchas

1

Posso montare il liveUSB copiato, modificare startup.sh per non avviare la mia applicazione Java e non si avvierà ancora (come sospettavo?).

2

Se uso "dd if = sda of = sdb" la copia del liveUSB funzionerà perfettamente. Tuttavia questa non è una soluzione accettabile. Se dovessi copiare una penna da 16 gb con dd su una chiavetta da 64 gb, ciò trasformerebbe lo stick da 64 gb in un 16 gb. Rende anche molto più difficile modificare i valori che devono essere modificati in ogni partizione.

3

Testato molte varianti di startup.sh e dell'applicazione Java stessa. Tutto ciò produce lo stesso errore.

4

Il metodo che sto usando per copiare i lavori per ogni altra forma di applicazione, file o qualsiasi altra cosa.

5

Vorrei anche provare ad evitare l'uso di librerie o programmi aggiuntivi per l'esecuzione dell'applicazione Java.

6

Ho anche montato sda2 e amp; sdb2 usava cp per copiare tutto direttamente da uno all'altro, quindi seguiva lo stesso per sda3 & amp; sdb3. Questo produce lo stesso errore.

PUNTI AGGIUNTIVI

1. La partizione sda3 è crittografata con cryptsetup
2. Ci sono 2 file nel file system.tar (che sarà sdb2, proveniente da sda2) che avrà un valore modificato dopo che è stato scritto sull'USB.
   • Questi due valori non hanno causato alcun problema in passato e sono sempre stati modificati ogni volta che viene creato un nuovo liveUSB
3. C'è un file nel casper.tar (che sarà sdb3, proveniente da sda3) che avrà un valore modificato dopo che è stato scritto sull'USB.
   • Questo valore non ha causato alcun problema in passato ed è sempre stato modificato con ogni nuovo liveUSB creato.

Processo di verifica del checksum

Immagine USB live originale

Lavorare liveUSB & gt; sda usb vuoto & gt; sdb

passi:

1. Monta, copia e amp; checksum sda2
   • Digitato "mount / dev / sda2 / media / sda2"
   • Digitato "tar -C / media / sda2 -cvf ~ / Desktop / system.tar."
   • Digitato "find. -Type f -exec sha1sum {} ';' & gt; /tmp/sda2_checksum.txt "
   • Digitato "umount / media / sda2"
2. Monta, copia e amp; checksum sda3
   • Digitato "mount / dev / sda3 / media / sda3"
   • Digitato "tar -C / media / sda3 -cvf ~ / Desktop / casper.tar."
   • Digitato "find. -Type f -exec sha1sum {} ';' & gt; /tmp/sda3_checksum.txt "
   • Digitato "umount / media / sda3"
3. Creare partizioni per sdb
4. Monta, scrivi e amp; checksum sdb2
   • Digitato "mount / dev / sdb2 / media / sdb2"
   • Digitato "tar -C / media / sdb2 -xvf ~ / Desktop / system.tar"
   • Digitato "find. -Type f -exec sha1sum {} ';' & gt; /tmp/sdb2_checksum.txt "
   • Digitato "umount / media / sdb2"
5. Monta, scrivi e amp; checksum sdb3
   • Digitato "mount / dev / sdb3 / media / sdb3"
   • Digitato "tar -C / media / sdb3 -xvf ~ / Desktop / casper.tar"
   • Digitato "find. -Type f -exec sha1sum {} ';' & gt; /tmp/sdb3_checksum.txt "
   • Digitato "umount / media / sdb3"
6. Confronta i checksum
   • ordina /tmp/sda2_checksum.txt -o /tmp/sda2_checksum.txt.sort
   • ordina /tmp/sda3_checksum.txt -o /tmp/sda3_checksum.txt.sort
   • ordina /tmp/sdb2_checksum.txt -o /tmp/sdb2_checksum.txt.sort
   • ordina /tmp/sdb3_checksum.txt -o /tmp/sdb3_checksum.txt.sort
7. risultati

sda2 & amp; sdb2

Digitato "diff sda2_checksum.txt.sort sdb2_checksum.txt.sort"

45d44
< 2ddf9802c9c15ac6e4575cc9de32e3530eae6b7d  ./efi/boot/grub.cfg
82d80
< 59bb2775a8e7e499e0590b7b8c2492eb250fb7d8  ./syslinux/txt.cfg
154a153
> ae6c127713e01fc5fb4a2e4e28f6bbddc6bd6af5  ./efi/boot/grub.cfg
158a158
> b78090b66b4e3fa04ca9d466ee78c9060adf744e  ./syslinux/txt.cfg

Questi 2 file contengono 1 valore in ciascuno che viene modificato. Tutto il resto è lo stesso. I risultati sono esattamente ciò che dovrebbero essere.

sda3 & amp; sdb3

Digitato "diff sda3_checksum.txt.sort sdb3_checksum.txt.sort"

Identico: tieni presente che questa è l'immagine liveUSB originale.

Pubblicherò ulteriori risultati di confronto mentre lavoro nella prossima sezione.

PROSSIME PASSI - alias Action Plan

A partire dall'immagine liveUSB senza gli script che devono essere eseguiti.

Passo 1 - Success / Fail?

SUCCESSO - I checksum corrispondono come dovrebbero

1. Aggiorna java su liveUSB da 6 a 7
2. Ricreare i tar
3. Crea un nuovo liveUSB da tar
4. Prova liveUSB

Passo 2 - Success / Fail?

SUCCESSO - I checksum corrispondono come dovrebbero

1. Crea / home / utente / cartella /
2. Copia i file di classe per l'applicazione java in / home / utente / cartella /
3. Ricreare i tar
4. Crea un nuovo liveUSB da tar
5. Prova liveUSB

Passaggio 3 - Success / Fail?

SUCCESSO - I checksum corrispondono come dovrebbero

1. Aggiungi startup.sh in /etc/init.d/
2. Senza chiamare update-rc.d
3. Ricreare i tar
4. Crea un nuovo liveUSB da tar
5. Prova liveUSB

Passaggio 4 - Success / Fail?

SUCCESSO - I checksum corrispondono come dovrebbero

(Non l'ho mai fatto con successo prima) - tuttavia il valore che deve essere scritto non è ancora stato inserito nella partizione di casper (sda3).

1. Digitare "update-rc.d startup.sh start 21 2 5."
2. Ricreare i tar
3. Crea un nuovo liveUSB da tar
4. Prova liveUSB

Passaggio 5 - Success / Fail?

SUCCESSO - I checksum corrispondono come dovrebbero

Non posso credere che abbia funzionato! Il che mi porta a ... (Per esprimerlo in modo carino) Perché il mondo non funzionava prima?

-incidentalmente era la versione 13 che funzionava.

1. Avvia liveUSB
2. Inserisci il valore da sovrascrivere in casper (sda3) prima di creare tar
   • Durante l'esecuzione da liveUSB
   • Modifica il file di configurazione in /home/user/folder/config.properties
3. Arresto liveUSB
4. Ricreare i tar
5. Crea un nuovo liveUSB da tar
6. Prova liveUSB

IMMAGINE COMPLETA !!

Non ho ancora finito con questo!

* Il processo di scrittura su USB non è mai cambiato.

Perché non ha funzionato prima?

1. Metodo di catrame? - Solo un leggero cambiamento ...
   • Da "tar -cvf casper.tar".
   • TO "tar -C / media / sda3 / -cvf ~ / Desktop / casper.tar.
   • Queste linee non stanno ottenendo la stessa cosa?
   • Lo metterò alla prova a breve lungo la strada. - Sospetto nessuna differenza.
2. Tagliare la procedura in singoli passaggi?
   • Prima:
     • Sotto il PROSSIMO PASSO - alias Action Plan, completerei tutti questi passaggi prima di creare una nuova immagine.
   • Dopo:
     • Il NEXT STEPS - aka Action Plan è stato seguito esattamente
   • Questa potrebbe essere la differenza?
   • Lo metterò alla prova a breve lungo la strada.
3. L'eliminazione di file grandi (o piccoli) dalla directory / home / nella partizione casper (sda3) causa una sorta di corruzione?
   • Non ne ho idea..?
   • Lo metterò alla prova a breve lungo la strada.

Ulteriori test - Voglio la mia risposta!

A partire dall'immagine liveUSB originale.

1. Aggiorna java su liveUSB da 6 a 7
2. Crea / home / utente / cartella /
3. Copia i file di classe per l'applicazione java in / home / utente / cartella /
4. Aggiungi startup.sh in /etc/init.d/
5. Digitare "update-rc.d startup.sh start 21 2 5."
6. Modifica il file di configurazione in /home/user/folder/config.properties

Tutto in una volta passo questa volta. - Funzionerà?

Test 1 - Success / Fail?

FALLIRE!

1. Vecchio metodo di catrame

Test 2 - Success / Fail?

1. Vecchio metodo di catrame
2. File generato eliminato in / boot /
   • Questo file viene creato dal mio script quando viene scritta la partizione casper (sda3), contiene solo un id per la verifica che non ha alcun effetto sul processo di avvio.

Test 3 - Success / Fail?

1. Nuovo metodo tar

Test 4 - Success / Fail?

1. Nuovo metodo tar
2. File generato eliminato in / boot /
   • Questo file viene creato dal mio script quando viene scritta la partizione casper (sda3), contiene solo un id per la verifica che non ha alcun effetto sul processo di avvio.

risultati

Farò dei test in questo ordine:

Test 1 - & gt; Test 3 - & gt; Test 4 - & gt; Test 2

Se il Test 1 funziona ... Andrò a saltare fuori dalla finestra!  - Non avrò idea del motivo per cui ora funzionerebbe come ho provato molte volte e ogni volta ha prodotto scarichi non riusciti.  - Forse il processo cp o tar è stato corrotto in qualche modo.

quando test 1 non riesce: Se Test 3 funziona ...  - Il metodo tar stava causando l'errore.  - Non capisco cosa sarebbe sbagliato con il vecchio metodo tar rispetto al nuovo metodo tar.

TBC ...

Data la tua descrizione del problema, sospetto che stia accadendo qualcosa di diverso da quello che descrivi. In ogni caso, prova questo:

# sda2
mount /dev/sda2 /mnt/tmp
tar -C /mnt/tmp -cf ~/Desktop/sda2.tar .
umount /dev/sda2 
# ... repeat for sda3 ...
# do your create partition shenanigans
mount /dev/newsda2 /mnt/tmp
tar -C /mnt/tmp -xpf ~/Desktop/sda2.tar
umount /dev/newsda2
# repeat ...
# test ..

Se questo funziona, è probabile che la tua / home sia montata noexec o che sia un qualche file system fubar perché il problema è che il bit di esecuzione è stato rimosso.

Se non funziona, modifica lo script di avvio per fornirti informazioni di debug come l'output di mount, il contenuto di syslog, ecc. E cerca l'aiuto lì.

Puoi anche generare checksum per ogni file e confrontare copia vs originale con:

find . -type f -exec sha1sum {} ';' > /tmp/sda2_checksums.txt

per ogni partizione e ampli montati diff i file /tmp/*_checksums.txt

In risposta a Solution Attempts & amp; Gotchas # 2 riguardante l'uso del comando dd:

Usando il comando dd per clonare la Live USB originale non gira in modo permanente il 64GB si attacca in una bacchetta da 16 gb. Lo farà solo se tu scegli di no per ripartizionare la chiavetta da 64 gb dopo aver usato il comando dd. Puoi ridimensionare la parata per recuperare tutto il rimanente spazio libero (non allocato) rimasto sullo stick da 64 gb dopo aver usato il comando dd.

È possibile rivedere le partizioni utilizzando uno di GParted o Parted Magic editor di partizioni per recuperare qualsiasi quantità di spazio libero da 16 GB a 64 GB l'unità flash USB clonata dopo aver utilizzato il comando dd.

L'effetto netto è che il comando dd non gira definitivamente il 64gb incollare in una bacchetta da 16 GB usando GParted o Parted Magic dopo lanciando il comando dd per recuperare il resto della chiavetta da 64 gb.

Usa il programma Linux Disk Utility per la tua distribuzione Linux per verificare il spazio della partizione libero o allocato.

Puoi imparare GParted dal tutorial "GParted partitioning software - Esercitazione completa "all'indirizzo: http://www.dedoimedo.com/computers/gparted.html

Informazioni su Parted Magic sono disponibili su: https://en.wikipedia.org/wiki/PartedMagic ma nella mia esperienza raccomanderei GParted in quanto Parted Magic era una distribuzione completa di strumenti a meno che non si preferisca l'approccio successivo a quello che si scopre a riguardo.

In breve, hai già scoperto la soluzione più semplice al tuo problema, che è solo una partizione ridimensionata se nessuno dei test che hai pianificato alla fine dei tuoi post funziona.