per-image ROOTFS sizes

per-image ROOTFS sizes

[Trevor Woerner]

Hi,

Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_<image>) still
supported? From this:

http://patches.openembedded.org/patch/4671/

it would appear not. However
poky-extras/meta-kernel-dev/conf/machine/example.conf contains
IMAGE_ROOTFS_SIZE_ext3 (which would make it appear as though they
are).

Best regards,
    Trevor

Re: per-image ROOTFS sizes

[Darren Hart]

On 12/11/2012 01:05 PM, Trevor Woerner wrote:
> Hi,
> 
> Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_<image>) still
> supported? From this:
> 
> http://patches.openembedded.org/patch/4671/
> 
> it would appear not. However
> poky-extras/meta-kernel-dev/conf/machine/example.conf contains
> IMAGE_ROOTFS_SIZE_ext3 (which would make it appear as though they
> are).
> 

Interesting, I haven't tried myself. Have you tried and run into an issue?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: per-image ROOTFS sizes

[Trevor Woerner]

Hi Darren,

On Wed, Dec 12, 2012 at 2:59 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> On 12/11/2012 01:05 PM, Trevor Woerner wrote:
>> Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_<image>) still
>> supported?
> Interesting, I haven't tried myself. Have you tried and run into an issue?


Yes. I had been trying to figure out why my:

    IMAGE_ROOTFS_SIZE_vmdk = "500000"

line in my config file wasn't working when I found the link I provided
earlier. Right now all I can say is that it doesn't work for _vmdk
specifically.

Re: per-image ROOTFS sizes

[Darren Hart]

On 12/12/2012 12:14 PM, Trevor Woerner wrote:
> Hi Darren,
> 
> On Wed, Dec 12, 2012 at 2:59 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>> On 12/11/2012 01:05 PM, Trevor Woerner wrote:
>>> Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_<image>) still
>>> supported?
>> Interesting, I haven't tried myself. Have you tried and run into an issue?
> 
> 
> Yes. I had been trying to figure out why my:
> 
>     IMAGE_ROOTFS_SIZE_vmdk = "500000"
> 
> line in my config file wasn't working when I found the link I provided
> earlier. Right now all I can say is that it doesn't work for _vmdk
> specifically.

That was:
http://patches.openembedded.org/patch/4671/

What is the reason you would like to do this just for vmdk? Is it to
avoid increasing the size of all the images when it is only vmdk you
care about? That would makes sense. Perhaps, for now, you could limit
the image types you build to just vmdk and increate the size without the
override?

Saul on CC for comment as that was his RFC Patch.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: per-image ROOTFS sizes

[Robert P. J. Day]

On Wed, 12 Dec 2012, Trevor Woerner wrote:

> Hi Darren,
>
> On Wed, Dec 12, 2012 at 2:59 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> > On 12/11/2012 01:05 PM, Trevor Woerner wrote:
> >> Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_<image>) still
> >> supported?
> > Interesting, I haven't tried myself. Have you tried and run into an issue?
>
>
> Yes. I had been trying to figure out why my:
>
>     IMAGE_ROOTFS_SIZE_vmdk = "500000"
>
> line in my config file wasn't working when I found the link I provided
> earlier. Right now all I can say is that it doesn't work for _vmdk
> specifically.

  since i was going to play with vmdk soon, i took a look at this and
from a position of extreme ignorance, i can see image-vmdk.bbclass
(which i'm going to assume is the class being used) which contains:

#inherit image-live
inherit boot-directdisk

create_vmdk_image () {
        qemu-img convert -O vmdk ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.vmdk
        ln -s ${IMAGE_NAME}.vmdk ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk

}

so my *guess* is that any sort of rootfs size calculation has to come
from boot-directdisk.bbclass, but if you look there, there's no
apparent reference to IMAGE_ROOTFS_SIZE.  what you see are numerous
references to BLOCKS and ROOTFSBLOCKS and BOOTDD_EXTRA_SPACE and so
on, with:

        ROOTFSBLOCKS=`du -Lbks ${ROOTFS} | cut -f 1`
        TOTALSIZE=`expr $BLOCKS + $ROOTFSBLOCKS`
        END1=`expr $BLOCKS \* 1024`
        END2=`expr $END1 + 512`
        END3=`expr \( $ROOTFSBLOCKS \* 1024 \) + $END1`

        echo $ROOTFSBLOCKS $TOTALSIZE $END1 $END2 $END3
        rm -rf $IMAGE
        dd if=/dev/zero of=$IMAGE bs=1024 seek=$TOTALSIZE count=1

        parted $IMAGE mklabel msdos
        parted $IMAGE mkpart primary fat16 0 ${END1}B
        parted $IMAGE unit B mkpart primary ext2 ${END2}B ${END3}B

so what happens if you try to set the appropriate variables above?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: per-image ROOTFS sizes

[Trevor Woerner]

On Wed, Dec 12, 2012 at 3:19 PM, Darren Hart <dvhart@linux.intel.com> wrote:
> What is the reason you would like to do this just for vmdk? Is it to
> avoid increasing the size of all the images when it is only vmdk you
> care about? That would makes sense.

Yes, that's it exactly. I have an existing build system in place
(which is all based on custom scripts) that I would like to upgrade to
Yocto. Our target device uses a 2GB CF card. My build system generates
an "image" which I use in conjunction with a script to create CF cards
based on any given build. There's no reason the "image" needs to be
2GB in size; the script formats and mounts the CF card, mounts the
"image", then copies the files from the image to the CF card. The
script also takes care of running LILO against the CF so it can boot.
The build system also generates a VDI (which is very much like a VMDK)
of the device which can be used for testing or development of
non-hardware-related features (e.g. web interface, snmp, etc). What I
like about the VDI is that it will start at, roughly, 200MB (which
makes it easier to copy around, download, etc) but when run will act
like the real 2GB system.

> Perhaps, for now, you could limit
> the image types you build to just vmdk and increate the size without the
> override?

Yes, that'll do for now. But I'd like to keep investigating so that
the ext3 image can be only as big as it needs to be while the
V{DI,MDK} can be dynamically sized to whatever is specified in
IMAGE_ROOTFS_SIZE_vmdk.

Re: per-image ROOTFS sizes

[Trevor Woerner]

On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> so what happens if you try to set the appropriate variables above?

When Yocto creates a VMDK, it creates 2 partitions:
- an MSDOS partition for the syslinux stuff
- the ext{3,4} partition of your root image

When it then shmushes these two together into 1 file, it has to make
sure all the sizes are set correctly as per the information in the
disk's partition table. That's what all these calculations are doing
(I recognize it from similar work in my own scripts).

Personally I have my own approach that can use either LILO or syslinux
for booting x86 (it can also create bootable ARM images with the
appropriate uboot/mlo); neither of the x86 solutions require a
separate MSDOS partition. Hopefully I'll find some time to examine how
Yocto is doing things and perhaps integrate my own findings into the
broader project(?).

(please see https://github.com/twoerner/qemu-image-builder)

I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
code in poky/meta/classes/image_types.bbclass, which is also run for
the VMDK's calculations too.

Re: per-image ROOTFS sizes

[Robert P. J. Day]

On Wed, 12 Dec 2012, Trevor Woerner wrote:

> On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > so what happens if you try to set the appropriate variables above?
>
> When Yocto creates a VMDK, it creates 2 partitions:
> - an MSDOS partition for the syslinux stuff
> - the ext{3,4} partition of your root image
>
> When it then shmushes these two together into 1 file, it has to make
> sure all the sizes are set correctly as per the information in the
> disk's partition table. That's what all these calculations are doing
> (I recognize it from similar work in my own scripts).
>
> Personally I have my own approach that can use either LILO or syslinux
> for booting x86 (it can also create bootable ARM images with the
> appropriate uboot/mlo); neither of the x86 solutions require a
> separate MSDOS partition. Hopefully I'll find some time to examine how
> Yocto is doing things and perhaps integrate my own findings into the
> broader project(?).
>
> (please see https://github.com/twoerner/qemu-image-builder)
>
> I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
> code in poky/meta/classes/image_types.bbclass, which is also run for
> the VMDK's calculations too.

  now i'm interested, so ... what are your config steps?  i wouldn't
mind trying to reproduce this on my system.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: per-image ROOTFS sizes

[Trevor Woerner]

Hi Robert,

(we met at OLS last summer, I came and chatted with you briefly after
your presentation)

On Wed, Dec 12, 2012 at 5:03 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>   now i'm interested, so ... what are your config steps?  i wouldn't
> mind trying to reproduce this on my system.


My doodle layer can be found here:
    https://github.com/twoerner/meta-trevor

My conf/bblayers.conf adds this and meta-openembedded/meta-oe.
My conf/local.conf currently looks like:

    BB_NUMBER_THREADS = "4"
    PARALLEL_MAKE = "-j 4"
    MACHINE = "qemux86"
    DL_DIR = "/home/trevor/devel/Downloads"
    DISTRO = "poky"
    PACKAGE_CLASSES = "package_ipk"
    EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh"
    USER_CLASSES = "buildstats image-mklibs image-prelink"
    PATCHRESOLVE = "noop"

    #
    # Disk Space Monitoring during the build
    #
    # Monitor the disk space during the build. If there is less that
1GB of space or less
    # than 100K inodes in any key build location (TMPDIR, DL_DIR,
SSTATE_DIR), gracefully
    # shutdown the build. If there is less that 100MB or 1K inodes,
perform a hard abort
    # of the build. The reason for this is that running completely out
of space can corrupt
    # files and damages the build in ways which may not be easily recoverable.
    BB_DISKMON_DIRS = "\
        STOPTASKS,${TMPDIR},1G,100K \
        STOPTASKS,${DL_DIR},1G,100K \
        STOPTASKS,${SSTATE_DIR},1G,100K \
        ABORT,${TMPDIR},100M,1K \
        ABORT,${DL_DIR},100M,1K \
        ABORT,${SSTATE_DIR},100M,1K"

    CONF_VERSION = "1"
    BB_DANGLINGAPPENDS_WARNONLY = "yes"
    IMAGE_FSTYPES = "vmdk"
    IMAGE_ROOTFS_SIZE = "500000"

You can then either "bitbake bboverride" or "bitbake core-image-minimal".

To easily boot the resulting VMDK with qemu, you'll have to patch your
poky/scripts/runqemu and poky/scripts/runqemu-internal with my patch
here (unless by the time you read this, it has already been included):
    https://lists.yoctoproject.org/pipermail/yocto/2012-December/013279.html

and then run:
    $ runqemu tmp/deploy/images/<image>.vmdk

Currently I can't think of any nice/easy way to _flexibly_ specify the
eth0 IP address of the vmdk image, but the runqemu script does setup
your local tap interface for 192.168.7.1/24 as expected. You can then
manually configure eth0 once the VM boots and/or setup
'/etc/network/interfaces'.

Re: per-image ROOTFS sizes

[Robert P. J. Day]

On Wed, 12 Dec 2012, Trevor Woerner wrote:

> On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > so what happens if you try to set the appropriate variables above?
>
> When Yocto creates a VMDK, it creates 2 partitions:
> - an MSDOS partition for the syslinux stuff
> - the ext{3,4} partition of your root image
>
> When it then shmushes these two together into 1 file, it has to make
> sure all the sizes are set correctly as per the information in the
> disk's partition table. That's what all these calculations are doing
> (I recognize it from similar work in my own scripts).
>
> Personally I have my own approach that can use either LILO or syslinux
> for booting x86 (it can also create bootable ARM images with the
> appropriate uboot/mlo); neither of the x86 solutions require a
> separate MSDOS partition. Hopefully I'll find some time to examine how
> Yocto is doing things and perhaps integrate my own findings into the
> broader project(?).
>
> (please see https://github.com/twoerner/qemu-image-builder)
>
> I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
> code in poky/meta/classes/image_types.bbclass, which is also run for
> the VMDK's calculations too.

  and here's where i'm confused.  i'm *assuming* that the
image-vmdk.bbclass file defines the creation of vmdk images, yes?  but
that class file inherits directly only boot-directdisk.bbclass, and if
i look in that class file, i don't see any further inherits that might
process IMAGE_ROOTFS_SIZE.  i just see hardcoded calculations that
build an image based on actual rootfs directory size.

  so what am i missing?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: per-image ROOTFS sizes

[Robert P. J. Day]

On Wed, 12 Dec 2012, Trevor Woerner wrote:

> Hi Robert,
>
> (we met at OLS last summer, I came and chatted with you briefly after
> your presentation)
>
> On Wed, Dec 12, 2012 at 5:03 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >   now i'm interested, so ... what are your config steps?  i wouldn't
> > mind trying to reproduce this on my system.
>
>
> My doodle layer can be found here:
>     https://github.com/twoerner/meta-trevor
>
> My conf/bblayers.conf adds this and meta-openembedded/meta-oe.
> My conf/local.conf currently looks like:
>
>     BB_NUMBER_THREADS = "4"
>     PARALLEL_MAKE = "-j 4"
>     MACHINE = "qemux86"
>     DL_DIR = "/home/trevor/devel/Downloads"
>     DISTRO = "poky"
>     PACKAGE_CLASSES = "package_ipk"
>     EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh"
>     USER_CLASSES = "buildstats image-mklibs image-prelink"
>     PATCHRESOLVE = "noop"
>
>     #
>     # Disk Space Monitoring during the build
>     #
>     # Monitor the disk space during the build. If there is less that
> 1GB of space or less
>     # than 100K inodes in any key build location (TMPDIR, DL_DIR,
> SSTATE_DIR), gracefully
>     # shutdown the build. If there is less that 100MB or 1K inodes,
> perform a hard abort
>     # of the build. The reason for this is that running completely out
> of space can corrupt
>     # files and damages the build in ways which may not be easily recoverable.
>     BB_DISKMON_DIRS = "\
>         STOPTASKS,${TMPDIR},1G,100K \
>         STOPTASKS,${DL_DIR},1G,100K \
>         STOPTASKS,${SSTATE_DIR},1G,100K \
>         ABORT,${TMPDIR},100M,1K \
>         ABORT,${DL_DIR},100M,1K \
>         ABORT,${SSTATE_DIR},100M,1K"
>
>     CONF_VERSION = "1"
>     BB_DANGLINGAPPENDS_WARNONLY = "yes"
>     IMAGE_FSTYPES = "vmdk"
>     IMAGE_ROOTFS_SIZE = "500000"
>
> You can then either "bitbake bboverride" or "bitbake core-image-minimal".
>
> To easily boot the resulting VMDK with qemu, you'll have to patch your
> poky/scripts/runqemu and poky/scripts/runqemu-internal with my patch
> here (unless by the time you read this, it has already been included):
>     https://lists.yoctoproject.org/pipermail/yocto/2012-December/013279.html
>
> and then run:
>     $ runqemu tmp/deploy/images/<image>.vmdk
>
> Currently I can't think of any nice/easy way to _flexibly_ specify the
> eth0 IP address of the vmdk image, but the runqemu script does setup
> your local tap interface for 192.168.7.1/24 as expected. You can then
> manually configure eth0 once the VM boots and/or setup
> '/etc/network/interfaces'.

  i'll check all this out, either this eve or tomorrow.  probably
tomorrow since i'm well into a bottle of 10-YO single malt ardbeg at
the moment.  you're jealous.  i know you are.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: per-image ROOTFS sizes

[Saul Wold]

On 12/12/2012 03:16 PM, Robert P. J. Day wrote:
> On Wed, 12 Dec 2012, Trevor Woerner wrote:
>
>> On Wed, Dec 12, 2012 at 3:46 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>>> so what happens if you try to set the appropriate variables above?
>>
>> When Yocto creates a VMDK, it creates 2 partitions:
>> - an MSDOS partition for the syslinux stuff
>> - the ext{3,4} partition of your root image
>>
>> When it then shmushes these two together into 1 file, it has to make
>> sure all the sizes are set correctly as per the information in the
>> disk's partition table. That's what all these calculations are doing
>> (I recognize it from similar work in my own scripts).
>>
>> Personally I have my own approach that can use either LILO or syslinux
>> for booting x86 (it can also create bootable ARM images with the
>> appropriate uboot/mlo); neither of the x86 solutions require a
>> separate MSDOS partition. Hopefully I'll find some time to examine how
>> Yocto is doing things and perhaps integrate my own findings into the
>> broader project(?).
>>
>> (please see https://github.com/twoerner/qemu-image-builder)
>>
>> I believe Yocto calculates the sizes (using IMAGE_ROOTFS_SIZE) from
>> code in poky/meta/classes/image_types.bbclass, which is also run for
>> the VMDK's calculations too.
>
>    and here's where i'm confused.  i'm *assuming* that the
> image-vmdk.bbclass file defines the creation of vmdk images, yes?  but
> that class file inherits directly only boot-directdisk.bbclass, and if
> i look in that class file, i don't see any further inherits that might
> process IMAGE_ROOTFS_SIZE.  i just see hardcoded calculations that
> build an image based on actual rootfs directory size.
>
>    so what am i missing?
>
Some serious magic!  It took me a while to reload my cache on this one.

All strapped in because here we go!

So you have selected the types of images you want to build by add it's 
type to IMAGE_FSTYPES, of which you can have multiple types.

When the do_rootfs() is run for an image, there is a call into 
image_types.bbclass via the ${@get_imagecmds(d)}, which returns a list 
of cmds to execute to create the various images selected via the above 
IMAGE_FSTYPES.  Of note here is that if vmdk or live is select, but not 
ext3 (soon to be ext4 we hope), then ext3 will be added to the types 
list, and vmdk and/or live will be removed.

in the get_imagecmds code, you can see that the OVERRIDES are updated 
locally to include the filesystem type, so that correct IMAGE_CMD can be 
selected via overrides and set into $cmd while the compressed version is 
set to $ccmd, then the runimagecmd is added to the cmds list (different 
than cmd, yes a little confusing).

runimagecmd is here the size computation occurs and the IMAGE_CMD is run 
via $cmd. Since we are not out side the get_imagecmds() context and do 
not have the localdata that set filesystem type overrides we won't seem 
them and beside runimagecmd will never get called for a vmdk or live 
image type! The underlying filesystem for those is the ext3 fs type.

Now that the rootfs has been created in the correct fs type (ext3) it 
mething to the TOTALSIZE and END3 computations in this code 
fragment:needs to be converted to vmdk, this is done via the 
image-vmdk.bbclass which is optionally inherited in image.bbclass.  This 
class slips the do_vmdkimg() function after do_bootdirectdisk, which is 
needed to get the right disk leve partitioning. The image-vmdk.bbclass 
inherits boot-directdisk.bbclass to get it incorporated correctly.  This 
is where Trevor correctly noted that that we are doing the multiple 
partition approach.

SO we cycle back to the initial question which is how to have 2 
different sizes for ext3 vanilla images vs a fixed size for the vmdk, 
right now that's really hard! Since we create an ext3 (4) for including 
mething to the TOTALSIZE and END3 computations in this code 
fragment:into the vmdk, that's where the sizing occurs.

What I think you are asking for is create a default sized ext3 and then 
allow the partition to be resized in the boot-directdisk partitioning 
code, since that's where the extra space would get accounted for.

Possibly we could add something to the TOTALSIZE and END3 computations 
in this code fragment:

         ROOTFSBLOCKS=`du -Lbks ${ROOTFS} | cut -f 1`
         TOTALSIZE=`expr $BLOCKS + $ROOTFSBLOCKS`
         END1=`expr $BLOCKS \* 1024`
         END2=`expr $END1 + 512`
         END3=`expr \( $ROOTFSBLOCKS \* 1024 \) + $END1`

That code feeds into the parted command, the dd that happens after that 
would have to change since we are dd'ing a ext3 and it does not know it 
has more space, this is the tricky part!  More thought is required, 
maybe a single malt (yes I was jealous).

Anyway, I hope have I not thoroughly confused everyone at this point.


Sau!



> rday
>

Re: per-image ROOTFS sizes

[Robert P. J. Day]

On Wed, 12 Dec 2012, Saul Wold wrote:

> Some serious magic!  It took me a while to reload my cache on this one.
>
> All strapped in because here we go!
>
> So you have selected the types of images you want to build by add
> it's type to IMAGE_FSTYPES, of which you can have multiple types.

  a minor nit but i used meta-yocto to configure for a beagle and used
bitbake-env to display the default value of IMAGE_FSTYPES:

$ bitbake-env IMAGE_FSTYPES
IMAGE_FSTYPES=" tar.bz2 jffs2"
$

so far, so good.  but then i simply *assigned* (not added) in
local.conf:

IMAGE_FSTYPES = "vmdk"

and checked again ... ???

$ bitbake-env IMAGE_FSTYPES
IMAGE_FSTYPES="vmdk tar.bz2 jffs2"
$

  um ... huh?  which is explained by the following inconsistent
collection of assignments in poky:

$ grep -r "IMAGE_FSTYPES.*=" *
meta/conf/bitbake.conf:IMAGE_FSTYPES ?= "tar.gz"
meta/conf/machine/include/ia32-base.inc:IMAGE_FSTYPES += "ext3 cpio.gz live"
meta/conf/machine/include/qemu.inc:IMAGE_FSTYPES += "tar.bz2 ext3"
meta/recipes-core/images/core-image-minimal-initramfs.bb:IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
meta/recipes-core/images/build-appliance-image.bb:IMAGE_FSTYPES = "vmdk"
meta-yocto/conf/distro/poky-tiny.conf:IMAGE_FSTYPES = "ext2 cpio.gz"
meta-yocto-bsp/conf/machine/beagleboard.conf:IMAGE_FSTYPES += "tar.bz2 jffs2"
meta-yocto-bsp/conf/machine/routerstationpro.conf:IMAGE_FSTYPES ?= "jffs2 tar.bz2"
meta-yocto-bsp/conf/machine/atom-pc.conf:IMAGE_FSTYPES ?= "ext3 cpio.gz live"
scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES ?= "jffs2 tar.bz2"
scripts/lib/bsp/substrate/target/arch/arm/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES += "tar.bz2 jffs2"
$

  that appears to be a very confusing mix of "=" and "?=" and "+=".
is that really the effect you were going for?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: per-image ROOTFS sizes

[Saul Wold]

On 12/13/2012 05:03 AM, Robert P. J. Day wrote:
> On Wed, 12 Dec 2012, Saul Wold wrote:
>
>> Some serious magic!  It took me a while to reload my cache on this one.
>>
>> All strapped in because here we go!
>>
>> So you have selected the types of images you want to build by add
>> it's type to IMAGE_FSTYPES, of which you can have multiple types.
>
>    a minor nit but i used meta-yocto to configure for a beagle and used
> bitbake-env to display the default value of IMAGE_FSTYPES:
>
> $ bitbake-env IMAGE_FSTYPES
> IMAGE_FSTYPES=" tar.bz2 jffs2"
> $
>
> so far, so good.  but then i simply *assigned* (not added) in
> local.conf:
>
> IMAGE_FSTYPES = "vmdk"
>
> and checked again ... ???
>
> $ bitbake-env IMAGE_FSTYPES
> IMAGE_FSTYPES="vmdk tar.bz2 jffs2"
> $
>
>    um ... huh?  which is explained by the following inconsistent
> collection of assignments in poky:
>
Good catch, I think some make sense and other should be fixed.

> $ grep -r "IMAGE_FSTYPES.*=" *
> meta/conf/bitbake.conf:IMAGE_FSTYPES ?= "tar.gz"
Base assignment for default, of course it should ?=

> meta/conf/machine/include/ia32-base.inc:IMAGE_FSTYPES += "ext3 cpio.gz live"
> meta/conf/machine/include/qemu.inc:IMAGE_FSTYPES += "tar.bz2 ext3"
These make sense as += it allows the DISTRO and/or user to add more types.

> meta/recipes-core/images/core-image-minimal-initramfs.bb:IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
initramfs will only need the cpio.gz there for set it directly

> meta/recipes-core/images/build-appliance-image.bb:IMAGE_FSTYPES = "vmdk"
build appliance only needs 1 fs types so set it directly.

> meta-yocto/conf/distro/poky-tiny.conf:IMAGE_FSTYPES = "ext2 cpio.gz"
again small custom image this is a DISTRO setting

> meta-yocto-bsp/conf/machine/beagleboard.conf:IMAGE_FSTYPES += "tar.bz2 jffs2"
As the qemu and ia32 add correct fs types for beagleboard.

> meta-yocto-bsp/conf/machine/routerstationpro.conf:IMAGE_FSTYPES ?= "jffs2 tar.bz2"
> meta-yocto-bsp/conf/machine/atom-pc.conf:IMAGE_FSTYPES ?= "ext3 cpio.gz live"
I would think that += would be better here, I would welcome a patch!

> scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES ?= "jffs2 tar.bz2"
Looks like these followed the pattern of the base machine, but I think 
this should be +=, a patch would be welcome!


Sau!

> scripts/lib/bsp/substrate/target/arch/arm/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES += "tar.bz2 jffs2"

> $
>
>    that appears to be a very confusing mix of "=" and "?=" and "+=".
> is that really the effect you were going for?
>

> rday
>

Re: per-image ROOTFS sizes

[Robert P. J. Day]

On Thu, 13 Dec 2012, Saul Wold wrote:

> > meta-yocto-bsp/conf/machine/routerstationpro.conf:IMAGE_FSTYPES ?= "jffs2
> > tar.bz2"
> > meta-yocto-bsp/conf/machine/atom-pc.conf:IMAGE_FSTYPES ?= "ext3 cpio.gz
> > live"

> I would think that += would be better here, I would welcome a patch!
>
> > scripts/lib/bsp/substrate/target/arch/mips/conf/machine/{{=machine}}.conf:IMAGE_FSTYPES
> > ?= "jffs2 tar.bz2"

> Looks like these followed the pattern of the base machine, but I think this
> should be +=, a patch would be welcome!

  ok, so those are the only cases that warrant tidying up?  unless
there's an objection, i'll submit two patches, one for each of the
above.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================