Se copio un'unità USB avviabile su un'altra USB, creerà un'unità di avvio duplicata?


37

Ho pensato che fosse una domanda stupida, ma una ricerca con Google sembra indicare che non è nemmeno possibile copiare / incollare i dati su un'unità avviabile su un'altra USB? Ma anche se fossimo in grado di copiarlo, perché non dovrebbe funzionare? (che sta creando un'unità di avvio duplicata)


2
Cosa intendi con "copia / incolla"? Ovviamente, devi copiare le parti che lo rendono effettivamente un'unità avviabile (come il bootloader, ecc.), Ma non c'è motivo per cui non dovrebbe funzionare.
Jörg W Mittag,

Risposte:


56

La semplice copia dei file non renderà un'unità avviabile. Non sono solo i file su un'unità flash USB a renderlo avviabile, ma la configurazione della tabella delle partizioni , i metadati sull'organizzazione dei contenuti dell'unità, che indicano a un PC se è avviabile e se si tratta di MBR o GPT .

Come notato su cyberciti.biz :

Ogni disco e partizione ha una sorta di firma e stringhe di metadati / magici su di esso. I metadati utilizzati dal sistema operativo per configurare i dischi o collegare i driver e montare i dischi sul sistema.

Tuttavia, è possibile clonare l'unità flash con una serie di strumenti, come dd , EaseUS Todo Backup e l'eccellente e open source Clonezilla e Rufus . (Grazie ad Alex per i promemoria su dd e Rufus).

Esistono persino dispositivi elettronici che replicano automaticamente le unità flash .


15
In realtà non ne hai nemmeno bisogno dd: semplice cpfarà il lavoro - assicurati solo di usarlo sul nodo del dispositivo anziché sul contenuto del filesystem.
Ruslan,

È sorprendente. O forse no. Ma almeno per me.
Jörg W Mittag,

1
'cat <source> destination' funzionerà bene supponendo che la destinazione non sia un lanciatore della sorgente.
ysdx,

@JoL non hai visto il commento (ora cancellato) di Jörg. Il mio era una risposta alla sua affermazione che cpavrebbe semplicemente copiato il nodo del dispositivo. Per evitare confusione, ora ho eliminato anche il mio commento.
Ruslan,

21

La copia copia solo i file in partizioni formattate. Non sarai in grado di fare cose speciali necessarie per il processo di avvio come impostare i flag di avvio, scrivere il boot loader o talvolta copiare anche i file normali nel punto corretto (leggi: settore) nella partizione e impostare gli attributi dei file permessi /. A meno che tu non sia fortunato ad avere quelle cose disponibili, a causa di una precedente creazione del disco di avvio, uno strumento di formattazione che scrive il boot loader nell'MBR, ecc., Dovrai fare più passaggi per rendere avviabile il disco


In particolare quando si avvia in modalità BIOS , il BIOS cerca il primo settore (MBR) per vedere se esiste una firma di avvio valida 0xAA55 . Se sì, carica quel settore e trasferisce il controllo al boot loader nell'MBR. L'MBR descrive la configurazione della partizione, pertanto non può trovarsi all'interno della partizione e non è ciò che è possibile copiare con gli strumenti normali.

Inoltre, poiché l'MBR è troppo piccolo per essere utile, la maggior parte dei caricatori di avvio moderni suddivide il processo di avvio in più fasi , con il codice di avvio nell'MBR carica la fase successiva. Le ulteriori fasi intra vengono spesso poste in regioni esterne alle partizioni . Alcuni potrebbero inserirlo nella BERS , ma di solito grub inserisce il suo secondo stadio nell'area vuota tra la prima partizione e l'MBR chiamato gap post-MBR. Ecco perché se non si allineano correttamente le partizioni, non c'è spazio per grub per inserire il proprio codice di avvio, con conseguente errore di incorporamento

Molti caricatori di avvio come LILO o vecchi caricatori di avvio di Windows / DOS contengono anche informazioni sul codice rigido nell'MBR, come la posizione della fase successiva o dei file di sistema. Non funzionano leggendo i dati della partizione, ma leggono invece alcuni settori con codice rigido, poiché ci vorrà troppo codice per analizzare il file system, che è molto difficile essere compresso in piccoli spazi come l'MBR o il gap post-MBR. Anche grub supporta una codifica così difficile . Ciò significa che alcuni file di sistema devono trovarsi nella posizione esatta , settore per settore, che non è possibile ottenere anche con una copia normale. Questo è il motivo per cui vedi "file di sistema non mobili" durante l'esecuzione della deframmentazione di Windows o della riduzione dei file system, che a volte non è effettivamente corretto, perché è solo che Windows ha troppa paura di spostare quei file anche se i caricatori di avvio moderni sono molto più intelligenti e non si preoccupano di queste cose.

E dopo tutto, devi anche impostare la partizione di avvio come attiva per far sapere al boot loader cosa avviare. Questo deve essere fatto da uno strumento di partizionamento o mediante modifica esadecimale manualmente, poiché è anche posto all'esterno dell'area di partizione.


In UEFI le cose sono molto più facili. Conosce i file system FAT (e anche più file system su implementazioni non standard), quindi i file di avvio sono archiviati nella partizione di sistema EFI, AKA ESP . L'UEFI carica le applicazioni * .efi nell'ESP che caricherà quindi i sistemi operativi.

Il firmware UEFI supporta l'avvio da dispositivi di archiviazione rimovibili come unità flash USB. A tale scopo, un dispositivo rimovibile deve essere formattato con un file system FAT12, FAT16 o FAT32, mentre un boot loader deve essere archiviato secondo la gerarchia di file ESP standard o fornendo un percorso completo di un boot loader al sistema gestore di avvio.

Quindi in pratica devi solo copiare i file * .efi su ESP e mettere i file di sistema nella cartella corretta. Tuttavia, c'è ancora un piccolo problema perché la partizione FAT contenente il file * .efi deve essere contrassegnata come ESP nella tabella MBR o GPT al di fuori delle partizioni, che non può essere eseguita copiando come sopra. In particolare, il tipo di partizione deve essere modificato da 0Ch / 0Bh / qualunque sia in EFh in MBR e in C12A7328-F81F-11D2-BA4B-00A0C93EC93B in GPT, poiché l'ESP non è in realtà FAT12 / 16/32 ma un file system indipendente basato su la famiglia di file system FAT


E ci sono ancora molti altri schemi di partizionamento come l'etichetta del disco BSD o APM che devono essere modificati in modo diverso per l'avvio. Oppure le chiavette USB potrebbero essere state formattate senza una tabella delle partizioni (AFAIK Windows lo fa di default), quindi renderlo avviabile sarà diverso. Ma si applica lo stesso limite: è necessario modificare le aree non partizionate


1
Questa è la risposta corretta
Margaret Bloom,

È la risposta più completa , sì, ma non credo sia più corretta della risposta accettata, a cui l'IMO risponde a una domanda posta in modo semplice.
Ian Kemp,

@IanKemp il problema con la risposta accettata non è che è semplice (va bene) ma che è tecnicamente ambiguo nella migliore delle ipotesi :)
Margaret Bloom

Se si contrassegna un volume della chiavetta USB come attivo - utilizzando l'utilità "diskpart" di Windows cmd line o qualsiasi gestore di partizioni di terze parti, copiando il contenuto di un'immagine ISO di Windows Vista / 7/8/10 la chiavetta diventa la chiavetta di avvio di Windows; all'avvio non si verifica alcun effetto ramdrive o montaggio furthur. Quindi, ovviamente, dopo aver contrassegnato uno stick come attivo, tutto ciò che serve è un piccolo file di immagine di avvio (bootmgr e bootmgr.efi su Windows credo) sullo stick; non sono necessari strumenti complessi. Mi aspetterei una semplice procedura da riga di comando su Linux, molto più semplice di Windows.
Red.Wave

3

Tradizionalmente, l'avvio del BIOS richiedeva un marcatore invisibile speciale. Ecco alcuni esempi :

  • Se MBR-partizionato ("disco rigido"), quindi nella tabella delle partizioni
  • Se floppy / superfloppy ("unità ZIP"), sostanzialmente l'intera unità formattata senza una tabella delle partizioni, quindi entro i primi byte
  • Se CD, quindi El Torito

In questi casi, non è possibile semplicemente copiare i file. L'unità risultante non sarà avviabile perché mancano quei marcatori speciali.

Tuttavia , l'avvio UEFI è speciale, più intelligente e risolve specificamente questi problemi. Come sempre, consiglio di leggere questo post sul blog per un primer semplificato per UEFI. Prendere nota speciale della sezione di avvio di fallback. Questo è anche discusso in modo leggermente più dettagliato qui .

Tutto ciò che serve per farlo funzionare è un file in un percorso specifico in una partizione che il firmware cercherà. Per una compatibilità ottimale 1 , sì, questa dovrebbe essere una partizione formattata FAT32 contrassegnata come partizione di sistema EFI in un disco partizionato GPT. Tuttavia, la maggior parte del firmware cercherà anche partizioni (singole) su dischi con partizioni MBR e non partizionate (superfloppy).

Ciò significa che tutto ciò di cui hai veramente bisogno per l'avvio UEFI è una singola partizione formattata FAT32 1 contenente una voce di avvio di fallback. Su un'architettura x86_64, ciò significa che hai solo bisogno di un \EFI\BOOT\BOOTx64.EFIfile. Puoi semplicemente copiare da un'unità flash a un'altra, incluso quel file, e tutto dovrebbe funzionare.


1 FAT32 e GPT sono richiesti dalla norma. MBR e superfloppy non lo sono, AFAIK, ma il supporto per loro è piuttosto universale tra l'hardware desktop. Il laptop è un po 'più esoterico; i tablet sono un gioco da ragazzi e Mac EFI è unico.

2 Lo standard UEFI richiede il supporto FAT32. Alcuni firmware potrebbero anche supportare NTFS (anche se tutt'altro che garantito) e potresti effettivamente incorporare un driver NTFS in un ESP FAT32.


0

Dipende da cosa intendi per "copia".

Copia e incolla nella GUI del tuo sistema operativo? No, non funzionerà: alcuni file necessari per una USB avviabile saranno considerati "nascosti" / invisibili e non copiati.

Ci sono tipi di copia che vi lavorano. Questo è spesso definito come "imaging" una nuova USB, per differenziarsi dalla "copia" dei suoi contenuti. Il modo più comune per farlo è uno strumento da riga di comando, ma se ne hai bisogno sono disponibili opzioni grafiche.

Questo dovrebbe essere uno sfondo sufficiente per avviare la tua ricerca!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.