Re: dd effect on cloning of iso file to usb stick

[Bernhard Voelker]

On 10/03/2014 12:33 AM, jb wrote:
> # dd bs=4M if=Downloads/archlinux-2014.10.01-dual.iso of=/dev/sdb && sync
> 143+0 records in
> 143+0 records out
> 599785472 bytes (600 MB) copied, 157.154 s, 3.8 MB/s

...

> $ lsblk -f
> ...
> sdb    iso9660 ARCH_201410 2014-10-01-05-00-04-00
> ├─sdb1 iso9660 ARCH_201410 2014-10-01-05-00-04-00
> └─sdb2 vfat    ARCHISO_EFI A05B-32C8
> ...
>
> # 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)

> 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 ?

As Eric already explained, there's nothing strange about dd(1) here.
Nothing prevents you from running this command:

  $ fdisk -l Downloads/archlinux-2014.10.01-dual.iso

I'm pretty sure that you'll see the same result as the
fdisk output from the target /dev/sdb.

For dd(1), it's all just data - byte per byte.
It's the interpretation of the data that makes the difference.
The kernel e.g. has to check if there's a partition table at the
beginning of a device, /dev/sdb in this case, and indeed there is one.
Therefore, it provides access to the partitions as sdb{1,2}.

Given you knew the offset of the file system in the second partition
of the ISO file, then you could also loop-mount it directly by using
the 'offset' and 'sizelimit' options of mount/losetup.
  man losetup; man mount

Again, this all has not much to do with dd(1) and coreutils.

Have a nice day,
Berny