mjhjmtu

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)

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.

Copying only copes with files in 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. That means some system files have to be at the exact location, sector-by-sector, 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 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

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 compatibility¹, 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 FAT32¹-formatted single partition containing a fallback boot entry. On an x86_64 architecture, this means you just need a EFIBOOTBOOTx64.EFI file. You can just copy from one flash drive to another, including that file, and everything should work.

¹ 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.

² 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!