dd effect on cloning of iso file to usb stick

[jb]

Hi,

could you please explain what happened to the iso cloning ?

$ ls -al Downloads/
-rw-r--r-- 1 jb jb 599785472 Oct 2 22:39 archlinux-2014.10.01-dual.iso

The iso size is 572M.
Verified sha1sum.

My usb stick:
$ dmesg
...
[Thu Oct 2 07:59:24 2014] usb-storage 1-1:1.0: USB Mass Storage device detected
[Thu Oct 2 07:59:24 2014] scsi4 : usb-storage 1-1:1.0
[Thu Oct 2 07:59:25 2014] scsi 4:0:0:0: Direct-Access SanDisk Cruzer
8.02 PQ: 0 ANSI: 0 CCS
[Thu Oct 2 07:59:25 2014] sd 4:0:0:0: [sdb] 7913471 512-byte logical
blocks: (4.05 GB/3.77 GiB)
[Thu Oct 2 07:59:25 2014] sd 4:0:0:0: [sdb] Write Protect is off
...

# dd if=/dev/zero of=/dev/sdb
dd: writing to ‘/dev/sdb’: No space left on device
7913472+0 records in
7913471+0 records out
4051697152 bytes (4.1 GB) copied, 1024.08 s, 4.0 MB/s

$ lsblk
...
sdb 8:16 1 3.8G 0 disk
...
$ lsblk -f
...
sdb
...

# 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
...
sdb 8:16 1 3.8G 0 disk
├─sdb1 8:17 1 572M 0 part
└─sdb2 8:18 1 31M 0 part
...
$ 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)

# mount -t auto /dev/sdb1 /mnt
mount: /dev/sdb1 is write-protected, mounting read-only
# ls -al /mnt
total 14
drwxr-xr-x 1 root root 2048 Oct 1 06:58 .
drwxr-xr-x 18 root root 4096 Sep 5 07:23 ..
drwxr-xr-x 1 root root 2048 Oct 1 06:59 arch
drwxr-xr-x 1 root root 2048 Oct 1 06:58 EFI
drwxr-xr-x 1 root root 2048 Oct 1 06:58 isolinux
drwxr-xr-x 1 root root 2048 Oct 1 06:58 loader
# ls -al /mnt/EFI/
total 1634
drwxr-xr-x 1 root root 2048 Oct 1 06:58 .
drwxr-xr-x 1 root root 2048 Oct 1 06:58 ..
drwxr-xr-x 1 root root 2048 Oct 1 06:58 archiso
drwxr-xr-x 1 root root 2048 Oct 1 06:58 boot
-rw-r--r-- 1 root root 771136 Oct 1 06:58 shellx64_v1.efi
-rw-r--r-- 1 root root 893184 Oct 1 06:58 shellx64_v2.efi

# mount -t auto /dev/sdb2 /media/
# ls -al /media/
total 24
drwxr-xr-x 4 root root 16384 Jan 1 1970 .
drwxr-xr-x 18 root root 4096 Sep 5 07:23 ..
drwxr-xr-x 4 root root 2048 Oct 1 06:58 EFI
drwxr-xr-x 3 root root 2048 Oct 1 06:58 loader
# ls -al /media/EFI/
total 1650
drwxr-xr-x 4 root root 2048 Oct 1 06:58 .
drwxr-xr-x 4 root root 16384 Jan 1 1970 ..
drwxr-xr-x 2 root root 2048 Oct 1 06:58 archiso
drwxr-xr-x 2 root root 2048 Oct 1 06:58 boot
-rwxr-xr-x 1 root root 771136 Oct 1 06:58 shellx64_v1.efi
-rwxr-xr-x 1 root root 893184 Oct 1 06:58 shellx64_v2.efi

# df
...
/dev/sdb1 585728 585728 0 100% /mnt
/dev/sdb2 31662 26104 5558 83% /media

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 ?

I see the above happen with Arch Linux iso, but not with Fedora iso:
# lsblk
...
sdb 8:16 1 3.8G 0 disk
└─sdb1 8:17 1 598M 0 part
...
# lsblk -f
...
sdb iso9660 Fedora-Live-LXDE-i686-20-1
2013-12-12-03-47-50-00
└─sdb1 iso9660 Fedora-Live-LXDE-i686-20-1
2013-12-12-03-47-50-00
...

jb

[Eric Blake]

Post by jb
Hi,
could you please explain what happened to the iso cloning ?
$ ls -al Downloads/
-rw-r--r-- 1 jb jb 599785472 Oct 2 22:39 archlinux-2014.10.01-dual.iso

If you install libguestfs-tools, you can run 'virt-inspector -a
archlinux-2014.10.01-dual.iso' to see exactly what is in that iso.

Post by jb
# 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.

Post by jb
# 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.

Post by jb
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.
That's because the particular Fedora iso you chose to play with does not
contain multiple partitions, perhaps because it was designed for BIOS
booting rather than UEFI booting. But still off-topic for coreutils.

[jb]

Post by Eric Blake
...

Post by jb
# 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.

Post by Eric Blake

Post by jb
# 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 ?

Post by Eric Blake

Post by jb
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

[Eric Blake]

Post by jb
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 ?

No, they are all accurately reading the partition table. The partition
table lives in sector 0 of both the .iso and of your just-written
/dev/sdb, and it is that partition table that then tells the kernel
where the boundaries of /dev/sdb1 and /dev/sdb2 are, if that partition
table was encoded to list multiple partitions.

Post by jb
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.

You sound confused. How do you think disks work? /dev/sdb is how you
access EVERY SINGLE SECTOR of the underlying device; and it is the
bit-perfect copy that you wrote into sector zero that says how to
interpret the rest of the sectors.

Post by jb
Is that by design ? I was not aware of such dd's capability ...

dd just did a byte-wise copy. ANY program that does a byte-wise copy on
sector boundaries would have the same result; it's nothing special about
dd. How do you think fdisk writes partitions? By writing to sector
zero of the raw disk.

Post by jb
Also, is such behavior by dd not risky w/r to making backups by cloning ?

Actually, when cloning a hard drive, you WANT to copy the entire image,
including sector zero, to cover ALL partitions (and any file systems
embedded within those partitions), and NOT limit the copy to a single
partition. There's a reason that it is usually only root that can
access /dev/sdb, so that ordinary users don't accidentally clobber their
hard drive; but the point remains that the ability to byte-wise clone
all partitions of a disk in one command is a nice feature when it is needed.

Post by jb
After all, the purpose of a backup is to have it restored, eventually, in
a symmetrical, one-to-one manner.

Your usb stick IS a symmetrical one-to-one copy of the iso - the iso
itself was encoded with multiple partitions. It's no different than
what virtual machine disk images can do - a single file within the file
system of the host machine which looks like a disk with multiple
partitions to the guest machine. It's all in how people agree to
interpret the data in sector 0.

Post by jb
There is nothing in dd(1) about such a capability.

What would you add? Patches are welcome, if you think there's a
shortcoming in the coreutils documentation.

[jb]

...

What if I wanted to retain the standard bit-by-bit cloning ability, that is,
to clone file.iso to file.iso on a usb stick, without that on-the-fly iso
transformation to multiple partitions ?
How would I go about making a classic backup/cloning of file.iso with dd ?

jb

[Eric Blake]

Post by jb

...

What if I wanted to retain the standard bit-by-bit cloning ability, that is,
to clone file.iso to file.iso on a usb stick, without that on-the-fly iso
transformation to multiple partitions ?

Then copy your file into a file system already residing on a partition
of the disk, rather than to the entire disk.

Post by jb
How would I go about making a classic backup/cloning of file.iso with dd ?

Assuming you have already formatted /dev/sdb1 to contain the filesystem
of your choice (usb sticks usually use FAT, but that's a horrible
filesystem, so I prefer ext4), then:

mount /dev/sdb1 /mnt/whatever
dd if=file.iso of=/mnt/whatever/file.iso

Or even

cp file.iso /mnt/whatever/file.iso

as soon as you are talking about moving the iso as a file, rather than
as a disk image, then use normal file system operations instead of raw
access to /dev/sdb.

[Bob Proulx]

Post by jb
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 ?

If fdisk and cfdisk are confused then it is probably because the
partition table used in the image is one of the newer formats. Newer
formats have expanded capabilities. But the older fdisk and cfdisk
tools haven't been updated yet to deal with those partitions.

Basically seeing fdisk confused about a partition table is normal if
the partition table is a newer format than it knows how to deal with.
You might try using parted to print the partition table. It has been
updated for the newer formats.

parted /dev/sdb print

Post by jb
What if I wanted to retain the standard bit-by-bit cloning ability,
that is, to clone file.iso to file.iso on a usb stick, without that
on-the-fly iso transformation to multiple partitions ? How would I
go about making a classic backup/cloning of file.iso with dd ?

There is no "on-the-fly iso transformation". That is simply confusion.

As Eric has explained the /dev/sdb device is the entire raw disk
device. When you read or write to it you are not reading and writing
to a file system. You are reading and writing to the raw bits. By
copying an ISO image to the raw disk you are copying the ISO to the
raw disk. Since the ISO image has a file system on it that file
system is cloned to the /dev/sdb device.

Any time you see "/dev" in a path then know that you are using the raw
device files and not a file system. If you were using wanting to
simply copy the file as a file from one place to another then don't
use don't use /dev but use the mounted location such as "/mnt" or
"/media" would would be the file system location.

To copy the file as a file it is simplest to use cp.

cp Downloads/archlinux-2014.10.01-dual.iso /media/usbdisk/

Note that the above assumes that the usb has been prepared as a
storage device with a file system on it. It either came pre-formatted
or you formatted it yourself. Either way. Then it was mounted either
manually by you or automatically by your desktop session manager to
the /media/usbdisk location. A typical place. Then if you want to
simply copy the file as a file then just simply copy the file as a
file.

Often dd is used to create bootable media. If the iso image is
bootable then copying it to the entire raw usb device will make the
usb device bootable too. Copying to the raw device will destroy
anything that was previously there and will replace it with the
contents of what you are copying onto it. Using dd is good for that
type of task of creating bootable devices. This is very used to
create bootable media that can then be used to boot off of to install
new operating systems such as Arch in your example iso above.

Bob

[jb]

Post by Bob Proulx

Post by jb
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 ?

If fdisk and cfdisk are confused then it is probably because the
partition table used in the image is one of the newer formats. Newer
formats have expanded capabilities. But the older fdisk and cfdisk
tools haven't been updated yet to deal with those partitions.
Basically seeing fdisk confused about a partition table is normal if
the partition table is a newer format than it knows how to deal with.
You might try using parted to print the partition table. It has been
updated for the newer formats.
parted /dev/sdb print
...

First fdisk:

# fdisk -l /dev/sdb
...
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)

Some more (weird) entries:

# fdisk -l /dev/sdb1

Disk /dev/sdb1: 572 MiB, 599785472 bytes, 1171456 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/sdb1p1 * 0 1171455 1171456 572M 0 Empty
/dev/sdb1p2 252 63739 63488 31M ef EFI (FAT-12/16/32)

Any comment on these /dev/sdb1p1 and /dev/sdb1p2 device names ?

# fdisk -l /dev/sdb2

Disk /dev/sdb2: 31 MiB, 32505856 bytes, 63488 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: 0x00000000

Now parted:

# parted /dev/sdb unit s print
Model: SanDisk Cruzer (scsi)
Disk /dev/sdb: 7913471s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
2 252s 63739s 63488s primary fat16 esp

What happened to first partition ?

Some more (weird) entries:

# parted /dev/sdb1 unit s print
Model: Unknown (unknown)
Disk /dev/sdb1: 1171456s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
2 252s 63739s 63488s primary fat16 esp

# parted /dev/sdb2 unit s print
Model: Unknown (unknown)
Disk /dev/sdb2: 63488s
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number Start End Size File system Flags
1 0s 63487s 63488s fat16

Somewhat unusual :-)

jb

[Bob Proulx]

Post by jb

Post by Bob Proulx
parted /dev/sdb print
...

# fdisk -l /dev/sdb
...
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)

That looks okay. fdisk handles it okay.

Post by jb
# fdisk -l /dev/sdb1

Weird that you would ask fdisk to look at /dev/sdb1 instead of
/dev/sdb which is where the partition table would reside. There isn't
normally a partition table at /dev/sdb1.

Post by jb
Any comment on these /dev/sdb1p1 and /dev/sdb1p2 device names ?

Yes. You don't normally have a partition table at /dev/sdb1. Looking
there for one is like looking for meaning in clouds and tea leaves.
Something might randomly look like something but it isn't there by
design.

Post by jb
# fdisk -l /dev/sdb2

Again, there isn't normally a partition table at /dev/sdb2. What
makes you want to look there for one? That would normally be the
start of either file system or swap or other data use for that
partition. The partition table is at /dev/sdb.

Post by jb
# parted /dev/sdb unit s print
Model: SanDisk Cruzer (scsi)
Disk /dev/sdb: 7913471s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
2 252s 63739s 63488s primary fat16 esp
What happened to first partition ?

It was empty and so not displayed. The above shows basically the same
information as fdisk displayed. Since fdisk handled it there isn't
anything more for parted to add. The value for me is when fdisk can't
handle the partition table and then parted usually will be able to do so.

Post by jb
# parted /dev/sdb1 unit s print

Yes. Weird that you would try to print a partition table from
/dev/sdb1. There isn't one there normally.

Post by jb
# parted /dev/sdb2 unit s print

Same thing again for /dev/sdb2. Garbage in produces garbage out.

Post by jb
Somewhat unusual :-)

I think you are still missing the understanding that /dev/sdb is the
entire disk from start to finish of the disk. One creates a partition
table at the first disk block. That divides up the rest of the disk
into partitions. The first partition is /dev/sdb1 and the second is
/dev/sdb2 and so forth. File systems, swap, other users are placed
into those partitions. There isn't usually *another* partition table
placed there.

Of course I have to qualify everything with a "normally" or "usually"
and so forth. Because it is all like a book with blank sheets of
paper. Normally the title is at the front and chapters in the middle.
But that doesn't prevent someone from writing things into the blank
sheets in an unusual way. The disk is like that too. Nothing
prevents someone from copying a disk image which contains a partition
table into a primary partition on a disk. In that case it will appear
that there are two partition tables. And that could be applied again
and again.

But that is like copying the contents of one book into the blank
sheets of a blank book. And then copying another book into its blank
sheets and so on. Yes you can copy a book that way but you don't
normally find books that have been done that way. Most books have a
title up front, table of contents, body content in that order. Disks
are the same way. Most disks have a partition table dividing up the
disk into partitions. Then those partitions are used to hold file
system data.

Bob

[Bernhard Voelker]

Post by jb
# 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

...

Post by jb
$ 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)
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

[jb]

Post by Bernhard Voelker
...

Post by jb
$ 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
...
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)

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

Device Boot Start End Sectors Size Id
Type
Downloads/archlinux-2014.10.01-dual.iso1 * 0 1171455 1171456 572M 0
Empty
Downloads/archlinux-2014.10.01-dual.iso2 252 63739 63488 31M ef
EFI (FAT-12/16/32)

Post by Bernhard Voelker
...
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}.
...

Yes, indeed, I confused dd operation with its results as interpreted by
other tools (fdisk, etc) and presented to the user.

W/r to that interpretation, in a dos (MBR) partitioning scheme, the hard
disk can contain at most four primary partitions, or alternatively
three primary partitions and an extended partition.
The only way to have embedded (logical) partitions is thru dedication of
one primary partition to an extended partition mechanism.
What the fdisk shows here, at least start/end sectorwise, is that sdb2
partition is physically embedded in sdb1 partition.
So, how to interpret sdb1 and sdb2 partitions (primary, extended,
logical) ?
Is this a case of extended partition mechanism ?

jb

[Eric Blake]

Post by jb

Post by jb
# fdisk -l /dev/sdb
...
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)

...

W/r to that interpretation, in a dos (MBR) partitioning scheme, the hard
disk can contain at most four primary partitions, or alternatively
three primary partitions and an extended partition.
The only way to have embedded (logical) partitions is thru dedication of
one primary partition to an extended partition mechanism.
What the fdisk shows here, at least start/end sectorwise, is that sdb2
partition is physically embedded in sdb1 partition.

Yep. An unusual layout to be sure, but completely valid (as evidenced by
the fact that your kernel was able to mount both partitions).

Post by jb
So, how to interpret sdb1 and sdb2 partitions (primary, extended,
logical) ?

sdb1 is ALWAYS the first primary partition, and sdb2 is ALWAYS the
second primary partition. It is possible to have an MBR partition table
that specifies /dev/sdb2 while leaving /dev/sdb1 uninitialized, although
that is also unusual.

Post by jb
Is this a case of extended partition mechanism ?

No, it is a case of someone intentionally overlapping two primary
partitions. Weird, but nothing inherently wrong with it.