[OE-core] [RFC PATCH 1/1] self-hosted-image: generate the .hdddirect and .vmdk image files

[Cui, Dexuan]

Darren Hart wrote on 2012-01-13:
> Hi Dexuan,
> 
> Please include a complete patch header. Much of your 0/1 content can
> go here.
(Sorry for the late reply! I overlooked the mails...)
Ok, I'll pay attention to this in future.

> Comments below...
> 
> On 01/10/2012 10:53 AM, Dexuan Cui wrote:
>> Signed-off-by: Dexuan Cui <dexuan.cui at intel.com>
>> ---
>>  meta/classes/boot-directdisk.bbclass          |   10 +++++++++-
>>  meta/recipes-core/images/self-hosted-image.bb |   11 +++++++++--
>>  2 files changed, 18 insertions(+), 3 deletions(-)
>> diff --git a/meta/classes/boot-directdisk.bbclass
>> b/meta/classes/boot-directdisk.bbclass index 8879ba8..83ec929 100644
>> --- a/meta/classes/boot-directdisk.bbclass +++
>> b/meta/classes/boot-directdisk.bbclass @@ -24,6 +24,7 @@
>> do_bootdirectdisk[depends] += "dosfstools-native:do_populate_sysroot \
>> 
>> syslinux-native:do_populate_sysroot \
>> 
>> parted-native:do_populate_sysroot \
>> 
>> mtools-native:do_populate_sysroot " +do_bootdirectdisk[depends] +=
>> "qemu-native:do_populate_sysroot"
>> 
>>  PACKAGES = " "
>>  EXCLUDE_FROM_WORLD = "1"
>> @@ -38,7 +39,7 @@ BOOTDD_EXTRA_SPACE ?= "16384"
>> 
>>  AUTO_SYSLINUXCFG = "1"
>>  LABELS = "boot"
>> -APPEND = "root=/dev/sda2"
>> +APPEND = "root=/dev/hda2"
> 
> This seems like it had the potential to break other uses of hdddirect.
> Qemu may use hda2, but other hdddirect users (external layers for
Hi Darren, thanks for pointing this out!
I thought it's ok since now I'm the only user ofhdddirect, but I didn't realize I might break external layers...

> example) may not. This feels like a MACHINE config to me. In fact,
> machine's do already set APPEND for things like the console.
I agree.
So, I think here we should change the = to ?= like the below
-APPEND = "root=/dev/sda2"
+APPEND ?= "root=/dev/sda2"
And in meta/conf/machine/include/qemu.inc, I can add a line
APPEND = "root=/dev/hda2".

Does this sound ok?

> 
>>  TIMEOUT = "10"
>>  SYSLINUXCFG  = "${HDDDIR}/syslinux.cfg"
>>  SYSLINUXMENU = "${HDDDIR}/menu"
>> @@ -50,6 +51,7 @@ build_boot_dd() {
>> 
>>  	install -d ${HDDDIR}
>>  	install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage
> ${HDDDIR}/vmlinuz
>> +	install -m 0644 ${S}/syslinux.cfg ${HDDDIR}/syslinux.cfg
> 
> Hrm... syslinux.cfg wasn't installed before at all?
I'm not very clear about the history, but according to syslinux.bbclass,
iso and hddimg do invoke syslinux_populate, but hdddirect doesn't -- I suppose hdddirect doesn't need all the functionality of build_syslinux_menu, so it tries to install the files itself, and unluckily it misses syslinux.cfg. Now there is no user of .hdddirect in poky, and I don't know there is any actual external user. This may explain why nobody complains. :-)


> 
>>  	install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys
>> ${HDDDIR}/ldlinux.sys
>> 
>>  	BLOCKS=`du -bks ${HDDDIR} | cut -f 1` @@ -83,6 +85,12 @@
>>  build_boot_dd() { 	cd ${DEPLOY_DIR_IMAGE} 	rm -f
>>  ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect 	ln -s
>>  ${IMAGE_NAME}.hdddirect
>> ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
>> +
>> +	if [ "${NOVMDK}" != "1" ] ; then
>> +		${STAGING_BINDIR_NATIVE}/qemu-img convert -O vmdk   \
> 
> You've added a dependency on qemu-img, please add the appropriate
> DEPENDS above.
I have added the line in my patch:
do_bootdirectdisk[depends] += "qemu-native:do_populate_sysroot"

I think this is enough?
Need I add "DEPENDS += "qemu-native", too?

> 
>> +			${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect \
>> +			${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk
>> +	fi
>>  }
>>  
>>  python do_bootdirectdisk() {

> Darren Hart wrote on 2012-01-13:
> On 01/10/2012 10:53 AM, Dexuan Cui wrote:
> 
> A couple additional thoughts about the boot-directdisk class in general:
> 
> So build_boot_dd needs a careful audit to ensure the various dd
> commands do not stomp on eachother iirc, the dd of syslinux/mbr.bin
> was stomping on the partition table or some such.
Hi Darren,
The dd-ing of mbr.bin actually writes only the first 440 bytes of $IMAGE -- please note
the size of mbr.bin(generated by the recipe syslinux, I think) is 440 bytes rather than 512 bytes. :-)
I think 440 is safe enough because it's even smaller than 512-16*4=448 bytes.

> Also note that it uses "mkdosfs -d" which we have purged (and it aint
> coming back if my NACK is worth anything ;-). Sounds like we need to
> abstract building msdos images into an msdosfs.bbclass. No reason to
Would you volunteer to make a msdosfs.bbclass? :-)

> duplicate all the fatfs overhead calculations I did yesterday (See the
> patch I sent yesterday to bootimg.bbclass).
I agree.
I see your patch has been in poky master now.
If you could help to make msdosfs.bbclass, I would appreciate that a lot.
Now I'm stick in something else and I'm afraid I can't start to work on this immediately. :-(

Thanks,
-- Dexuan