[arch-releng] Note about removing archiso_early hook.

Sven-Hendrik Haase sh at lutzhaase.com
Fri Mar 5 14:44:22 EST 2010

On 03.03.2010 18:12, Sven-Hendrik Haase wrote:
> On 03.03.2010 02:08, Gerardo Exequiel Pozzi wrote:
>> Hi, just to leave in some visible place this experiment if some is
>> interested.
>> My idea: remove archiso_early hook, and take the advantage of symlink
>> /dev/disk/by-label/XYZ created by 60-persistent-storage.rules
>> installed via udev hook, without doing other tricks.
>> Result:
>> * OK: when booting in cdrom mode.
>> * FAIL: when booting in disk mode.
>> The reason is because hybrid mode (via isohybrid).
>> * The LABEL is defined at first sector of iso "sda" (simulate a MBR)
>> also there is a fake partition "sda1" (with offset 1 [+512 bytes ahead
>> of sda]) so you can create another partitions on the destination media.
>> * When mount the UDF filesystem, sda is mounted and not sda1 (sda1 is
>> just a fake part to avoid overwriting data).
>> * There is a udev rule at 60-persistent-storage.rules that make all
>> parent (sda in this case) ID_* env data available to childrens (sda1
>> in this case), so sda1 inherits the LABEL, and this data is not
>> overwrited because blkid fail (remember sda1 is not a real partition)
>> Consequence:
>> * /dev/disk/by-label/XYZ points to /dev/sda1 instead of /dev/sda.
>> (when isohybrid offset > 0)
>> What works:
>> * if offset = 0 will works, but doing this we lost the capability of
>> create another partitions in the medium that .iso is copied (USB media)
>> * Also works on real partition scheme (usb drive with the real MBR,
>> and real partiton with label)
>> * As said before if boot as cdrom.
>> Conclusion:
>> * Keep with archiso_early, that is pretty simple and does not require
>> other tools [#1]
>> If some is interested in changes for your personal usage, the patch is
>> here [#2]
>> [#1] http://bugs.archlinux.org/task/18523 [mkinitcpio] usb_id, ata_id,
>> scsi_id, path_id: should be added to udev install hook?
>> [#2] https://gist.github.com/1f6f5a67008bf3b927ee
> The problem with the recursive stuff might actually be in parted while
> other tools may be able to modify the resulting partition. Follow the
> syslinux mailing list for more infos on this. I'm currently trying to
> get some help as to how I would be able to add more partitions with
> offset = 0.
> -- Sven-Hendrik
I just did some empiric tests here with surprising results.

Using offset 1 and off-the-shelf archiso-git official master, I dd'd my
netinstall medium (x86_64) onto my USB key (sdb) and used gparted to
make a second partition (sdb2) at the end of type ext2. I was able to
mount it, put some crap onto it and rebooted into my live system. I did
not expect this to work, however it booted just fine. In the live
system, I was able to mount -o loop sdb2 fine and found my crap on there.
I looked up what /dev/disk/by-label/ looked like and to my surprise
found that ARCH_201003 pointed to sdb2! How did it even boot?

Astonished by this work of magic I moved on to retry the same test using
offset 0. I repeated the same procedure and found myself in a happily
booted Arch live system that still pointed its
/dev/disk/by-label/ARCH_201003 at /dev/sdb2 (still the extra ext2 part).
This time however it reported both partitions correctly in blkid.
Earlier it only showed the ext2 partition while the udf one it was
booted from was hidden. This time I got the udf one as well.

Anyhow, turns out you *are*able to create partitions on the offset 0
device just fine using fdisk and mkfs friends. H. Peter Anvin, the
syslinux guy, also advises to not rely on parted for more exotic layouts
(which a recursive partition certainly is). I therefore conclude my
tests and suggest trying to move forward on the course to remove
archiso_early. This could be done by improving the
60-persistent-storage.rules hook to make it find the stuff we need it to
find more properly.

At its current state, it appears we cannot rely on it to create correct
LABELs for us using isohybrid.

-- Sven-Hendrik

More information about the arch-releng mailing list