Re: unbootable image produced with PACKAGE_CLASSES ?= "package_ipk", /etc missing

[Robert Yang <liezhi.yang@windriver.com>]

Hi Todd,

I can reproduce the similar problem now, I think that it should be a
bug of e2fsprogs, it seems the debugfs can't know the free space
correctly, and thus it appears no free blocks, I'm sorry to say that
I can't fix it in a short while, but I will fix it in one or two weeks,
maybe you can set this in the local.conf as a workaround:

IMAGE_ROOTFS_EXTRA_SPACE = "51200"

If 51200 is not enough, it can be higher, the unit is Kbytes.


And the todd-new-wandboard-dual.tar.bz2 works well is because it doesn't
generated by debugfs.

// Robert

On 11/29/2013 12:02 AM, Todd Stellanova wrote:
> Thanks for taking a look at this Robert!
> Below is the ls output: fsck output and bb are attached.
>
> I should note that if I manually copy the bz2 output of bitbake to an
> sdcard, like:
> sudo tar xjvf
> tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual.tar.bz2 -C
> /media/rootfs
> the image boots fine and contains all the packages I expect.
>
> todd@ubuntu:~/proj/wandboard/fsl-community-bsp/build$ ls -stlh
> tmp/deploy/images/wandboard-dual/*.ext3
> 572M -rw-r--r-- 1 todd todd 572M Nov 27 17:05
> tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131128005017.rootfs.ext3
>     0 lrwxrwxrwx 1 todd todd   50 Nov 27 17:05
> tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual.ext3 ->
> todd-new-wandboard-dual-20131128005017.rootfs.ext3
> 435M -rw-r--r-- 1 todd todd 436M Nov 26 16:17
> tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131127001137.rootfs.ext3
> 435M -rw-r--r-- 1 todd todd 436M Nov 26 15:55
> tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131126234958.rootfs.ext3
> 435M -rw-r--r-- 1 todd todd 436M Nov 26 15:36
> tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131126232014.rootfs.ext3
> 435M -rw-r--r-- 1 todd todd 436M Nov 26 14:03
> tmp/deploy/images/wandboard-dual/todd-new-wandboard-dual-20131126161048.rootfs.ext3
>
>
>
>
> On Thu, Nov 28, 2013 at 4:48 AM, Robert Yang <liezhi.yang@windriver.com>wrote:
>
>>
>> Hi Todd,
>>
>> I can't reproduce the problem, the rpm has more space than ipk is because
>> of the IMAGE_ROOTFS_EXTRA_SPACE, which is 50M * 1.3 by default.
>>
>> Would you please try the following commands:
>>
>> 1) $ ls -stlh tmp/deploy/images/wandboard-dual/core-image-minimal-dev-
>> wandboard-dual-*.ext3
>>
>> 2) $ fsck.ext4 -fn /path/to/image.ext3
>>
>> And can you show the bb file if possible ?
>>
>> // Robert
>>
>>
>> On 11/27/2013 09:27 AM, Todd Stellanova wrote:
>>
>>> Tried creating a fresh build folder and giving the vm more ram but the
>>> results are basically the same:
>>>
>>> Allocated inode: 15264
>>> copy_file: Could not allocate block in ext2 filesystem
>>> debugfs: sif "libgio-2.0.so.0.3800.1" mode 0x81ed
>>>
>>> It appears that using package_rpm successfully allocates something like
>>> 15968 inodes. When calculating the ROOTFS_SIZE it looks like package_rpm
>>> and package_ipk are using very different values:
>>>
>>> package_rpm:
>>>
>>> ++ du -ks
>>> /fsl-community-bsp/build/tmp/work/wandboard_dual-poky-
>>> linux-gnueabi/todd-new/1.0-r0/rootfs
>>> ++ awk '{base_size = $1 * 1.3; base_size = ((base_size > 8192 ? base_size
>>> :
>>> 8192) + 0 + *51200*); if (base_size != int(base_size)) base_size =
>>>
>>> int(base_size + 1); base_size = base_size + 4096 - 1; base_size -=
>>> base_size % 4096; print base_size }'
>>>
>>> + ROOTFS_SIZE=*458752*
>>>
>>>
>>> package_ipk:
>>>
>>> ++ du -ks
>>> /fsl-community-bsp/build/tmp/work/wandboard_dual-poky-
>>> linux-gnueabi/todd-new/1.0-r0/rootfs
>>> ++ awk '{base_size = $1 * 1.3; base_size = ((base_size > 8192 ? base_size
>>> :
>>> 8192) + 0); if (base_size != int(base_size)) base_size = int(base_size +
>>> 1); base_size = base_size + 4096 - 1; base_size -= base_size % 4096; print
>>> base_size }'
>>>
>>> + ROOTFS_SIZE=*376832*
>>>
>>>
>>> I'm just guessing here, but it seems like package_ipk is underestimating
>>> ROOTFS_SIZE and subsequently populate-extfs.sh fails trying to add files
>>> to
>>> the ext fs.  Any ideas what might cause this?
>>>
>>> Thanks for any help!
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Nov 25, 2013 at 7:03 AM, Todd Stellanova <tstellanova@gmail.com
>>>> wrote:
>>>
>>>   Thanks for the ideas. I'll try creating a new build folder. If that still
>>>> shows the problem, I'm thinking this has something to do with the fact
>>>> that
>>>> I'm running the build inside a vm (inside an Ubuntu vm running on a Mac).
>>>> It looks like the build is using debugfs...maybe it's running out of ram
>>>> at
>>>> some point and not obtaining more in the vm properly?
>>>>
>>>>   On Nov 25, 2013, at 5:21 AM, Paul Eggleton <
>>>>>
>>>> paul.eggleton@linux.intel.com> wrote:
>>>>
>>>>>
>>>>> Hi Nicolas / Todd,
>>>>>
>>>>>   On Monday 25 November 2013 11:31:42 Nicolas Dechesne wrote:
>>>>>> On Sun, Nov 24, 2013 at 3:51 AM, Todd Stellanova
>>>>>> <tstellanova@gmail.com>wrote:
>>>>>>
>>>>>>> It appears that copying the files to the ext3 / sdcard image is
>>>>>>>
>>>>>> failing in
>>>>
>>>>> *populate-extfs.sh*
>>>>>>> I see a series of these errors:
>>>>>>>
>>>>>>> *copy_file: Could not allocate block in ext2 filesystem*
>>>>>>>
>>>>>>> Any idea what might cause this?  I've verified that the initial .tar
>>>>>>> archive and the bz2 contain the right files.
>>>>>>>
>>>>>>
>>>>>> can you try to create a new <build> folder (do not remove the current
>>>>>>
>>>>> one
>>>>
>>>>> for now) and reuse the downloads and sstate folder? i am wondering if
>>>>>>
>>>>> there
>>>>
>>>>> is a bug when trying to change PACKAGE_CLASSES in an existing <build>
>>>>>> folder.
>>>>>>
>>>>>
>>>>> I do this not infrequently and never hit a problem like this, so I doubt
>>>>>
>>>> this
>>>>
>>>>> is the case.
>>>>>
>>>>> Either there is a problem in how the filesystem is being set up (block
>>>>>
>>>> sizes,
>>>>
>>>>> etc.) or there is some kind of corruption occurring.
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>> --
>>>>>
>>>>> Paul Eggleton
>>>>> Intel Open Source Technology Centre
>>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>