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 <rpj...@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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
