From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 86355E0079D for ; Thu, 28 Nov 2013 23:29:04 -0800 (PST) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail1.windriver.com (8.14.5/8.14.5) with ESMTP id rAT7T2F7018169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Nov 2013 23:29:02 -0800 (PST) Received: from [128.224.162.242] (128.224.162.242) by ALA-HCB.corp.ad.wrs.com (147.11.189.41) with Microsoft SMTP Server id 14.2.347.0; Thu, 28 Nov 2013 23:29:01 -0800 Message-ID: <5298421C.4090708@windriver.com> Date: Fri, 29 Nov 2013 15:28:28 +0800 From: Robert Yang User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Todd Stellanova References: <2925583.ItqHBfeJuJ@helios> <52973B8D.9010806@windriver.com> In-Reply-To: Cc: Paul Eggleton , "yocto@yoctoproject.org" Subject: Re: unbootable image produced with PACKAGE_CLASSES ?= "package_ipk", /etc missing X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 07:29:05 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 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 >>> 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 >>>>>> 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 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 >>>>>> 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 >>> >>> >