Eric Blake <eblake@...> writes: > ...
> > # dd bs=4M if=Downloads/archlinux-2014.10.01-dual.iso of=/dev/sdb && sync > > This says to copy the exact iso over (as much as possible of) the entire > usb stick. If the iso itself contains partitions, then your stick will > now contain those same partitions. > See my comment below. > > # fdisk -l /dev/sdb > > > > Disk /dev/sdb: 3.8 GiB, 4051697152 bytes, 7913471 sectors > > Units: sectors of 1 * 512 = 512 bytes > > Sector size (logical/physical): 512 bytes / 512 bytes > > I/O size (minimum/optimal): 512 bytes / 512 bytes > > Disklabel type: dos > > Disk identifier: 0x574a1394 > > > > Device Boot Start End Sectors Size Id Type > > /dev/sdb1 * 0 1171455 1171456 572M 0 Empty > > /dev/sdb2 252 63739 63488 31M ef EFI (FAT-12/16/32) > > In fact, it looks like the iso image intentionally contains two > partitions, with the /dev/sdb2 partition existing to make it possible to > boot your USB stick on a UEFI system. > It looks like fdisk, cfdisk, etc are confused about identifying those partitions and their start/end sectors. Is there a partition table at all ? If so, where is it located, sectorwise ? > > Question: > > I dd-ed an iso file (it is a bit-for-bit copy/cloning), which resulted in > > sdb1. > > What is this sdb2 about, where did it come from ? > > It was put in the iso by the person that created it. This is not a bug > in dd, which faithfully copied the entire iso contents to your disk. > There's nothing wrong here. > ... Ouch ! What dd does is not a neutral cloning (bit-by-bit) but some kind of transformation of a source (if=) to different binary object targets. Is that by design ? I was not aware of such dd's capability ... Also, is such behavior by dd not risky w/r to making backups by cloning ? After all, the purpose of a backup is to have it restored, eventually, in a symmetrical, one-to-one manner. There is nothing in dd(1) about such a capability. jb
