Copiando un'immagine tramite risultati dd a volte in un disco non avviabile

Ho la seguente configurazione di dispositivi completamente identici (Modello e Revisione corrispondono):

Dispositivo A: sistema operativo completamente installato, tutto il software richiesto installato.
Dispositivo B: disco vuoto *
Dispositivo C: disco vuoto *

* su tutti i dispositivi è (nel caso di A era) una versione di Ubuntu installata che non voglio usare dato che ho un Debian completo e personalizzato che voglio usare

Così ho preso un'immagine del dispositivo A e il disco lo ho scaricato sul disco del dispositivo B. Dopo di che comparo il crc32 dell'immagine e la memoria del dispositivo B, corrispondono. Avvio B, funziona come un clone completo di A.

Ora eseguo il dump della stessa immagine sul dispositivo C (che è completamente identico a A e B) e confronta nuovamente i loro valori crc32, un'altra corrispondenza. Lo avvio e dice "Nessun supporto avviabile trovato".

Perché questo sta accadendo, il processo di dump ha funzionato senza problemi, come conferma il crc32. Ma perché non funziona? E molto più interessante: come posso risolvere questo problema?

modificare

Uscita di fdisk -l (tutti i dispositivi sono denominati come mmcblk0pX)

Device  Start     End       Sectors   Size
p1            34     97656     97623  47.7M  EFI System
p2         97657   2690217   2592561   1.2G  Microsoft basic data
p3       2691072  13025279  10334208     5G  Linux file system
p4      13025280  14940159   1914880   935M  Linux swap

debian dd grub2

— DBX12
fonte

dd non sta per "disc dump" che fornisce l'esatta esecuzione della stringa e il risultato restituito sarebbe più utile.

— user657451

Stai provando ad avviare con loro tutti collegati? Come sono collegati (usb, sata, esata, scsi)? Hai riconfigurato il bootloader su Xdc per scegliere come target il proprio disco? La tua piattaforma supporta l'avvio dal terzo disco? Hai contrassegnato l'unità / partizione come avviabile?

— user657451

Non ho trovato un nome completo in man dd e il pensiero disc-dump avrebbe senso;) L'HDD dei dispositivi è infatti costruito in chip di memoria (sto usando Intel Compute Sticks). Per il processo di copia avvio da una chiavetta USB attiva, che rimuovo prima di avviarla dalla memoria interna. Gparted dice che il flag di avvio è impostato sulla prima partizione (fat32, 512 MB) come comando che ho usato sudo dd if=image.img of=/dev/mmcblk0 bs=4M nella directory image.img si trova. Restituisce senza errori e dice "1824 + 0 registra in, 1824 + 0 registra, 7.7 GB copiato" E un numero leggermente più dettagliato.

— DBX12

Il che mi suggerisce che l'errore non è riuscire a passare oltre la seconda partizione "dispositivo" o (storicamente più probabile) 4.

— user657451

Non sono sicuro di averlo capito completamente o non sono stato chiaro sulla descrizione del mio dispositivo. A, B e C sono dispositivi fisicamente separati. Ho appena copiato di nuovo l'immagine, ora ho le seguenti partizioni sul mio disco (ogni nome inizia con mmcblk0) p1 (fat16, 47MiB, boot e esp flag set), p2 (fat32, 1.24 GiB, msftdata flag) p3 (ext4, 4.93 GiB, senza bandiere) p4 (linux-swap, 935 MiB, nessun flag) e 1 MiB non allocato. Scusate per la confusione con la partizione fat32 di 512 MB del commento precedente, ho provato ad installare un debian "pulito" ieri che ha lasciato questa partizione, non era neanche avviabile.

— DBX12

Prima di tutto, non ho trovato la ragione. Ma ho trovato una soluzione che va bene per me. Ho avviato la shell EFI e inserito fs0 con fs0: La shell EFI ora richiede qualcosa di simile fs0\ > attraverso cd EFI e cd debian Sono stato in grado di trovare un file chiamato grubx64.efi. Ho eseguito il file inserendo grubx64.efi e ha avviato il sistema, mi ha mostrato GRUB2 dove ho potuto selezionare la mia installazione debian. Si avvia completamente normale e con sudo grub-install e sudo update-grub Sono stato in grado di ripristinare il record EFI in qualche modo rotto. Dopo il riavvio, il dispositivo C si comporta esattamente come i dispositivi B e A.

— DBX12
fonte