Jump to content

Building a XU4 wheezy image always fails


jeansburger

Recommended Posts

I am trying to build a Wheezy image for the Odroid XU4, everything seemingly compiles okay it get to building and compressing the image and I get an error from the tools.sh file.

 

Here is my output log.

Displaying message: Preparing host info
Displaying message: Build host OS release xenial info
Displaying message: Downloading toolchain gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabi info
Displaying message: Verifying
Displaying message: Extracting
Displaying message: Download complete  info
## BUILD SCRIPT ENVIRONMENT

Version: db2129e7177f2b9ec17f6e4584b13303427645c9

## BUILD CONFIGURATION

Build target:
Board: odroidxu4
Branch: next

Kernel configuration:
Repository: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Branch: tag:v4.8.4
Config file: linux-odroidxu4-next

U-boot configuration:
Repository: git://git.denx.de/u-boot.git
Branch: tag:v2016.05
Offset: 4
Size: 0

CPU configuration:
600000 - 1800000 with 
Displaying message: Starting Armbian build script @host info
Displaying message: Syncing clock host info
Displaying message: Downloading sources  info
Displaying message: Checking git sources u-boot-odroidxu v2016.05 info
Displaying message: Creating local copy
Displaying message: Fetching updates
Displaying message: Checking out
Displaying message: Checking git sources linux-vanilla v4.8.4 info
Displaying message: Creating local copy
Displaying message: Fetching updates
Displaying message: Checking out
Displaying message: Checking git sources sunxi-tools master info
Displaying message: Up to date
Displaying message: Cleaning u-boot-odroidxu/v2016.05 info
Displaying message: Cleaning linux-vanilla/v4.8.4 info
Displaying message: Cleaning output/debs for odroidxu4 next info
Displaying message: Started patching process for u-boot u-boot-odroidxu-next info
Displaying message: Looking for user patches in userpatches/u-boot/u-boot-odroidxu-next info
Displaying message: ... odroid-xu4_defconfig.patch succeeded info
Displaying message: ... xu4_blobs.patch succeeded info
Displaying message: ... xu4_sd_fusing.patch succeeded info
Displaying message: Compiling uboot 2016.05 info
Displaying message: Compiler version arm-linux-gnueabihf-gcc 5.4.0 info
Displaying message: Building deb linux-u-boot-next-odroidxu4_5.23_armhf.deb info
Displaying message: Patching kernel for compiler support
Reversed (or previously applied) patch detected!  Assuming -R.
Displaying message: Started patching process for kernel odroidxu4-next info
Displaying message: Looking for user patches in userpatches/kernel/odroidxu4-next info
Displaying message: ... bash_to_afterinstall.patch succeeded info
Displaying message: ... packaging-4.x-NEXT-with-postinstall-scripts.patch succeeded info
Displaying message: Compiling next kernel 4.8.4 info
Displaying message: Compiler version arm-linux-gnueabihf-gcc 5.4.0 info
Displaying message: Using kernel config file lib/config/kernel/linux-odroidxu4-next.config info
Displaying message: Creating board support package odroidxu4 next info
Displaying message: Fingerprinting
Displaying message: Building package linux-wheezy-root-next-odroidxu4 info
Displaying message: Starting rootfs and image building process for odroidxu4 wheezy info
Displaying message: Extracting wheezy-ng-armhf.b91...4d1.tgz 0 days old info
Displaying message: Applying distribution specific tweaks for wheezy info
Displaying message: Applying common tweaks  info
Displaying message: Installing kernel linux-image-next-odroidxu4 info
Displaying message: Installing u-boot linux-u-boot-next-odroidxu4 info
Displaying message: Installing headers linux-headers-next-odroidxu4 info
Displaying message: Installing generic firmware armbian-firmware info
Displaying message: Installing DTB linux-dtb-next-odroidxu4 info
Displaying message: Installing board support package odroidxu4 info
Displaying message: Installing extra applications and drivers  info
Displaying message: Installing linux firmware 5.23 info
Displaying message: Building deb armbian-tools info
Displaying message: ... downloading sources temper info
Displaying message: ... downloading sources BT utils info
Displaying message: ... compiling temper info
Displaying message: ERROR in function compiling tools.sh:70 err
Displaying message: Error building temper err
Displaying message: Process terminated  info
Displaying message: ERROR in function unmount_on_exit debootstrap-ng.sh:569 err
Displaying message: debootstrap-ng was interrupted  err
Displaying message: Process terminated  info

I have no clue how to fix this error or what I need to modify or install to resolve it.

 

Thanks in advance.

Link to comment
Share on other sites

Any special need to have Wheezy? We are slowly abandoning support for Debian Wheezy and Ubuntu Trusty since this job is getting harder and pointless. Jessie is stable for some time now and it works fine.

Link to comment
Share on other sites

@jeansburger

 

As Igor writes, last time I have tested jessie (& a little bit xenial).

Wheezy/XU4 has been removed from the distro list for a while.

[ o.k. ] Writing U-boot bootloader [ /dev/loop0 ]
[ o.k. ] Signing and compressing [ Please wait! ]
[ o.k. ] Done building [ /home/gr/gro_armbian/output/images/Armbian_5.21-GRO_Odroidxu4_Debian_jessie_4.8.4.7z [194M] ]
[ o.k. ] Runtime [ 39 min ]

Link to comment
Share on other sites

Displaying message: ERROR in function compiling tools.sh:70 err
Displaying message: Error building temper err

Since it is failing at building additional tools, you can try adding EXTERNAL=no to compile.sh to disable building these tools.

 

Maybe we should not interrupt build process if non-critical packages failed to build, or even remove temper and USB redirector since they are not specific to our supported hardware and most people don't need these tools.

Link to comment
Share on other sites

Any special need to have Wheezy? We are slowly abandoning support for Debian Wheezy and Ubuntu Trusty since this job is getting harder and pointless. Jessie is stable for some time now and it works fine.

 

This is part of a extra credit assignment for a graduate class I'm taking. I need to build a wheezy image for an arm board and modify the kernel to do something extra, for myself I'm trying to modify the kernel for the XU4 to allow for the use of all 8 cores of the processor. The other reason I would like to have wheezy is when I am done with the assignment I will install open media vault on it to have a fast but small footprint NAS, from what I have read on the OMV page there is no support for Jessie when installing OMV 2.x on top as it only is for testing/ proof of concept.

Link to comment
Share on other sites

The other reason I would like to have wheezy is when I am done with the assignment install open media vault on it to have a fast but small footprint NAS, from what I have read on the OMV page there is no support for Jessie when installing OMV 2.x on top as it only is for testing/ proof of concept.

 

Well, regarding OMV 3.x and Jessie please have a look at http://forum.armbian.com/index.php/topic/2644-openmediavault-3x-customize-imagesh/

 

Then I really don't get why one wants to use software outdated like hell (OMV 3.x for example does also not run on Ubuntu Xenial since there no horribly outdated PHP5 is fortunately available any more).

 

Since you want to use ODROID-XU4 as NAS please check the bottom of post #10 here: http://forum.armbian.com/index.php/topic/1925-some-storage-benchmarks-on-sbcs/?p=15318  (so better go the other direction and forget about smelly outdated stuff).

 

BTW: the real problem why the build failed has already been mentioned by Zador.

Link to comment
Share on other sites

Well, regarding OMV 3.x and Jessie please have a look at http://forum.armbian.com/index.php/topic/2644-openmediavault-3x-customize-imagesh/

 

This may be because I used OMV 3.x on my raspberry pi 2 (useing the image found on sourceforge), when I installed it on the pi it just broke itself when I tried to do any updates. Is it more stable on other boards? I would like to be able to use OMV 3.x but I would like something that is very stable so that I won't have to constantly fix it if the system updates itself.

Link to comment
Share on other sites

This may be because I used OMV 3.x on my raspberry pi 2 (useing the image found on sourceforge), when I installed it on the pi it just broke itself when I tried to do any updates. Is it more stable on other boards?

 

Same experiences made by me when I started with this SBC stuff a few years ago. Every OMV image I tried was horrible (insecure, slow, fragile). This is one of the reasons I try to contribute to Armbian today.

 

Regarding OMV I would join the aforementioned thread since this is the right approach: Create a 'recipe' for an OMV image on a solid foundation that doesn't suck and is also universal (if it uses Armbian it can run on any of the SBC you find here -- maybe the 2 64-bit SBC require some extra work). And a pretty simple method to don't fear OS updates any more is to use mainline kernel, btrfs and snapshots (and backup u-boot+spl prior to updates). If you do it this way and create a snapshot each time you do an update nothing can go wrong (since you simply do a rollback to the snapshot before if something breaks).

Link to comment
Share on other sites

This is part of a extra credit assignment for a graduate class I'm taking. I need to build a wheezy image for an arm board and modify the kernel to do something extra, for myself I'm trying to modify the kernel for the XU4 to allow for the use of all 8 cores of the processor. The other reason I would like to have wheezy is when I am done with the assignment I will install open media vault on it to have a fast but small footprint NAS, from what I have read on the OMV page there is no support for Jessie when installing OMV 2.x on top as it only is for testing/ proof of concept.

 

just a crazy idea

 

A downgrade from jessie to wheezy

https://duckduckgo.com/?q=downgrade+jessie+wheezy&ia=web

Link to comment
Share on other sites

 And a pretty simple method to don't fear OS updates any more is to use mainline kernel, btrfs and snapshots (and backup u-boot+spl prior to updates). If you do it this way and create a snapshot each time you do an update nothing can go wrong (since you simply do a rollback to the snapshot before if something breaks).

 

Thank you for the help! I have been trying to figure out how to do the whole backup u-boot+spl, would I have to just read the image using something like Win32 Imager? Or is there a more elegant way to do this from inside the system that I can just throw onto my server for future need?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines