Funtoo on the Odroid-xu4

[lazlo.vii]

I have an Odroid-xu4 and I would like to install Funtoo.  The newest stage3 file is from late July and I took a peek inside at the ego.conf file.  It isn't setup for 1.2 and naturally the version of ego is less than 2.6.0.

Are there plans to continue supporting the Odroid-xu4?  I understand that with limited resources you guys can only do so much.  If the Odroid support is "on the back burner" that is ok.  If it is discontinued I can live with that too.  I'll just look for another solution.  Either way I would be grateful for a status update.

[safulkin]

I am asus tinkerboard single board computer enthusiast. Funtoo work great with many single board computers. Reason why stage3 stuck in GCC version.

latest in tree gcc-7.3.1-r3 build fail on arm architecture, but previous gcc-7.3.1 work fine.

So solution steps is:

• begin with latest stage3
• mask broken version =sys-devel/gcc-7.3.1-r3 in Your /etc/portage/package.mask
• perform 1.2 upgrade steps with official Funtoo upgrade instruction https://www.funtoo.org/Upgrade_Instructions

 

 

 

[lazlo.vii]

I masked =sys-devel/gcc-7.3.1-r3 and tried the upgrade, but has to revert to a backup.  It seems that the gcc 7.3.1 is ignoring MAKEOPTS and spawing so many threads the my poor xu4 segfaults the compilation or hangs and needs to be reset.  The freeze up has got to heat related since the stock fan is always at max rpm when it happens. 

[safulkin]

PORTAGE_NICENESS="19"

this parameter lower portage threads priority and system remain responsible

 

EMERGE_DEFAULT_OPTS="--jobs 2 --load-average 4"

--jobs limit amount of parallel running jobs.

--load-average for soft limiting overall CPU load average. In practice, with --load-average 4 htop tool show actual load average between 3.5 and 8.5

Tune this parameters, try just one or two jobs and load average less then amount of CPU cores.

 

Do You have swap partition? I have 4 Gb swap partition. Swap partition solve out-of-memory build faults.

[lazlo.vii]

Thanks for the tips.  Is there any significant difference between your suggested EMERGE_DEFAULT_OPTS and MAKEOPTS="-j2 -l4"?  Right now my make.conf has MAKEOPTS="-j4 -l4" and the gcc ebuild was still spawning enough threads to send the load average through the roof.  I tried everything else I could think of short of editing the files in Portage.  I didn't try that because I know that I don't know enough to do it right and I would hate to screw up my system with an ugly hack 'n' slash of Portage.  I even set up an NFS share to hold my root Odroid file system so I don't have to worry about corrupting the SD card with the constant I/O of compiling packages.  Well, filesystems, really because it is hosting the default ubuntu as well as funtoo, devuan, and armbian.  I am just one file edit and reboot away from switching between them and the gigabit NIC is faster than the SD card reader by a long shot.

 

Anyway I'll try the EMERGE_DEFAULT_OPTS later and see if it has the desired effect.  Thanks again.

 

EDIT:  OK, the EMERGE_DEFAULT_OPTS line you gave me is pretty much the same as "emerge --jobs=2 --load-average=4" and it had no effect on the amount of threads portage was spawning.  I guess I'll either wait until an official update comes down the pipe or get brave enough to try editing Portage files. 

[lazlo.vii]

Today I decided to start fresh with the stage3 tar from late July.  I have made good progress in that gcc 7.3.1 compiled without crashing and while respecting my MAKEOPTS settings.  It only took it about 3 hours to run.  Now I am working my way through the rest of the 1.2 upgrade and am currently running "emerge -e @world" but there is one thing that I don't like. 

 

When an ebuild is done compiling I get an error that looks something like this:

"Failed to set XATTR_PAX markings <string for markings> </path/to/portage/build/dir>

Life is never dull as long as I have my Odroid ?

[lazlo.vii]

 * Messages for package sys-devel/gcc-7.3.1:
	 
	* Failed to set XATTR_PAX markings -re /var/tmp/portage/sys-devel/gcc-7.3.1/image//usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/7.3.1/cc1.
 * Failed to set XATTR_PAX markings -re /var/tmp/portage/sys-devel/gcc-7.3.1/image//usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/7.3.1/cc1plus.

 

This shows up at the end of merging gcc and there is a similar message after merging python.  Is it going to impact my system stability or security in the long run?  I would like to go ahead and start building my X server, DE, and other things I had planned for my XU4 but I don't want to waste time.  With a bare bones stage3 install it took over 6 hours just to "emerge -e @world."

[palica]

this is kernel related IMHO.

are you using hardened stage?

what kernel version ...

[lazlo.vii]

7 hours ago, palica said:

this is kernel related IMHO.

are you using hardened stage?

what kernel version ...

I am using the stage3 from here:

  https://build.funtoo.org/funtoo-current/arm-32bit/odroid-xu4/

 

The kernel is  4.14.78+ from here:

https://github.com/hardkernel/linux/tree/odroidxu4-4.14.y/kernel

 

I am using the default kernel config for an Odroid xu3 or xu4.  The kernel was compiled following this guide for native compile:

https://wiki.odroid.com/odroid-xu4/software/building_kernel#native-build

 

EDIT:  I copied the kernel .config  to http://termbin.com/zeue