[yocto] image-vmdk with genericx86

[Takashi Matsuzawa]

Hello.

Though the build successfully completes, but the image does not boot and I believe parameters are not set properly for my image.

What I am trying to do is to build xxx.hdddirect image instead of xxx.hddimg for genericx86(, on fido).

As I inspect with '-e' option, I believe, at least the following is wrong.

> # $SYSLINUX_ROOT [3 operations]
> #   set /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/classes/image-live.bbclass:5
> #     "root=/dev/ram0"
> #   set? /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/classes/image-vmdk.bbclass:4
> #     "root=/dev/sda2"
> #   set? /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/> poky/meta/classes/boot-directdisk.bbclass:63
> #     "root=/dev/sda2"
> # pre-expansion value:
> #   "root=/dev/ram0"
> SYSLINUX_ROOT="root=/dev/ram0"

I think SYSLINUX_ROOT here is set by image-live.bbclass's value, not by boot-directdisk.bbclass's.

I feel this is strange that in my local.conf, I have explicitly removed 'live' from IMAGE_FSTYPES and added 'vmdk'.

But, in the above, image-live.bbclass seems to be interpreted and affecting the variable expansion.

I think, the following line in image.bbclass is deciding if it reads image-live.bbclass or not.

>IMAGE_TYPE_live = "${@build_live(d)}"
>
>inherit ${IMAGE_TYPE_live}

Since IMAGE_TYPE_live is set to '' as follows, I believe image-live.bbclass should never interpreted?

> # $IMAGE_TYPE_live
> #   set /mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/classes/image.bbclass:129
> #     "${@build_live(d)}"
> IMAGE_TYPE_live=""

I tried BBMASK'ing image-live.bbclass, but it still seems to be read.

So, I am a bit of stuck here.


________________________________
From: Takashi Matsuzawa
Sent: Thursday, July 14, 2016 10:06 PM
To: Maxin B. John
Cc: yocto at yoctoproject.org
Subject: Re: [yocto] image-vmdk with genericx86


Hello

>IMAGE_FSTYPES += "vmdk"

Thank you it worked.
(I should remember  '_append'  applied after all '=' assignments are done.)

After .hdddirect image is successfully created, I am still working on the following.

i) image does not boot, maybe its boot device path thing...
ii) hddimage, iso images are also generated.  I may want to disable generation of these (and leave images types that I need only), so that bitbake completes much earlier.
iii) same can be sade to do_populatesdk it seems to run default.

________________________________
From: Maxin B. John <maxin.john at intel.com>
Sent: Thursday, July 14, 2016 12:16 AM
To: Takashi Matsuzawa
Cc: yocto at yoctoproject.org
Subject: Re: [yocto] image-vmdk with genericx86

Hi Takashi-san,

On Wed, Jul 13, 2016 at 10:51:34AM +0000, Takashi Matsuzawa wrote:
>Hello, Yocto.
>
>Should it be possible to simply change image class of genericx86 from xxxx.hddimg to xxxx.hdddirect?
>
>I have been successfully building genericx86 image (that is image-live.bbclass based), and now trying to build it with directdisk (xxxx.hdddirect).
>
>I thought it would be simpler to use pre-existing imageclass, so I tried following after finding image-vmdk.bbclass inherits boot-directdisk.
>
>Currently my build is based on Yocto 1.8 (fido).
>
>
>(in my local.conf)
>
>IMAGE_FSTYPES_remove = " live"
>IMAGE_FSTYPES_append = " vmdk"

Instead of the above two, could you use the following line in local.conf and build again ?

IMAGE_FSTYPES += "vmdk"

>But this caused following error.
>
>I am currently looking into the class files to find the cause of error, but anyway, this should work?
>
>
>>ERROR: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'vmdk' - possibly invalid type name or missing support class
>> ERROR: Function failed: do_rootfs
>> ERROR: Logfile of failure stored in:
>>/mnt/ssd2/yocto/dev/tmp/x86-wk3/work/genericx86-poky-linux/core-image-minimal-initramfs/1.0-r0/temp/log.do_rootfs.20432
>> ERROR: Task 229
>>(/mnt/ssd2/yocto/dev/wk/x86/wk3/build-root/sources/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb, do_rootfs) failed with exit code '1'


Best Regards,
Maxin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160715/a06640b6/attachment.html>