during a local rebuild of the angstroem image, the build fails
during the screen recipe:
NOTE: Running task 908 of 919 (ID: 1, /extopt/beaglebone/angstroembuild/build/setup-scripts/sources/openembedded-core/meta/recipes-extended/screen/screen_4.0.3.bb, do_patch)
NOTE: package screen-4.0.3-r3: task do_patch: Started
ERROR: Command Error: exit status: 1 Output:
Applying patch screen_4.0.3-11+lenny1.diff
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.
Patch screen_4.0.3-11+lenny1.diff does not apply (enforce with -f)
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: /extopt/beaglebone/angstroembuild/build/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/screen-4.0.3-r3/temp/log.do_patch.11944
NOTE: package screen-4.0.3-r3: task do_patch: Failed
ERROR: Task 1 (/extopt/beaglebone/angstroembuild/build/setup-scripts/sources/openembedded-core/meta/recipes-extended/screen/screen_4.0.3.bb, do_patch) failed with exit code ‘1’
NOTE: Tasks Summary: Attempted 908 tasks of which 907 didn’t need to be rerun and 1 failed.
Can someone help to determine what exactly goes wrong?
your patch is not the solution. The error still remains.
ERROR: Command Error: exit status: 1 Output:
Applying patch screen_4.0.3-11+lenny1.diff
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.
Patch screen_4.0.3-11+lenny1.diff does not apply (enforce with -f)
ERROR: Function failed: patch_do_patch
I will investigate what the cause of this is.
kind regards,
gerrit
For various reasons, I had to start a clean build on a new machine and just hit this error in the build (and am now applying the patch again). I will let you know what I find.
Do you have any errors displayed before the final indicating trouble fetching the patch from archive.debian.org?
it seems that the patch is not extracted as it should be. I am working on a workarround.
But this stupid long running angstroem builds prevent to find a quick solution.
It seems that a simple buildroot chain works more faster. For example - the build root chain
introduced here a Xmas time runs through in 4…6 hours on my development maschine.
The complete angstroem build from virtual / kernel to cloud9-image runs more than 14 hours.
It seems that my build is actually successfull (running … at package cloud9-image-1.0-r0: task do_rootfs: Started)
Here is what I did
First download the missing packages manually and put them in the sources/download folder
No bitbake receipes have to be changed
Missing packages e.g. is debian_utils
Download the patch manually
gunzip screen_4.0.3-11+lenny1.diff.gz
mv screen_4.0.3-11+lenny1.diff temp.diff
less temp.diff > screen_4.0.3-11+lenny1.diff
Since the *.diff file is not readable via cat, but it seems that the patch routine needs plain text
some conversions must be done. One possible way is described above.
After that, put the file screen_4.0.3-11+lenny1.diff in the directory
build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/screen-4.0.3-r4/screen_4.0.3-11+lenny1.diff
I see the issue now. The URI I was using was fetching the page rather than the source. I must have downloaded the correct file while debugging.
Here is a corrected bitbake file for screen. I just ran this after cleaning the screen download and intermediate files out, and this step now works.
After installing the file, you will need to do the following:
delete the old, incorrect screen…tar.gz file
run bitbake -c clean screen
then build cloud0-image
You should see it get to the screen step, download the new file, apply the patches, and compile without error.
Note: as before, I have hardcoded the archive source in the URI. No doubt this is a poor practice, and I will let someone more experienced with bitbake files correct it.
thanks to you! I proceed with my method. Now the build stops with error while baking the cloud9-image.
There are some issues with /dev/loop1
I added the build user to the disk group. But no success so far.
As build environment I use openSuse 12.1.
It is not a hard error. All the packes are build and in the deploy directory.
One can use opkg upgrade to update the beaglebone via local network.
Kind regards,
Gerrit
When you build the cloud9-image, it will tell you that you need an entry in /etc/fstab
sudo vi /etc/fstab and paste this line from the build error into the /etc/fstab, but replace the spaces with tabs.
Then, the error may fail again. The program genext2fs may have a bug with images over 2GB, and the cloud9-image is I believe 3.6GB. genext2fs also requires as much memory as the image size, so if you are running on a machine with less than 4GB available (or using a 32 bit Linux that cannot address 4GB) you will run into this limitation.
Someone has patched genext2fs to work around these problems, but it’s not in the official download yet.
See here for the discussion about genext2fs and the patches to handle 4GB images.
I am stuck at the same point, gabeagle. I have Dexuan’s patched genext2fs which is supposed to work for large images like cloud9. I see this error on Ubuntu 64 11.10 and 10.04.
Next step would be to put print statements around the point where genext2fs generates the ftruncate error in order to figure out what the problem is.
Same here.
Seems to me the problem could be commit “eceb8e05b9e984e8221fb9a3754c2253d8c980f8” on “./sources/meta-ti/classes/sdcard_image.bbclass”:
“sdcard_image bbclass: run genex2fs directly on the loop device”.
The man page says…
“EINVAL fd does not reference a regular file.”
And /dev/loop3 is not a regular file…
I’m trying on my system, but it isn’t fast so it has not reached the bug yet.
Cordially,