[arch-releng] Note about removing archiso_early hook.

Gerardo Exequiel Pozzi vmlinuz386 at yahoo.com.ar
Fri Mar 5 15:25:36 EST 2010


On 03/05/2010 04:44 PM, Sven-Hendrik Haase wrote:
> 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.
>    
Thanks for the feedback :)
> 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?
>    
Because without this patch, "by-label" is not used at all. Just 
/dev/archiso is used that points to /dev/sdb in your case.
> 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).
>    
Yes, offset does not change in how symlink is created.

The magic rule is (this make all sdbN, inherits parent ID_* data from sdb.
ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"

and rule that create symlink is:
ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_LABEL_ENC}=="?*", 
SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}"

and this is the rule that export ID_*
KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"

> This time however it reported both partitions correctly in blkid.
>    
Yes, this is because as I explained before sdb points to sector 0, and 
sdb1 also points to sector 0, so only and only in this case, is a valid 
filesystem.
> 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.
>    
Set an e2fslabel on your ext2 partition and see how another by-label/ 
entry is created that points to correct partition.
> 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.
>    
60-persistent-storage.rules is ""untoucheable"", rules are OK.

There is a dirty hack, that I didn't commented before, this is how udev 
uevents are triggered. The dirty hack is just before looking at 
"by-label" trigger udev events for disks, this is done with udevadm 
trigger --property-match=DEVTYPE=disk
In this way only disk are retriggered, not partitions, so again 
by-label/xyz will point to sdb and not sdb1 or sdb2 ;)

> At its current state, it appears we cannot rely on it to create correct
> LABELs for us using isohybrid.
>    
I guess this is not possible, since the partition created is not a real 
partition (is just a fake, to avoid overwriting the data), so can not 
contain a boot sector with a LABEL. I guess that at that offset 
(512-1023) there are important data that can not be overwrited like 
bettween 0-512 at some portions.


Good Luck!

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




More information about the arch-releng mailing list