Jika saya menyalin drive USB yang dapat di-boot ke USB lain, apakah ini akan membuat drive yang dapat di-boot duplikat?


37

Saya pikir itu semacam pertanyaan bodoh, tetapi pencarian dengan Google tampaknya mengindikasikan bahwa bahkan tidak mungkin untuk menyalin / menempel data pada drive yang dapat di-boot ke USB lain? Tetapi bahkan jika kita dapat menyalinnya, mengapa itu tidak berhasil? (yang membuat drive bootable duplikat)


2
Apa yang Anda maksud dengan "copy / paste"? Jelas, Anda harus menyalin bagian-bagian yang sebenarnya membuatnya menjadi drive yang dapat di-boot (seperti bootloader, dll.) Tetapi tidak ada alasan ini seharusnya tidak berfungsi.
Jörg W Mittag

Jawaban:


56

Cukup menyalin file tidak akan membuat drive bootable. Bukan hanya file pada USB flash drive yang membuatnya dapat di-boot, tetapi konfigurasi tabel partisi , metadata tentang pengorganisasian konten drive, yang memberi tahu PC jika itu dapat di- boot , dan apakah itu MBR atau GPT .

Sebagaimana dicatat di cyberciti.biz :

Setiap disk dan partisi memiliki semacam tanda tangan dan string metadata / sihir di atasnya. Metadata yang digunakan oleh sistem operasi untuk mengkonfigurasi disk atau melampirkan driver dan me-mount disk pada sistem Anda.

Namun, Anda dapat mengkloning flash drive dengan sejumlah alat, seperti dd , EaseUS Todo Backup , dan Clonezilla dan Rufus . (Terima kasih kepada Alex untuk pengingat tentang dd dan Rufus).

Bahkan ada perangkat elektronik yang secara otomatis mereplikasi flash drive .


15
Sebenarnya Anda bahkan tidak perlu dd: sederhana cpakan melakukan pekerjaan - pastikan untuk menggunakannya pada node perangkat, bukan konten sistem file.
Ruslan

Eh, itu mengejutkan. Atau mungkin tidak. Tapi setidaknya bagiku.
Jörg W Mittag

1
'cat <source> destination' akan berfungsi dengan baik dengan asumsi bahwa destinasi itu bukan penembak selain sumbernya.
ysdx

@ JoL Anda belum melihat komentar (sekarang dihapus) oleh Jörg. Milik saya adalah jawaban atas pernyataannya yang cphanya akan menyalin node perangkat. Untuk mencegah kebingungan, sekarang saya telah menghapus komentar saya juga.
Ruslan

21

Menyalin hanya salinan dengan file di partisi yang diformat. Anda tidak akan dapat melakukan hal-hal khusus yang diperlukan untuk proses boot seperti mengatur flag boot, menulis boot loader, atau kadang-kadang bahkan menyalin file normal ke tempat yang benar (baca: sektor) di partisi dan mengatur atribut file ' / izin. Kecuali Anda beruntung memiliki hal-hal itu tersedia, karena pembuatan disk boot sebelumnya, alat pemformatan yang menulis boot loader ke MBR, dll., Anda harus melakukan lebih banyak langkah untuk membuat disk tersebut dapat di-boot


Khususnya ketika boot dalam mode BIOS , BIOS mencari sektor pertama (MBR) untuk melihat apakah ada tanda tangan boot yang valid 0xAA55 . Jika ya maka ia memuat sektor itu dan mentransfer kontrol ke boot loader di MBR. MBR menjelaskan konfigurasi partisi, oleh karena itu ia tidak dapat terletak di dalam partisi dan bukan apa yang dapat Anda salin dengan alat normal.

Selain itu, karena MBR terlalu kecil untuk berguna, kebanyakan boot loader modern membagi proses boot menjadi beberapa tahap , dengan kode boot dalam MBR memuat tahap berikutnya. Tahap intra lebih lanjut lagi sering ditempatkan di daerah di luar partisi . Beberapa mungkin meletakkannya di EBR , tetapi grub biasanya meletakkan tahap kedua di area kosong antara partisi pertama dan MBR yang disebut celah post-MBR. Itu sebabnya jika seseorang tidak menyelaraskan partisi dengan benar, tidak ada ruang bagi grub untuk meletakkan kode boot-nya, menghasilkan kesalahan embedding

Banyak boot loader seperti LILO atau boot loader Windows / DOS lama juga informasi kode keras di MBR, seperti posisi tahap berikutnya atau file sistem. Mereka tidak bekerja dengan membaca data partisi tetapi membaca beberapa sektor kode keras sebagai gantinya, karena itu akan mengambil terlalu banyak kode untuk mem-parsing sistem file yang sangat sulit untuk diperas ke dalam ruang kecil seperti MBR atau post-MBR gap. Bahkan grub mendukung hard coding semacam itu . Itu berarti beberapa file sistem harus berada di lokasi yang tepat , sektor demi sektor, yang tidak dapat Anda capai dengan salinan normal. Itulah alasan Anda melihat "file sistem tidak bergerak" saat menjalankan Windows defragmenter atau menyusut sistem file, yang kadang-kadang tidak benar-benar benar, karena hanya saja Windows terlalu takut untuk memindahkan file-file itu meskipun boot loader modern jauh lebih pintar dan tidak peduli tentang hal-hal seperti itu.

Dan setelah semua, Anda juga perlu mengatur partisi boot sebagai aktif untuk membiarkan boot loader tahu apa yang harus di-boot. Itu harus dilakukan oleh alat partisi atau dengan pengeditan hex secara manual, karena itu juga diletakkan di luar area partisi.


Dalam UEFI banyak hal lebih mudah. Ia tahu tentang sistem file FAT (dan bahkan lebih banyak sistem file pada implementasi non-standar), oleh karena itu file boot disimpan di partisi sistem EFI, AKA ESP . UEFI memuat aplikasi * .efi di ESP yang kemudian akan memuat sistem operasi.

Firmware UEFI mendukung booting dari perangkat penyimpanan yang dapat dilepas seperti USB flash drive. Untuk tujuan itu, perangkat yang dapat dilepas perlu diformat dengan sistem file FAT12, FAT16 atau FAT32, sementara boot loader perlu disimpan sesuai dengan hierarki file ESP standar, atau dengan menyediakan jalur lengkap boot loader ke sistem. manajer boot.

Jadi pada dasarnya Anda hanya perlu menyalin file * .efi ke ESP dan meletakkan file sistem di folder yang benar. Namun, masih ada masalah kecil karena partisi FAT yang berisi file * .efi harus ditandai sebagai ESP di tabel MBR atau GPT di luar partisi, yang tidak dapat dilakukan dengan menyalin seperti di atas. Khususnya tipe partisi harus diubah dari 0Ch / 0Bh / apa pun ke EFh di MBR dan ke C12A7328-F81F-11D2-BA4B-00A0C93EC93B dalam GPT, karena ESP sebenarnya bukan FAT12 / 16/32 tetapi sistem file independen berdasarkan keluarga sistem file FAT


Dan masih ada banyak skema partisi lain seperti label disk BSD atau APM yang perlu dimodifikasi secara berbeda untuk boot. Atau stik USB mungkin telah diformat tanpa tabel partisi sama sekali (AFAIK Windows melakukan ini secara default), oleh karena itu membuatnya dapat di-boot akan berbeda. Tetapi batas yang sama berlaku: Anda perlu memodifikasi area yang tidak dipartisi


1
Ini jawaban yang benar.
Margaret Bloom

Itu adalah jawaban yang paling menyeluruh , ya, tapi saya tidak percaya itu lebih benar daripada jawaban yang diterima, yang IMO menjawab pertanyaan sederhana dengan cara sederhana.
Ian Kemp

@IanKemp masalah dengan jawaban yang diterima bukanlah bahwa itu sederhana (itu bagus) tetapi itu secara teknis ambigu terbaik :)
Margaret Bloom

Jika Anda menandai volume stik USB sebagai aktif - menggunakan jendela cmd line "diskpart" utility atau manajer partisi pihak ke-3 - dengan menyalin konten windows vista / 7/8/10 ISO image, stik tersebut menjadi stik boot windows; tidak ada hal ramdrive atau pemasangan furthur yang terjadi saat booting. Jadi jelas, setelah menandai tongkat sebagai aktif, yang Anda butuhkan adalah file image boot kecil (bootmgr dan bootmgr.efi di windows saya kira) pada stick; tidak perlu alat yang rumit. Saya akan mengharapkan prosedur baris perintah sederhana di Linux, jauh lebih mudah daripada windows.
Merah. Gelombang

3

Secara tradisional, boot BIOS membutuhkan penanda khusus yang tidak terlihat. Berikut beberapa contoh :

  • Jika MBR-dipartisi ("hard disk"), maka di dalam tabel partisi
  • Jika floppy / superfloppy ("ZIP drive"), pada dasarnya seluruh drive diformat tanpa tabel partisi, maka dalam beberapa byte pertama
  • Jika CD, maka El Torito

Dalam kasus itu, Anda tidak bisa hanya menyalin file. Drive yang dihasilkan tidak dapat di-boot karena tidak memiliki marker khusus tersebut.

Namun , UEFI boot khusus, lebih cerdas, dan secara khusus mengatasi masalah ini. Seperti biasa, saya sarankan membaca posting blog ini untuk primer yang disederhanakan untuk UEFI. Perhatikan bagian boot fallback khusus. Ini juga dibahas sedikit lebih detail di sini .

Yang Anda perlukan agar ini berfungsi adalah file di jalur tertentu di partisi yang akan dicari firmware. Untuk kompatibilitas optimal 1 , ya, ini haruslah partisi yang diformat FAT32 yang ditandai sebagai Partisi Sistem EFI dalam disk yang dipartisi GPT. Namun, sebagian besar firmware juga akan mencari partisi (tunggal) pada disk MBR yang dipartisi dan tidak dipartisi (superfloppy).

Ini berarti semua yang Anda butuhkan untuk UEFI boot adalah partisi tunggal FAT32 1 yang diformat yang berisi entri boot mundur. Pada arsitektur x86_64, ini berarti Anda hanya perlu \EFI\BOOT\BOOTx64.EFIfile. Anda cukup menyalin dari satu flash drive ke yang lain, termasuk file itu, dan semuanya akan berfungsi.


1 FAT32 dan GPT diperlukan oleh standar. MBR dan superfloppy bukan, AFAIK, tetapi dukungan untuk mereka cukup universal di antara perangkat keras desktop. Laptop sedikit lebih esoteris; tablet adalah undian, dan Mac EFI adalah unik.

2 Standar UEFI membutuhkan dukungan FAT32. Beberapa firmware mungkin juga mendukung NTFS (meskipun jauh dari dijamin), dan Anda sebenarnya bisa menanamkan driver NTFS dalam FAT32 ESP.


0

Itu tergantung apa yang Anda maksud dengan 'copy'.

Salin dan Tempel di GUI sistem operasi Anda? Tidak, itu tidak akan berfungsi - beberapa file yang dibutuhkan oleh bootable USB akan dianggap "tersembunyi" / tidak terlihat dan tidak disalin.

Ada beberapa jenis salinan yang akan berfungsi. Ini sering disebut sebagai 'pencitraan' USB baru, untuk membedakan dari 'menyalin' isinya. Cara paling umum untuk melakukan ini adalah alat baris perintah, tetapi opsi grafis tersedia jika Anda membutuhkannya.

Itu harus menjadi latar belakang yang cukup untuk mendapatkan pencarian Anda di jalur!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.