[OE-core] [PATCH 0/6] Setup for VMDK to use Direct Disk

Cui, Dexuan dexuan.cui at intel.com
Sun Apr 1 10:28:35 UTC 2012


Cui, Dexuan wrote on 2012-03-31:
> Cui, Dexuan wrote on 2012-03-31:
>> Paul Eggleton wrote on 2012-03-30:
>>> On Monday 26 March 2012 22:42:54 Saul Wold wrote:
>>>> Updated comments per Darren's request, added cleanup to image-types
>>>> to only use one -i (inode-count) parameter.
>>>> 
>>>> Sau! The following changes since commit
>>>> 644b7503c37fd73730dd3d7841463b158b8934ed:
>>>> 
>>>>   guile: Deal with hardcoded path issues (2012-03-27 00:28:41 +0100)
>>>>   are available in the git repository at:
>>>>   git://git.openembedded.org/openembedded-core-contrib sgw/self
>>>> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log
>>>> /
>>>> ?h
>>>> =sgw/
>>>> self
>>> 
>>> So these patches have been merged now; I updated to latest master
>>> and re-ran bitbake self-hosted-image; unfortunately the output
>>> doesn't appear to be usable. I don't know what has gone wrong but
>>> during boot there are complaints that the filesystem is corrupt:
>>> 
>>> SYSLINUX 4.03 2010-10-22 EDD Copyright (C) 1994-2010 H. Peter Anvin et
>>> al EXT3-fs error (device hda2): ext3_lookup: deleted inode referenced:
>>> 581713 EXT3-fs error (device hda2): ext3_lookup: deleted inode
>>> referenced: 610383 Kernel panic - not syncing: no init found.  Try
>>> passing init= option to kernel.
>>> 
>>> Running e2fsck -fn on the rootfs.ext3 file shows quite a number of errors.
>>> There were no unusual errors in the log.do_rootfs.
>>> 
>> Hi Paul,
>> I can reproduce the same I issue, too...
>> I'll try to look into this, but at the first glance, I don't know what
>> has gone wrong, either...
> Can we make a conclusion the current genext2fs is buggy here
> when creating a big image(e.g., >4GB)?
Hi Paul, I believe this is true:
genext2fs-1.4.1 can create a corrupt file system when
the size of the file system exceeds some limit.

e.g., when I create an image of 2.8GB, the image can be mounted
properly, but when I create an image of about 4.5GB(yes, I found
genext2fs-1.4.1 is actually able to create an image of 4.5GB; I also
found it's unable to create an image of about 5.5GB, always
reporting "couldn't allocate a block (no free space)"),
the generated image can show something like this when it's
booted:

EXT3-fs error (device hda2): ext3_lookup: deleted inode referenced...

However, with Corey's patches (from the genext2fs's mailing list)
applied, I can't see the issues.

You can try the patch too to see if this would also works for you:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/master&id=c76f9db84c2eabe0bf704b253a957f695f421936 

Thanks,
-- Dexuan






More information about the Openembedded-core mailing list