I thought it's kind of a dumb question but a search with Google seems to indicate that it is not even possible to copy/paste data on a bootable drive to another USB? But even if we were able to copy it, why should it not work? (that is creating a duplicate bootable drive)

  • 3
    What do you mean by "copy/paste"? Obviously, you have to copy the parts that actually make it a bootable drive (such as the bootloader, etc.) but there is no reason this should not work. Commented Sep 6, 2018 at 7:51

4 Answers 4


Simply copying the files will not make a bootable drive. It's not only the files on a USB flash drive which make it bootable, but the partition table configuration, the metadata about the organization of the drive contents, which tells a PC if it is bootable, and whether it is MBR or GPT.

As noted at cyberciti.biz:

Each disk and partition has some sort of signature and metadata/magic strings on it. The metadata used by operating system to configure disks or attach drivers and mount disks on your system.

However, you can clone the flash drive with a number of tools, such as dd, EaseUS Todo Backup, and the excellent and open source Clonezilla and Rufus. (Thanks to Alex for the reminders about dd and Rufus).

There are even electronic devices which automatically replicate flash drives.

  • 16
    Actually you don't even need dd: simple cp will do the work — just be sure to use it on the device node instead of filesystem content.
    – Ruslan
    Commented Sep 6, 2018 at 7:51
  • Uh, that is surprising. Or maybe not. But to me at least. Commented Sep 6, 2018 at 14:25
  • 1
    'cat < source > destination' will work alright asuming the destination is no shoter than the source.
    – ysdx
    Commented Sep 6, 2018 at 18:50
  • @JoL you've not seen the (now deleted) comment by Jörg. Mine was a reply to his assertion that cp would simply copy the device node. To prevent confusion, I've now deleted my comment too.
    – Ruslan
    Commented Sep 7, 2018 at 5:58

Copying only copes with files inside formatted partitions. You won't be able to do special things necessary for the boot process like setting the boot flags, writing the boot loader, or sometimes even copying normal files into the correct spot (read: sector) in the partition and set the files' attributes/permissions. Unless you're lucky to have those things available, due to a previous boot disk creation, a formatting tool that writes the boot loader to the MBR, etc., you'll need to do more steps to make the disk bootable

Specifically when booting in BIOS mode, the BIOS looks for the first sector (MBR) to see if there's a valid boot signature 0xAA55. If yes then it loads that sector and transfer control to the boot loader in the MBR. The MBR describes the partition configuration, therefore it cannot lie inside the partition and is not what you can copy with normal tools.

Besides, since the MBR is too small to be useful, most modern boot loaders split the boot process into multiple stages, with the boot code in the MBR loads its next stage. The further intra-stages are again often put in regions outside the partitions. Some may put it in the EBR, but grub usually put its second stage in the empty area between the first partition and the MBR called the post-MBR gap. That's why if one doesn't align the partitions properly, there's no space for grub to put its boot code, resulting in embedding error

Many boot loaders like LILO or old Windows/DOS boot loaders also hard code information in the MBR, like the position of the next stage or of the system files. They don't work by reading the partition data but read some hard coded sector instead, since it'll take too much code to parse the file system which is very hard to be squeezed into tiny spaces like the MBR or post-MBR gap. Even grub supports such hard coding although it's fragile hence not recommended. That means some system files have to be at the exact location sector-wise, which you can't also achieve with a normal copy. That's the reason you see "non-movable system files" while running Windows defragmenter or shrinking file systems, which is sometimes not actually correct, because it's just that Windows is too afraid to move those files even though modern boot loaders are a lot bigger, smarter and don't care about such things.

And after all, you also need to set the boot partition as active to let the boot loader know what to boot. That has to be done by a partitioning tool or by hex editing manually, since it's also put outside the partition area.

In UEFI things are a lot easier. It knows about FAT file systems (and even more file systems on non-standard implementations), therefore boot files are stored in the EFI system partition, A.K.A ESP. The UEFI loads the *.efi applications in the ESP which will then load the operating systems.

UEFI firmware supports booting from removable storage devices such as USB flash drives. For that purpose, a removable device needs to be formatted with a FAT12, FAT16 or FAT32 file system, while a boot loader needs to be stored according to the standard ESP file hierarchy, or by providing a complete path of a boot loader to the system's boot manager.

So basically you just need to copy the *.efi file(s) to the ESP and put system files in the correct folder. However, there's still a small problem because the FAT partition containing the *.efi file must be marked as ESP in the MBR or GPT table outside the partitions, which can't be done by copying like above. In particular the partition type must be changed from 0Ch/0Bh/whatever to EFh in MBR and to C12A7328-F81F-11D2-BA4B-00A0C93EC93B in GPT, since the ESP is not actually FAT12/16/32 but an independent file system based on the FAT file system family

And there are still many other partitioning schemes like BSD disk label or APM which need to be modified differently to boot. Or the USB sticks might have been formatted without a partition table at all (AFAIK Windows does this by default), therefore making it bootable will be different. But the same limit applies: you need to modify non-partitioned areas!!!

  • 1
    This is the correct answer. Commented Sep 6, 2018 at 6:42
  • It is the most thorough answer, yes, but I don't believe it's more correct than the accepted answer, which IMO answers a simply-put question in a simple manner.
    – Ian Kemp
    Commented Sep 7, 2018 at 7:57
  • @IanKemp the problem with the accepted answer is not that it is simple (that's good) but that it's technically ambiguous at best :) Commented Sep 7, 2018 at 10:46
  • If you mark a USB stick volume as active - using windows cmd line "diskpart" utility or any 3rd party partition manager - by copying the contents of a windows vista/7/8/10 ISO image the stick becomes windows boot stick; no ramdrive thing or furthur mounting happens at booting. So obviously, after marking a stick as active, all you need is a small boot image file (bootmgr and bootmgr.efi on windows I guess) on the stick; no need for complex tools. I would expect a simple command line procedure on Linux, way easier than windows.
    – Red.Wave
    Commented Oct 5, 2019 at 20:45

Traditionally, BIOS boot required a special invisible marker. Here's a few examples:

  • If MBR-partitioned ("hard disk"), then within the partition table
  • If floppy/superfloppy ("ZIP drive"), basically the entire drive formatted without a partition table, then within the first few bytes
  • If CD, then El Torito

In those cases, you cannot simply copy files. The resulting drive will be unbootable because it is missing those special markers.

However, UEFI boot is special, smarter, and specifically addresses these issues. As always, I recommend reading this blog post for a simplified primer to UEFI. Take special note of the fallback boot section. This is also discussed in slightly more detail here.

All you need for this to work is a file in a specific path in a partition that the firmware will search. For optimal compatibility1, yes, this should be a FAT32-formatted partition marked as a EFI System Partition in a GPT-partitioned disk. However, most firmware will also search (single) partitions on MBR-partitioned and unpartitioned (superfloppy) disks.

This means all you really need for UEFI boot is a FAT321-formatted single partition containing a fallback boot entry. On an x86_64 architecture, this means you just need a \EFI\BOOT\BOOTx64.EFI file. You can just copy from one flash drive to another, including that file, and everything should work.

1 FAT32 and GPT are required by the standard. MBR and superfloppy are not, AFAIK, but support for them is pretty universal among desktop hardware. Laptop is a little more esoteric; tablets are a toss-up, and Mac EFI is unique.

2 The UEFI standard requires FAT32 support. Some firmware might also support NTFS (though far from guaranteed), and you could actually embed a NTFS driver within a FAT32 ESP.


It depends what you mean by 'copy'.

Copy and Paste in your operating system's GUI? No, that won't work - some files a bootable USB needs will be considered "hidden"/invisible and not copied.

There are types of copy that will work. This is often referred to as 'imaging' a new USB, to differentiate from 'copying' its contents. The most common way to do this is a command-line tool, but graphical options are available if you need them.

That should be enough background to get your search on track!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .