Building angstrom fails

Hi Folks,

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/, 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/, 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?

kind regards,

The patch file requested, patch screen_4.0.3-11, is no longer on the debian server, so the bitbake script cannot fetch it and the build breaks.

I updated the bitbake file for screen to point to the old version that’s now on the debian archive:

I hardcoded the server name in the script, as I don’t know where the variables are set for bitbake files.

Drop the attached into:


And this part of the build will now work. (1.81 KB)

Hi Pat,

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,

Hello everyone,

I am wondering if someone in this assembly could give me a link or a way to get “the angstrom and kernel 3.2.5+ sources for beaglebone REV A5”

Thank’s to everebody

Hi 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

Hi Pat,

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.

And as we all determine, it is buggy as well.

Kind regards,

Hi again,

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

  1. 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

  2. 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

Heres the result of my logfile

NOTE: Applying patch ‘screen_4.0.3-11+lenny1.diff’ (build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/screen-4.0.3-r4/screen_4.0.3-11+lenny1.diff)
NOTE: Applying patch ‘configure.patch’ (sources/openembedded-core/meta/recipes-extended/screen/screen-4.0.3/configure.patch)
NOTE: Applying patch ‘fix-parallel-make.patch’ (sources/openembedded-core/meta/recipes-extended/screen/screen-4.0.3/fix-parallel-make.patch)

Kind regards,

Hi Gerrit,

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:

  1. delete the old, incorrect screen…tar.gz file
  2. run bitbake -c clean screen
  3. 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. (1.64 KB)

Hi Pat,

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,

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.

To recap:

  • Add line to /etc/fstab as given in the output of bitbake cloud9-image

  • Run the final image generation step on a 64 bit Linux, or a 32 bit with patches (called PAE I believe) to allow it to address the full 4GB.

  • You need 4GB of memory or more accessible to Linux

  • You may need patches to genext2fs to allow it to build a 4GB image

I’m seeing this at the end of my cloud9-image compile…

/home/michael/BEAGLEBONE/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/beaglebone-angstrom-linux-gnueabi/cloud9-image-1.0-r0/rootfs/usr/share/beaglebone-getting-started/info.txt' -> /home/michael/BEAGLEBONE/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/beaglebone-angstrom-linux-gnueabi/cloud9-image-1.0-r0/tmp-mnt-boot/info.txt’
Cleaning up VFAT mount
ERROR: object ‘’ from LD_PRELOAD cannot be preloaded: ignored.
Creating rootfs loopback
genext2fs: set_file_size: ftruncate: Invalid argument
NOTE: package cloud9-image-1.0-r0: task do_rootfs: Failed
ERROR: Task 8 (/home/michael/BEAGLEBONE/setup-scripts/sources/meta-ti/recipes-misc/images/, do_rootfs) failed with exit code ‘1’
NOTE: Tasks Summary: Attempted 4597 tasks of which 4596 didn’t need to be rerun and 1 failed.

Summary: 1 task failed:
/home/michael/BEAGLEBONE/setup-scripts/sources/meta-ti/recipes-misc/images/, do_rootfs
Summary: There were 2 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Has anyone heard if they’ve applied that latest patch to henext2fs? If not does anyone know of step by step instructions on how to do so?

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.