Re: [yocto] unbootable image produced with PACKAGE_CLASSES ?= "package_ipk", /etc missing
Robert, since I think you implemented this, any idea what might be going wrong
here?
Cheers,
Paul
On Tuesday 26 November 2013 17:27:30 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.eggle...@linux.intel.com> wrote:
> > > 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
> > > > onefor 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.
> > >
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Weekly Build Available
The weekly build is about the be available at: http://autobuilder.yoctoproject.org/pub/nightly/20131127-1 Please begin scheduled testing. bitbake 347b2ead091f00ee60703f6f3d17cfdd9075ac07 eclipse-poky-juno e8342d27db60a9d1b627ddb9f8ae2f5512bfc0c9 eclipse-poky-kepler 3dd620d9f89e297ee9e22d5ba9fe741a5f40ac82 meta-fsl-arm 987115d6d099a5e87d9d5b3c4e6567a5e6309fd0 meta-fsl-ppc 768c6ef13546e0f977847bc1fbb5957571fbf724 meta-intel a649e92498d234f2d0d52f3da5a85bdc87296c23 meta-minnow 91cff9475081a5625c1c0bb49c17c6f3130ec503 meta-qt3 b73552fb998fd30a01dbee5a172e432a16078222 oecore f991d2d60b74f5ebd990f77aecd3324b1a4533e9 poky 32adaac34a614d106e6dd3e9f1130f4e94ff39ae -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge (use -f to force)
Hi Paul, good to hear I'm not the only one suffering from this issue... No, I've received no response on the mailing list yet, but maybe someone has a hint for us now? The only "workaround" I found is to purge the package and afterwards install the new version. I know this is a really dirty workaround, but it's the only "solution" I found. Have you discovered any other workarounds, Paul? regards Richard >-Original Message- >From: Stath, Paul [mailto:pst...@axxcelera.com] >Sent: Wednesday, November 27, 2013 4:49 PM >To: Richard Leitner - SKIDATA >Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge >(use -f to force) > >Richard -- > >I am also getting the "update-rc.d: /etc/init.d/XXX exists during rc.d purge" >error when I attempt to install a newer version of one of my packages. > >It doesn't look like you received any response to your post to the yocto >mailing list. > >Did you get any response, or did you discover a workaround? > >-- >Paul Stath >Axxcelera Broadband Wireless ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge (use -f to force)
Richard --
My "workaround" was a little less drastic than yours. (grin)
Before upgrading to the new package via 'dpkg -i', I would edit the postrm
script in /var/lib/dpkg/info/,postrm, adding the "-f" argument to
"force" the symlink removal, as suggested by the error message.
Then the upgrade install works correctly. (With only a warning from the postrm
script of the previous package.)
I believe that the issue is that when installing a package over an earlier
release, dpkg performs the following steps:
1) Extract control files of new package
2) Execute "prerm" script of previous package if applicable.
3) Execute "preinst" script of new package.
4) Unpack new files and backup old files.
5) Execute "postrm" script of previous package if applicable.
6) Configure the package
When installing a newer version of the package, the "postrm" in step 5 fails,
because the initscript from the new package is extracted in step 4, and
update-rc.d w/o the "-f" argument exits with a non-zero return code.
I would argue that the "updatercd_postrm()" stanza in the update-rc.d.bbclass
should include the "-f" flag.
(Anyone on the list want to chime in on this?)
In the meantime, I have added my own "updatercd_postrm()" stanza in the
.bbappend file for the package I'm having issues with, which overrides the one
provided by update-rc.d.bbclass.
updatercd_postrm() {
update-rc.d $D -f ${INITSCRIPT_NAME} remove
}
--
Paul Stath
Axxcelera Broadband Wireless
>From: Richard Leitner - SKIDATA [richard.leit...@skidata.com]
>Sent: Wednesday, November 27, 2013 11:02 AM
>To: Stath, Paul
>Cc: Yocto Project Discussion ML (yocto@yoctoproject.org)
>Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during rc.d purge
>(use -f to force)
>
>Hi Paul,
>good to hear I'm not the only one suffering from this issue...
>No, I've received no response on the mailing list yet, but maybe someone has a
>hint for us now?
>
>The only "workaround" I found is to purge the package and afterwards install
>the new version.
>I know this is a really dirty workaround, but it's the only "solution" I found.
>
>Have you discovered any other workarounds, Paul?
>
>regards
>Richard
>
>>-Original Message-
>>From: Stath, Paul [mailto:pst...@axxcelera.com]
>>Sent: Wednesday, November 27, 2013 4:49 PM
>>To: Richard Leitner - SKIDATA
>>Subject: RE: Errors with update-rc.d: /etc/init.d/XXX exists during rc.d
>>purge (use -f to force)
>>
>>Richard --
>>
>>I am also getting the "update-rc.d: /etc/init.d/XXX exists during rc.d purge"
>> error when I attempt to install a newer version of one of my packages.
>>
>>It doesn't look like you received any response to your post to the yocto
>>mailing list.
>>
>>Did you get any response, or did you discover a workaround?
>>
>>--
>>Paul Stath
>>Axxcelera Broadband Wireless
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Weekly Build Available
Folks, There seems to be autobuilder related issues with this build. I'm going to abort it, roll back the autobuilder config to the last good state and reroll. -b On Wed, Nov 27, 2013 at 3:11 PM, Flanagan, Elizabeth wrote: > The weekly build is about the be available at: > > http://autobuilder.yoctoproject.org/pub/nightly/20131127-1 > > Please begin scheduled testing. > > bitbake 347b2ead091f00ee60703f6f3d17cfdd9075ac07 > eclipse-poky-juno e8342d27db60a9d1b627ddb9f8ae2f5512bfc0c9 > eclipse-poky-kepler 3dd620d9f89e297ee9e22d5ba9fe741a5f40ac82 > meta-fsl-arm 987115d6d099a5e87d9d5b3c4e6567a5e6309fd0 > meta-fsl-ppc 768c6ef13546e0f977847bc1fbb5957571fbf724 > meta-intel a649e92498d234f2d0d52f3da5a85bdc87296c23 > meta-minnow 91cff9475081a5625c1c0bb49c17c6f3130ec503 > meta-qt3 b73552fb998fd30a01dbee5a172e432a16078222 > oecore f991d2d60b74f5ebd990f77aecd3324b1a4533e9 > poky 32adaac34a614d106e6dd3e9f1130f4e94ff39ae > > -- > Elizabeth Flanagan > Yocto Project > Build and Release -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: Weekly Build Available
Folks, We're respinning right now. The new build will be available in a few hours at: http://autobuilder.yoctoproject.org/pub/nightly/20131127-3 bitbake 347b2ead091f00ee60703f6f3d17cfdd9075ac07 eclipse-poky-juno e8342d27db60a9d1b627ddb9f8ae2f5512bfc0c9 eclipse-poky-kepler 3dd620d9f89e297ee9e22d5ba9fe741a5f40ac82 meta-fsl-arm 987115d6d099a5e87d9d5b3c4e6567a5e6309fd0 meta-fsl-ppc 768c6ef13546e0f977847bc1fbb5957571fbf724 meta-intel a649e92498d234f2d0d52f3da5a85bdc87296c23 meta-minnow 91cff9475081a5625c1c0bb49c17c6f3130ec503 meta-qt3 b73552fb998fd30a01dbee5a172e432a16078222 oecore f991d2d60b74f5ebd990f77aecd3324b1a4533e9 poky 32adaac34a614d106e6dd3e9f1130f4e94ff39ae ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to use pre-built external Yocto toolchain
I must be missing something obvious. It's easy for me to build and install a toolchain package using bitbake meta-toolchain The resulting toolchain package shows up at... ./tmp/deploy/sdk/poky-eglibc-i686-meta-toolchain-core2-toolchain-1.5.sh ...which is easy to install. It seems the proper way to use such an external toolchain would be to set TCMODE, but TCMODE only seems to support 'default' (i.e. build an internal toolchain) and 'external-sourcery' (i.e. use an external sourcery toolchain). :S How do I use an external toolchain built as above? Thanks! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: Weekly Build Available
Hi Beth, I can not access 20131127-3 directory because it doesn't exist. There is only 20131127-4 directory Would you please confirm it ? Thanks, Yi 于 2013年11月28日 01:32, Flanagan, Elizabeth 写道: Folks, We're respinning right now. The new build will be available in a few hours at: http://autobuilder.yoctoproject.org/pub/nightly/20131127-3 bitbake 347b2ead091f00ee60703f6f3d17cfdd9075ac07 eclipse-poky-juno e8342d27db60a9d1b627ddb9f8ae2f5512bfc0c9 eclipse-poky-kepler 3dd620d9f89e297ee9e22d5ba9fe741a5f40ac82 meta-fsl-arm 987115d6d099a5e87d9d5b3c4e6567a5e6309fd0 meta-fsl-ppc 768c6ef13546e0f977847bc1fbb5957571fbf724 meta-intel a649e92498d234f2d0d52f3da5a85bdc87296c23 meta-minnow 91cff9475081a5625c1c0bb49c17c6f3130ec503 meta-qt3 b73552fb998fd30a01dbee5a172e432a16078222 oecore f991d2d60b74f5ebd990f77aecd3324b1a4533e9 poky 32adaac34a614d106e6dd3e9f1130f4e94ff39ae ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] unbootable image produced with PACKAGE_CLASSES ?= "package_ipk", /etc missing
Hi Paul,
Thanks, seems not enough space when ipk ? I will try a ipk build today.
// Robert
On 11/27/2013 06:57 PM, Paul Eggleton wrote:
Robert, since I think you implemented this, any idea what might be going wrong
here?
Cheers,
Paul
On Tuesday 26 November 2013 17:27:30 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.eggle...@linux.intel.com> wrote:
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
onefor 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.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Patch failure with bbappends
Hi All, I am seeing an interesting effect due to a specific commit to bitbake/poky, which is causing the patching of gcc-* recipes from the meta-xilinx layer to fail. I understand that master of oe-core has switched to using GCC 4.8.2 since dora, however no changes to microblaze were added between 4.8.1 and 4.8.2. As such I have ruled out the patches themselves being the issue. But it appears the problem is that the patches to the working directory are being done twice during the intermediate steps of the gcc build. Build Configuration: BB_VERSION= "1.21.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "RedHatEnterpriseWorkstation-6.4" TARGET_SYS= "microblazeel-poky-linux" MACHINE = "qemumicroblaze" DISTRO= "poky" DISTRO_VERSION= "1.5+snapshot-20131128" TUNE_FEATURES = "microblaze v8.50 little-endian barrel-shift reorder pattern-compare divide-hard multiply-high fpu-hard" TARGET_FPU= "fpu-hard" meta-yocto meta = "master:82ff33fc398e6574905aa36f618ad06c3c79b8b7" meta-xilinx = "master:a573551a42e2f4c8efa82db90f938b10e62a3971" ... ERROR: Command Error: exit status: 1 Output: Applying patch 0001-Patch-microblaze-Enable-DWARF-exception-handling-sup.patch patching file gcc/common/config/microblaze/microblaze-common.c Hunk #1 FAILED at 37. 1 out of 1 hunk FAILED -- rejects in file gcc/common/config/microblaze/microblaze-common.c patching file gcc/config/microblaze/microblaze-protos.h Hunk #1 FAILED at 54. 1 out of 1 hunk FAILED -- rejects in file gcc/config/microblaze/microblaze-protos.h patching file gcc/config/microblaze/microblaze.c Hunk #1 succeeded at 1901 with fuzz 2 (offset 5 lines). Hunk #2 succeeded at 1940 with fuzz 1 (offset 12 lines). Hunk #3 succeeded at 2982 with fuzz 2 (offset 31 lines). Hunk #4 FAILED at 3184. 1 out of 4 hunks FAILED -- rejects in file gcc/config/microblaze/microblaze.c patching file gcc/config/microblaze/microblaze.h Hunk #1 succeeded at 199 with fuzz 2 (offset 15 lines). patching file gcc/config/microblaze/microblaze.md Hunk #1 FAILED at 2221. 1 out of 1 hunk FAILED -- rejects in file gcc/config/microblaze/microblaze.md Patch 0001-Patch-microblaze-Enable-DWARF-exception-handling-sup.patch does not apply (enforce with -f) ERROR: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /tmp/tmp.AHBPDCkrUT/tmp/work-shared/gcc-4.8.2-r0/temp/log.do_patch.17977 ERROR: Task 750 (/tmp/tmp.AHBPDCkrUT/repos/poky/meta/recipes-devtools/gcc/libgcc_4.8.bb, do_patch) failed with exit code '1' The following other recipes fail at the do_patch step with the exact same error: ERROR: Task 394 (/tmp/tmp.AHBPDCkrUT/repos/poky/meta/recipes-devtools/gcc/gcc-cross-initial_4.8.bb, do_patch) failed with exit code '1' ERROR: Task 474 (/tmp/tmp.AHBPDCkrUT/repos/poky/meta/recipes-devtools/gcc/gcc-cross_4.8.bb, do_patch) failed with exit code '1' ERROR: Task 487 (/tmp/tmp.AHBPDCkrUT/repos/poky/meta/recipes-devtools/gcc/gcc-runtime_4.8.bb, do_patch) failed with exit code '1' --- I have done some debugging to determine which change caused the effects, bisecting between the merge base of dora and master (on the poky repo) landed me on a bitbake commit: commit 381d5920188398bc53b2454843054c8690bca243 Author: Saul Wold Date: Thu Nov 21 09:50:41 2013 -0800 bitbake: cooker: add support for using % as a wildcard in bbappend filename There has been a continuing call for supporting wildcard in bbappend filenames. The wildcard is actually allow matching of the name and version up to the point of encountering the %. This approach will allow for matching of the major or major.minor. Exampes: busybox_1.21.1.bb busybox_1.21.%.bbappend will match busybox_1.2%.bbappend will also match if we update to busybox_1.3.0.bb the above won't match, but a busybox_1.%.bb will. [YOCTO #5411] (Bitbake rev: 31bc9af9cd56e7b318924869970e850993fafc5f) Signed-off-by: Saul Wold Signed-off-by: Richard Purdie Reverting this commit on the top of master results in a functional build. I've done some 'bitbake -e' scanning with and without the above commit, and I cannot see any differences between the variables that are changed in the meta-xilinx .bbappends files. So it does not appear to be a problem in non-inclusion of the bbappend files, and the ordering of the inclusion appears to be correct as well. Before I dive any deeper into the bitbake change itself I was hoping someone might have seen this issue previously or has some insight. Thanks, Nathan ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
