[arch-releng] Help with hybrid ISOs and making extra partitions

Gerardo Exequiel Pozzi vmlinuz386 at yahoo.com.ar
Mon Mar 22 23:32:39 CET 2010

On 03/22/2010 03:38 PM, Jim Pryor wrote:
> Success.
> Here's what I did:
> **********************************************************
>      * in archiso2dual, change
>              isohybrid -offset 1 "${imagename}"
>      to:
>              isohybrid "${imagename}"
> **********************************************************
Oops!, I missed to change archiso2dual, mkarchiso is already fixed 
(single arch images)

Thanks, changed and commited to my pxe_nbd branch (will be merged soon 
to master) to avoid conflicts.
>      * mastered my own i686 and x86_64 ISOs, combined them into dual ISO
>      with:
>              sudo archiso2dual -T full -3 myarch-2010.03.22-i686.iso -6 \
>              myarch-2010.03.22-x86_64.iso -o myarch-2010.03.22-dual.iso  -y
>      * wrote to my USB key (/dev/sdc) using:
>              sudo dd if=iso-mine/myarch-2010.03.22-dual.iso of=/dev/sdc bs=8M
>      * created a second partition, starting with
>              sudo fdisk /dev/sdc
>              ...
> fdisk turns out to be not very hard, especially if one has used cfdisk. Googling
> "fdisk howto" may help.
>      * create filesystem on second partition, with a label:
>              sudo mkdosfs -F32 -nmylabel /dev/sdc2
> At this point, both /dev/sdc1 and /dev/sdc2 are mountable. Plus I can
> boot from the USB key and login successfully. (When testing, don't just
> check for bootability, see whether you can get all the way to a login
> prompt.) I can also mount /dev/sdc2 when I've booted from /dev/sdc1.
> So it looks like everything is now working properly...
OK, right.
> Still, I wouldn't mind getting some more clarification about the
> offset=1 vs offset=0, and the limits/snags of using hybrid ISOs. I get
> the impression these are still something of a moving target.

1) isohybrid write a MBR to first 512 of the .iso (LBA 0)
2) Inside this MBR there is one partition (is fake*) defined that is 
type 0x17 (hidden NTFS) that points to LBA 0 (with offset 0) so points 
to MBR (this is why called recursive), if offset 1 will point to LBA 1.
3) If you try to mount the partition with offset 1, you receive an 
error, because there is no filesystem starting at that point. The only 
real filesystem is at LBA 0 (UDF).

* is fake, because under this partition there is no real filesystem.


This is the "boot archiso" step (the key of the issue is at udev rule 

supose sda is the USB key.

* offset 0 scenario:
1) udev process sda -> blkid is execute and get some attributes, in 
these attr there is a LABEL, and set in udev database.
1a) /dev/disk/by-label/ARCH_201003 -> /dev/sda
2) udev process sda1 -> blkid is execute and.... (same above)
2a) /dev/disk/by-label/ARCH_201003 -> /dev/sda1

right, there is no problem here, because sda1 points to UDF filesystem

* offset 1 scenario:
1) udev process sda -> blkid is execute and get some attributes, in 
these attr there is a LABEL, and set in udev database.
1a) /dev/disk/by-label/ARCH_201003 -> /dev/sda
2) udev procces sda1 -> blkid is execute but FAILS, attributes are 
ihnerited from parent device (sda).
2a) /dev/disk/by-label/ARCH_201003 -> /dev/sda1

bad, there is no filesystem at sda1

so, why label for all filesystem? because the last unlabeled filesystem 
will point to parent device (the attributed is inherited from parent device)

is more clear now?

More info about udev rules here:

Gerardo Exequiel Pozzi ( djgera )
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C 330D

More information about the arch-releng mailing list