Gentoo on Odroid XU4

I have a BUNCH of links open in my XU4 FireFox browser and it’s chewing about 100% of CPU (it can go higher than 100% as it is 8 cores, but still, I’m getting sporadic pauses). So… I’m going through turning some into bookmarks and just deleting other tabs. I’ve decided to aggregate the Gentoo tabs into this posting to make them easy to reach from any of my machines.

If you are not interested in the XU4, Gentoo, or how to install Linux on an ARM system, you likely don’t care about any of this.

It is in no particular order. Just grabbing the link and stuffing it here for the future. “Someday” I’m likely to go to Gentoo on the XU4 simply because, while a PITA to install, it is a SystemD(emented) free port. But not, I think, today; so saving the links is it.

Generic “where to get OS images” link at Odroid:

Not Gentoo, but Arch, who have decided to BOHICA and let SystemD(eviant) have it’s why with them:

The Arch ARM repository:

Nice article on installing Gentoo:

Installing Gentoo base system:

The OpenRC init system (a Gentoo alternative to both SystemD and RC based inits):

Some Gentoo XU4 bits and with emphasis on formatting partitions:

How configuring Gentoo Repos works:

The Stage 3 files:

What to do if your emerge keyserver refresh fails:

Bugbase on a keyserver related bug:

Sync failure discussion:

A related, but different, derivative of Gentoo, Funtoo. Design goal is removal of some Gentoo PITA:

The Funtoo download (and what I’m more likely to try next when “someday” I return to doing a Gentoo / Funtoo on XU4):

Subscribe to feed


About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits and tagged , , , , , , . Bookmark the permalink.

60 Responses to Gentoo on Odroid XU4

  1. E.M.Smith says:

    Well, pruning tabs didn’t do anything. I discovered the English Dictionary wasn’t working, so went to the addons page:
    to do a remove / reinstall. It is now spinning endlessly on the remove step.

    So, I figure something made the Dictionary barf, and now it doesn’t work, and isn’t “installed” enough to be removed. Next I’ll try just crashing the de-install and then re-installing. IF that doesn’t work, I’m a bit hosed. This release is out of support and the repositories have moved off to archives “somewhere”, so do remove / reinstall Firefox in total I’ll need to figure out where all the repositories have gone off to and change my /etc/apt/sources.list accordingly.

    Sigh. Not what I had in mind for this morning. Maybe I’ll just boot up on a different system…

  2. E.M.Smith says:

    Well, that was interesting…

    I crashed the “remove” page and instead installed a British English Dictionary. Then the American English Dictionary would not let me chose “remove” again (even though it showed only the “remove” button). After shutting down FireFox, and then relaunching it, spelling checks once again work (though of the British flavour and colour) and I am again offered the opportunity to install the American English Dictionary. So something got cleaned up

    CPU “spin” is down some, but still higher than I think proper at about 75% of a core while doing nothing. Oh Well. Good enough.

  3. cdquarles says:

    Speaking of ARM, I have seen reports that nVidia is going to buy them.

  4. E.M.Smith says:

    Yeah, but….

    ARM corporate doesn’t make chips. They license instruction sets and core designs. So oodles of folks have existing licenses and roll their own. Samsung, Apple, and many more. Those licenses have persistance.

    So what is really being bought is royalties from old licenses, and the right to design new instruction sets going forward.

    A bit different from, say, buying Intel with design, fab, inventory, distribution, etc.

    Then realize that ARM, nominally RISC, has been adding in complex instructions like pipelining as Intel patents expired. There isn’t much left down that road as Moore’s Law is winding down and most interesting instruction ideas are already known (and many expired patents).

    For over a decade now, most speed gain has come from more cores. ARM is now at 64 bit pipelined multicore (up to 8). There are effectivly increasingly hard limits that start biting hard at 64 bit, 8 cores, and 3 Ghz.

    Beyond 64 bit, packing and unpacking bytes takes away any math speed gains.
    Beyond 8 cores, few problems can effectively use all cores (at 2 k cores it is hard for even highly parallel codes for highly parallel problems to use all the machine)
    Physics is limiting at about 3 GHz and power needed goes way high.
    Physics is limiting at current feature nm width. Essentially, masking smaller requires using X-rays and shorter that just pass through the mask…

    So not much more that can be done to advance things on that front. Thus the big move to using CUDA Cores in nVidea video processors and massively parallel coding practices to reach the hard parallel limits at 2k to 4 k cores.

    My best guess is the present ARM owner (Softbank?) realized the super growth of the past was over, while nVidea is growing fast in the massivly parallel space (computer vision, self driving cars) and figured adding some ARM bits to their CUDA cores designs might be useful.

  5. E.M.Smith says:

    FWIW, I’m posting this comment from the RockPro64 running Slackware. I just did an update of it (as described in the comments here: ) and FireFox is nicely running a video with good audio.

    As almost all I need from my general purpose desktop is a working browser with sound and enough computes to run video, I think I’m set.

    The “Devuan Uplift” on the Odroid XU4 has just gotten too far out of sync with support. First off, the Jessie to Devuan uplift script is now deleted. Second, Armbian (the base Jessie I used) has archived the sources.list target (and in modest looking, I could not find a way to download it to my own sources server nor any alternative other than pointing at generic Debian and risking killing off bits of Armbian / Devuan that matter…) So I’ve run without updates for about a year now, and some things are starting to be an issue (i.e. not being able to install new applications).

    So at least until I’m able to put some other OS on the Odroid XU4, it is set aside. I’m going to be moving “stuff” from it to the RockPro64 since now it seems to do what all I want. (Not a real surprise. Usually when you buy “The Latest Hot Board” it takes about a year for the software to be all working right and bugs ironed out.

    Hopefully I’ll be happy with this Slackware release. I do need to spend a bit of time getting my Slackware Admin skills up. It is BSD style RC based init. It’s been about a decade since I did much with one of those. OTOH, with about 20 years+ of maintaining it professionally, I’m pretty sure all that stuff is still in the brain somewhere ;-) Biggest issues is the Slackware specific stuff like “slackpkg” for slackpkg update and slackpkg install-new.

    So it goes…

    Slackware has been around “since the beginning” and has been prone to NOT embracing all sorts of gratuitous and IMHO stupid changes from BSD roots. I’m good with that for most of my uses.

    It does have some limits that can annoy. It isn’t particularly NOOB friendly. The boot process is the older slower one thing at time version (OTOH you can watch and see when and where a boot fails in real time…)

    Then there’s stuff I’m not sure about yet. Does it have all the interesting file systems I like to play with? Will it have extra problems with newer versions of applications as SystemD forces changes n them? We’ll see. For now, it has all I need in a Daily Driver desktop. GIMP for image creation. Working browser with good sound. Functioning (AND STABLE) administration and file storage.

    So that’s where I am this morning.

    I’m looking at trying NetBSD on the Rock64 / Orange Pi One for various infrastructure uses. At present, the Orange Pi One file server is running Armbian, but the way Armbian just deep sixes support for a given release is a bit problematic. It means I’m either an orphan by surprise, or I must watch for the right moment, make a duplicate of the sources.list targets before they evaporate, and / or stay in sync with their constantly moving versions. (Which is problematic as it is a big workload, updates risk system failure, and then for some boards support may just end.)

    So IMHO Armbian is fine for first use for a year or two, but then you either need to be prepared to suddenly go “Stand Alone” or accept that you may be suddenly unable to add applications or do updates. And your board may be left an orphan once they lose interest in it.

    As they are “embedded” oriented, that’s reasonable. Vendors need support for a couple of years, then they are making new products on new boards and have moved on. IF the vendor does LTS Long Term Support on a product, they have a LTS team and have downloaded a set of sources and have their own sources.list target.

    Basically, Armbian isn’t “desktop oriented” and I am. I can live with that for a couple of years, but not for decade+, and I use equipment for decades…

    Anyway, enough of a rant. On to more productive things.

  6. E.M.Smith says:

    Hit my first issue. The “old” home directory account on the XU4 was successfully added to Slackware on the RockPro64 (via the wonderfully simple old school way of just editing /etc/passwd and /etc/group ;-) and the file system mounted.

    Logged in and everything was there, even my desktop looked right. Launched FireFox…

    Newer Firefox on the RockPro64 / Slackware informed me it used a new “Profile” system so all my old settings, bookmarks, etc. needed to be moved from the old to the new. “All” I needed to do was make a FaireFox account…

    Well, being unfond of making accounts all over and telling everyone all about me and getting SPAM email from the forever and being sold to vendors and…

    There’s an alternative, which is to reboot on the XU4 and dump my bookmarks, and open tabs URLs and then reload them here. OK, not too bad. Except I just put the XU4 back in the shipping box on the shelf.

    Yet Another Someday Task… For now, I’m using the local RockPro64 maintenance account.

    FWIW, I typically make 2 accounts on any machine / board. My “Daily Driver” general use accunt, and a “Boot and maintenance and emergency” account. That way if I screw up something in my Daily Driver account and can’t log in, I can log in as the “other me” and fix it. This also lets me avoid all the security hassles of trying to log in as root directly (some systems block this, others only let you do it in single user CLI Command Line Interface mode, etc.)

    Both accounts are fully functional and both are configured about the same. Just one gets most of the files, clutter, etc.

    So, OK, not a big problem. just something to note: FireFox has backwards compatibility barriers somewhere in the last year or so. Welcome to Dependency Hell (even if only a minor level of hell…)

    FWIW, I don’t have a lot of stuff in bookmarks or open tabs on the other account. I moved most of what I care about to this Gentoo posting. The rest I can fairly easily get back. So no big. Just a minor carbuncle on the rump of life…

  7. E.M.Smith says:

    Oh, and while I’m here:

    That Amdahl’s Law graph above, how to read it:

    Typically in a normies mix of workload, about 50% is suited to parallel processing. So look at the 50% line (light blue at the bottom). That’s saying you can cut run time in half if you use abut 8 cores, then you get no faster. That is why most desktop machines have at most 4 to 8 cores. Beyond that the typical user gets nothing more to show for the money.

    The half that does not run parallel now limits completion time.

    At the top, the green line, is showing that for an incredibly parallel computing task where 95% of it can be done in parallel, you can get a 20 times speedup at about 2000 cores, then you get nothing more. Supercomputers with 4000 or 8000 cores are really only “better” in that they can run 2 or 4 such jobs at the same time for different people (or can run tailored test cases very fast to claim superior performance over the competition in gross computes…)

    The 5% that does not run parallel now limits completion time.

    So consider a climate model with 16,000 cells. At about 2000 cores, you are maxed out. Why? Because once your run of cell 1 computes, it is I/O bound moving those results to where they need to be while you compute cell 2, 3, 4, etc. values (that then get I/O bound in the write step).
    Now it MIGHT be possible with very careful code design to make a system where each cell was mapped to a single core with local data store, and get 16,000 cores to all hummm together, but that’s way hard. Needs things like special data prefetch to move data from the database to each core cache storage, then careful handling of any subsequent write steps and more. Even then, it is unlikely you can avoid a fair amount of core idle time during I/O operations. Your gain over the case of 2000 cores and I/O processors handling data flow will likely be small (and very hard to attain).

    Essentially, you end up custom designing the computer and the data flow to match the problem, should you want to effectively use more than 2,000 to 4,000 cores. Though really, just to get to using 2000 cores you already did a lot of that. “Massively Parallel is Massively Hard. -E.M.Smith”

    While we’re not up against the wall just yet, and we may still have a “Miracle Happens” moment with some new bizarre technology, in reality we’ve got about one last Double Of Performance before it’s just not worth it anymore at the hardware level. At that point (and not likely before it), the focus will turn to all the horrible software bloat that’s gotten into things in the last couple of decades. Heck, folks might even start writing assembler again ;-)

    To some extent this is already happening. There are special languages and compilers being made to improve parallel execution of codes. More use of Graphics Vector Processors for math bits in parallel parts like rendering and big math problems. OS tweaks to make parallel threads easier and let more of them run. But it is going slowly in most cases.

    So, for example, on this RockPro64, in the browser, with a video running in another panel, I’m using about 1/2 of the 6 cores. It looks to me like about 3 to 4 cores of load but being spread arround. More cores will not give me any more performance on these tasks. Htop shows 255 threads in existence (many of them for the OS itself). So I’ve got a potential for 255 parallel tasks, but not filling up the box anyway so more cores not going to do much. Only 3 running at the moment, most waiting for some work to do.

  8. E.M.Smith says:

    Found an interesting discussion of Slackware on the XU4. I’ll add the link here later if I can. Essentially they did it via putting the Slackware userland on top of an Ubuntu kernel, modules, and libraries. I’ll have to ponder that a bit.

    It ought to work OK, and is less work than doing a full on Gentoo compile (as Gentoo is all source build, you spend a day or so doing compiles…). I’ve done other userland swaps on other systems, and it isn’t that hard. Biggest issue is just the risk of some Dependency Hell from different levels of libraries in kernel vs userland, but that’s usually OK if the releases are at all close in age.

    I find Gentoo (or Funtoo a more user friendly derivative) interesting as it IS a source build so you know it all works together. (BUT if it fails in the compiling steps it is up to you to fix it…). OTOH, Slackware is built binaries and I’ve already got it running on 3 or 4 different boards (but it suffers from being a bit out of date a lot on some applications and being a bit retro in look and feel at times).

    Decisions decisions…

    For now, I’m mostly going to work on moving my old Jessie Firefox to the new Slackware version on the RockPro64, and having it be my Daily Driver for a while.

    I’ll then archive the Armbian-uplift-to-Devuan-Jessie image from the XU4 and at that time see which port works for me. Probably do a “First one to work wins” with both of them.

    FWIW, on ARM boards, it is looking like Raspberry Pi gets the most support and ports. Other boards are a bit more “catch as catch can” and spotty. Armbian has the most breadth of support, but they only keep a couple of releases “up” and live for their source.list targets at any one time. You are expected to keep up with the constant river of change… No “build it and forget it”.

    Neither Slackware nor Gentoo (Funtoo) have a great depth with ARM boards, but both have working ports to major CPU types. Around the edges of odd boards, it is more “roll your own” and a bit technical. Mix in that Odroid have a particularly bothersome boot process and that means they get less love than others. Sad, since IMHO the Odroid Hardware is some of the best thought out and have proper heat removal built in. Oh Well.

    So, in summary:

    I’m still doing the “wander in the woods” of OS / release candidates that will let me avoid SystemD while also being relatively low support workload. For things that are modest use (i.e. very little admin on them so SystemD interaction is minimal) I’m still using Armbian, but staying in sync with release levels at least once a year. I also need to put a bit more priority on making a source.list archive locally so as to not have the archived release death bite me again. (I’ve done it before and there’s an article up about it, my only “problem” was that I didn’t make one for Armbian: )

    I’m mostly going to run Slackware, for now, on my non-Raspberry and non-Armbian systems. We’ll see if I can get a Gentoo build on some other board to work without too much pain and suffering, then I’ll take on the Odroid boot differences.

    The “good news” is that I seem to be centering in on Slackware and Gentoo (Funtoo) as the most likely candidates for non-Devuan systems. As much as I like Devuan, they just are not interested in providing systems for more than a couple of makers of boards at this time.

  9. E.M.Smith says:

    This looks promising, if still alive:

    Installing slackwarearm on a odroid XU4/HC2.
    slacwarearm containes all of the needed userspace binaries, but it doesn’t have a kernel for the odroid. I have made 4 packages to address this:


    This is a complete odroid kernel package and contains the kernel, the modules, the boot.ini, and the samsung exynos dtb files. :


    This is the “make headers_install” from the above kernel build which insures that you can build userland software for this kernel.


    This is the kernel source as it was at the end of the build.

    Option 1 (use the magic script)
    Just download the script and call it:

    chmod 755
    sudo ./ /dev/

    Option 2 (pretend to know what you are doing)
    Get the files and install manually. Where /dev/sdf is the name of your SD card:

    Step 1. Grab some files

    Step 2. Partition and format

    Partition the disk:
    parted -s -a optimal /dev/sdf “mklabel msdos mkpart primary fat32 2048s 266239s mkpart primary ext4 266240s -0″

    Now format it:
    mkfs.msdos -F 16 -I -n BOOT /dev/sdf1
    mke2fs -t ext4 /dev/sdf2

    Step 3. Install the Samsung SoC boot loader stuffs

    Extract and install binary bootloader code
    tar xvf xu4-boot.tar.gz
    cd xu4-boot
    ./ /dev/sdf
    cd ..

    Step 4. Mount.

    Mount the new filesystems to ./mnt
    mkdir -p mnt
    mount /dev/sdf2 mnt
    mkdir mnt/boot
    mount /dev/sdf1 mnt/boot

    Step 5. Extract rootfs.

    Extract the new slackware miniroot to the larger ext4 partition
    cd mnt
    tar xvf ../slack-current-miniroot_14Jan20.tar.xz

    Step 6. Install kernel and firmware

    Install the custom kernel and firmware packages
    tar xvf ../kernel-odroidxu4-4.14.165-arm-1.tgz
    sh install/
    rm -rf install
    tar xvf ../kernel-odroidxu4-firmware-20200122-noarch-1.tgz
    sh install/
    rm -rf install

    Step 7. Fix a few things:

    vi etc/fstab (delete everything and make it look like this)
    /dev/mmcblk1p1 /boot vfat defaults 0 1
    /dev/mmcblk1p2 / ext4 errors=remount-ro 0 1
    devpts /dev/pts devpts gid=5,mode=620 0 0
    proc /proc proc defaults 0 0
    tmpfs /dev/shm tmpfs defaults 0 0

    Fix the serial line since ttyS0 doesn’t exist on the odroid but ttySAC2 does.
    sed -i” ‘s/115200 ttyS0 vt100/115200 ttySAC2 vt100/’ etc/inittab

    Tell the dhcp client to wait 30 seconds on eth0 since it takes longer than the default timeout to get an address.
    — etc/rc.d/rc.inet1.conf.orig
    +++ etc/rc.d/rc.inet1.conf
    @@ -19,6 +19,7 @@

    Add ntp on boot since we don’t have a clock.
    echo “ntpdate” >> etc/rc.d/rc.local

    If you are going to be headless, then you might want to allow root to ssh
    Change “PermitRootLogin” to “yes” in etc/ssh/sshd_config

    Step 8. Cleanup.

    That’s it, you’re done, so umount, put the sd card in your odroid and give it a go.
    cd ..
    umount mnt/boot
    umount mnt
    rm -rf mnt

    Step 9. Configure system.
    Boot up and ssh to your new system. The password is listed in the text file for the miniroot:

    Setup slackpkg
    slackpkg update

    Change root password

    Install some useful packages
    slackpkg install curl diffutils infozip glibc smartmontools hdparm

    Check for updates
    slackpkg upgrade-all

  10. E.M.Smith says:

    Well, I’m moved onto the RockPro64 / Slackware now. Had to dump / restore bookmarks from the XU4 as this Firefox is not compatible. Also made a “private” copy of URLs that were open in tabs but not bookmarked to “save state”. I’ve likely lost other state information (history / cookies) for sites that depend on them to let me log on, but “We’ll see”.

    This is a faster experience than the XU4, some of that the 2 faster cores, but more of it, I think, the slim software. Slackware has always been a bit well optimized and low bloat.

    If this experience goes well, then I’ll put a Slackware on the XU4 and call it done. If it goes badly (i.e. if I find myself not fond of Slackware or can’t load needed software) then I’ll try a Gentoo install.

    Looking over Devuan, it looks like maybe The Newest Release has shipped the x86 versions but that the ARM boards might just be following slowly and later. Maybe an XU4 port will show up after all. But for now, the XU4 will just sit in the box a while.

    Both Slackware and Gentoo on the XU4 have you save a kernel, modules, and headers from some other build and then glue on their userland (along with keeping the Odroid specific boot binary / disk partition stuff). I’m OK with that, having done it before, but would really rather not have a Franken System.

    Oh Well.

    While I really like the XU4 as they have some of the most computes / $$ and a nice stable 32 bit system with good heat control: fighting with getting a non-systemD OS for it is too much time and trouble. 64 Bit software has matured enough on ARM that it is no longer an issue, and other boards have simpler boot process so get more “load and go” support. I may just have to “move on”. Make it a general use desktop or some dedicated infrastructure thing.

    I’d intended to make it the hart of a 32 bit cluster, but to do things like distributed compiles requires the same release level of libraries on all parts, and that’s just not going to happen in a heterogeneous environment of different boards and it. Compare the Rock64 and RockPro64 where both easily installed and booted Slackware. So 10 fast cores all the same OS, no grief. Or the Raspberry Pi stack where I’ve got 16 cores, all the same software (and several choices of it).

    So “it is what it is”. As of now, the XU4 is on the bench and the RockPro64 has had software maturity catch up to where it’s very nice. So it’s the Daily Driver and candidate for Build Cluster cores. I do need to find out if the “missing bits” from first release (that caused me to set it aside for a while) are really all there now. Python. SQL. Gimp. etc. and working properly. IIRC, I was having issues with plots in Python from the database…. so checking that needs doing.

    But as a general desktop, browser (modulo the link / bookmark / history / profile conversion), file system and workstation, it looks like it’s pretty good.

  11. E.M.Smith says:

    And no sooner said that then found out GIMP isn’t working:

    bash-5.0$ gimp
    gimp: error while loading shared libraries: cannot open shared object file: No such file or directory

    So some libraries missing or misplaced. Guess I’ll try a GIMP reinstall…

  12. E.M.Smith says:

    Sadly, it looks like ARM systems are still treated as 2nd class citizens. Gentoo has a Stage 3 tarball, but installation instructions are lacking:

    What should I download? What do I do with these files?
    If you are unsure what you need to download, please refer to the Gentoo Handbook for the complete installation documentation.
    It explains how you can find the right architecture for your machine and which files you need at what stage of the installation process.

    ARM Handbook
    ARM is a 32-bit architecture that is a very popular in embedded and small systems. Sub-architectures range from ARMv1 to ARMv7 (Cortex) and are often found in smart phones, tablets, hand-held consoles, end-user GPS navigation systems, etc. Variants include: StrongARM and Cortex-M.
    There is no ARM Handbook available at this time. Please see bug #534376.
    ARM64 Handbook
    ARM64 is a 64-bit variant of ARM for embedded and server systems. The primary sub-architecture referred to as AArch64 (also known as ARMv8-A) is produced by a few manufacturers. AArch64 chips are seen in a variety of SoCs including developer boards, smart phones, tablets, smart TVs, etc. Variants include: ARM Holdings’ Cortex-A53, A57, A72, A73, and Qualcomm’s Kryo and Falkor.
    There is no ARM64 Handbook available at this time. Please see bug #534376.

  13. Compu Gator says:

    E.M. Smith added on 19 September 2020 at 7:10 pm GMT:
    [….] on ARM boards, it is looking like Raspberry Pi gets the most support and ports. Other boards are a bit more “catch as catch can” and spotty. Armbian has the most breadth of support, but they only keep a couple of releases “up” and live for their
    source.list targets at any one time. You are expected to keep up with the constant river of change…  Nobuild it and forget it”.

    I am expected!?  Well!  [Expletives deleted]!  That’s about as potent a disqualifier for software for my personal use as I’m ever faced with, aside from outright unsuitability for the tasks to be performed.

    In certain noncomputational Chiefio topics, I’m among those alluding to my “comorbidities”,  so my remaining life-time is likely too short to have any of it wasted by source-code management practices as, ummm, miserly as Armbian‘s. What’s the problem that its people think they’re solving?  Don’t they understand that they’re risking making their distro “too bothersome” to survive?

  14. E.M.Smith says:

    Hmmm… reading this over:

    It has you prserve the boot sectors, kernel, headers and , modules. Then place them in an unpacked Funtoo image.

    This leads me to think I could just unpack the Funtoo into selected partion segments and overlay it on an existing working system…. as I’ve done with 32 and 64 bit Pi O/S on one chip… I think I’ll try that. Later.


    They are mostly solving the professional embedded systems maker issues, not the home desktop on ARM hobby user issues. In that context their choices make sense. Not the ones I’d prefer, but right for that market.

    As ARM starts intruding into the desktop space, that will change. But only now is it starting outside the hobby space (Apple and a low end laptop or 2).

    They make ports to as many SBCs as possible, then hand it to various device maker staff who grab their own copy and sources and customize for their product LTS. Those are the folks paying the bills.

    So some company with a custom router based on the Jessie port will have copied the stuff for archive for their LTS product needs, but the developer staff will be on current or devo … in the river of change.

    I saw the notice that Jessie was moving to archive, but ASSUMED that would be an open online archive. Not telling me to archive my own, too. My bad, not theirs.

  15. E.M.Smith says:

    Well, progress, even if not fully satisfied.

    I now have a working Funtoo install on the XU4 via a slight kludge. The SD chip is now dual boot. So I can boot the old Armbian Jessie uplifted to Devuan, or boot the fresh Funtoo install. Or “chroot” into Funtoo.

    I did a modification on the Funtoo page idea. Cleared the third partition on my chip (really checked it was empty) and changed the lable to SD_Funtoo, then unxz uncompressed and tar xvf the tar file. At that time, it has no /lib/modules nor /lib/firmware, so copied them from the running system. Also copied over /boot just in case. Edited the new fstab and went to chroot /SD/Funtoo where I had mounted it. Then you can set root passwd and do other config stuff.
    Finally, added a line to each boot.ini setting rootfs to that partition and rebooted.

    Came up live.

    I’ll put up more details and files later.

    It is a modestly thin system out of the box. Very fast, but missing bits I want. Like gparted, X windows, etc. Funtoo uses yet another package system, so next for me is to learn how to add missing packages and turn it from CLI only into a desktop.

    For now I’m happy to have it running.

    As I can chroot into it in a terminal window, I can boot the full graphical Armbian / Devuan OS then in a window work on adding packages.

    So off to learn Funtoo package management…

  16. E.M.Smith says:

    Probably ought to put all this in a new Funtoo – Not! posting…
    So in the chroot, I’m trying to update / upgrade and SW install desired bits. It isn’t working. Of course, “everything you know is wrong”, again, because Yet Another Bright Idea Guy decided to change things yet again. OK…

    In addition to the already byzantine Gentoo “emerge” system (with EVERYTHING configurable but not set right out of the box) it has layered on more stuff. “ego” and “meta-repo” and using “git” for packages and having meta-packages called “kits” (that used to be called “shards” that…).

    But hey, the “directions” say to just run “ego sync” and all will be fine…

    XU4_Funtoo /tmp # ego sync
    Running as root user (will drop perms for sync.)
    Syncing meta-repo
    fatal: open /dev/null or dup failed: Permission denied
    ERROR: Could not clone meta-repo at '/var/git/meta-repo'.
    WARNING: Cannot update repos.conf as meta-repo does not exist.
    Updating profiles at /etc/portage/make.profile/parent...
    ERROR: Ego encountered an unexpected error: KeyError
    ERROR: Full traceback written to /tmp/ego-traceback-4335.txt.

    Which produces the Oh So Useful log:

    XU4_Funtoo /tmp # cat ego-traceback-3711.txt 
    'release_defs'Traceback (most recent call last):
      File "/usr/bin/ego", line 118, in 
        EgoModule.run_ego_module(action, econfig, args, VERSION)
      File "/usr/share/ego/python/ego/", line 103, in run_ego_module
      File "/usr/share/ego/python/ego/", line 88, in __call__
      File "/usr/share/ego/modules/sync.ego", line 452, in handle
      File "/usr/share/ego/modules/sync.ego", line 412, in sync_meta_repo_and_kits
        EgoModule.run_ego_module('profile', self.config, ['update'])
      File "/usr/share/ego/python/ego/", line 103, in run_ego_module
      File "/usr/share/ego/modules/profile.ego", line 313, in __call__
      File "/usr/share/ego/python/ego/", line 88, in __call__
      File "/usr/share/ego/modules/profile.ego", line 294, in handle
      File "/usr/share/ego/modules/profile.ego", line 130, in handle_write
        self.tree.write(self.config, outfile)
      File "/usr/share/ego/python/ego/", line 462, in write
        for kit in self.config.all_kit_names_in_release:
      File "/usr/share/ego/python/ego/", line 97, in all_kit_names_in_release
        return self.kit_info_metadata["release_defs"][self.release].keys()
    KeyError: 'release_defs'
    XU4_Funtoo /tmp # 


    So what’s the problem? What to fix? Web searches are unenlightening…

    One says to set the permissions on a directory to what they already are. Another has directions for testers interested in trying this new meta-kit thing from years ago. Etc.

    Maybe it’s just my low exposure to emerge (and the new “ego” in Funtoo), but I really get the feeling some parts are missing… and steps to make them go…

    AND, I’m not even sure where to begin.

    So I’m going to try semi-randomly whacking at bits of this to see if I can get more clue as to what’s missing / wrong / not configured / broken / whatever…

    BTW, doing “emerge –sync” (the Gentoo way) seems to give the same error file.

  17. E.M.Smith says:

    Don’t know if this fixes it, or not. It claims to be how you set up to use meta-repo; yet the installed system is already trying to use it as though it thinks it is already installed.

    I think I’ll clone the chip (about a half hour) then try this;

    Using Meta-Repo
    To use meta-repo as your meta-repository for Funtoo Linux, perform the following steps on your Funtoo Linux system, as root:

    # cd /var/git
    # git clone
    # cd meta-repo
    # git submodule init
    # git submodule update
    # rm /usr/share/portage/config/repos.conf
    # mv /etc/portage/repos.conf /etc/portage/repos.conf.bak
    # mkdir /etc/portage/repos.conf
    # ln -s /var/git/meta-repo/repos.conf /etc/portage/repos.conf/funtoo
    # chown -R portage:portage /var/git/meta-repo
    At this point, you should be able to use the emerge command and use Portage normally.

  18. E.M.Smith says:

    Well, tried to do that and it looks like DNS resolution isn’t working (so did nslookup in another panel and tried it via number, no joy.)

    odroidxu4 / # cd /var/git
    odroidxu4 /var/git # ls -l
    total 0
    odroidxu4 /var/git # git clone
    Cloning into 'meta-repo'...
    fatal: unable to access '': Couldn't resolve host ''
    odroidxu4 /var/git # nslookup
    bash: nslookup: command not found
    odroidxu4 /var/git # git clone
    Cloning into 'meta-repo'...
    fatal: unable to access '': SSL: no alternative certificate subject name matches target host name ''
    odroidxu4 /var/git # 

    So also hung up on some cert stuff too.

    But ah, the joys of a chroot system. Swapping back to the parent system and doing the git there:

    ems@odroidxu4:~$ sudo bash
    [sudo] password for ems: 
    root@odroidxu4:/SG2/home/XU4/ems# cd /SD/Funtoo/var/git
    root@odroidxu4:/SD/Funtoo/var/git# git clone
    Cloning into 'meta-repo'...
    remote: Enumerating objects: 243, done.
    remote: Counting objects: 100% (243/243), done.
    remote: Compressing objects: 100% (185/185), done.
    remote: Total 13225 (delta 63), reused 236 (delta 57), pack-reused 12982
    Receiving objects: 100% (13225/13225), 1.89 MiB | 2.20 MiB/s, done.
    Resolving deltas: 100% (5800/5800), done.
    Checking connectivity... done.

    Gives me a meta-repo in the chroot system:

    odroidxu4 /var/git # ls -l
    total 4
    drwxr-xr-x 5 root root 4096 Sep 22 22:52 meta-repo

    So onward and hopefully upward…

  19. E.M.Smith says:

    Continuing that process, back on the parent:

    root@odroidxu4:/SD/Funtoo/var/git# cd meta-repo
    root@odroidxu4:/SD/Funtoo/var/git/meta-repo# git submodule init
    root@odroidxu4:/SD/Funtoo/var/git/meta-repo# git submodule update
    root@odroidxu4:/SD/Funtoo/var/git/meta-repo# ls
    metadata  README.rst  repos.conf

    and then:

    root@odroidxu4:/SD/Funtoo/var/git/meta-repo# cat README.rst

    Meta-repo is a git repository that contains all the ports trees for Funtoo
    Linux. Meta-repo also contains pointers to kits, which are functional units of
    ebuilds used by Funtoo Linux, and which are managed by Funtoo Linux’s personality
    tool, `ego`.

    Using Meta-Repo

    To use meta-repo as your meta-repository for Funtoo Linux, first make sure that
    you have not defined “PORTDIR“ in “/etc/make.conf“ to point to a specific
    Portage repository location. If you have “PORTDIR“ defined, comment it out or
    remove this line. Then, perform the following steps as root to set up a temporary
    “ego“ instance::

    # cd /var/tmp
    # git clone
    # cd ego
    # ./ego sync

    The “./ego sync“ action will create a meta-repo at “/var/git/meta-repo“, along
    with kits, and also update your “/etc/portage/repos.conf“ directory and
    “/etc/portage/make.profile/parent“ file to work with “ego“ and Funtoo Linux’s

    You can use this temporary “ego“ installation as needed until you are able to
    emerge a recent version of “ego“ directly. As long as you run the “ego“ command
    within the git repository, it should run self-hosted from the repository. Some
    functionality such as MediaWiki document retrieval (“ego doc“ and query functionality
    “ego query“) will not work without the “mwparserfromhell“ and “appi“ modules
    being installed, but “ego sync“ and “ego profile“ commands should work.

    Updating to Meta-Repo with Funtoo Containers

    If you are a Funtoo Container user, you can enable meta-repo in your container
    by making sure that you remove the “PORTDIR=/var/src/portage“
    line from “/etc/make.conf“. Then follow the steps above to clone a git master
    version of ego into “/var/tmp/ego“, but do *not* run “ego sync“ as the
    last step; instead, run this variation of the command as the last step::

    # ./ego sync –config-only

    This won’t actually update any files in meta-repo, since it’s read-only, but will
    update your local “/etc/portage/repos.conf“ directory and
    “/etc/portage/make.profile/parent“ to work with meta-repo.

    As above, you can now use the self-hosted git version of “ego“ until your
    system is fully upgraded and you have a local version of ego installed.

    Updating Meta-Repo

    From now on you will be using `ego sync` to update the Portage tree::

    # ego sync

    For read-only meta-repo configurations like the default meta-repo on Funtoo
    Containers, you can periodically use the read-only equivalent to ensure that
    any new kits are properly enabled and accounted for::

    # ego sync –config-only

    The “emerge -auDN @world“ command may be used to update your system.

    Reporting Bugs

    To report bugs or suggest improvements to meta-repo, please use the Funtoo Linux
    bug tracker at Thank you! :)


    So now I’m going back onto the chroot Funtoo to see if NOW I can get it to work (after figuring ut why the networking isn’t in the chroot?…)

  20. E.M.Smith says:

    Well, at least now “ego sync” didn’t outright die, but it does look like I need to do the rest of these steps from above too:

    # rm /usr/share/portage/config/repos.conf
    # mv /etc/portage/repos.conf /etc/portage/repos.conf.bak
    # mkdir /etc/portage/repos.conf
    # ln -s /var/git/meta-repo/repos.conf /etc/portage/repos.conf/funtoo
    # chown -R portage:portage /var/git/meta-repo

    As running “ego sync” said:

    odroidxu4 /var/git # ego sync
    Running as root user (will drop perms for sync.)
    Syncing meta-repo
    fatal: unable to access '': Couldn't resolve host ''
    Already on '1.4-release'
    Your branch is up to date with 'origin/1.4-release'.
    HEAD is now at 8275d59 kit updates
    fatal: unable to access '': Couldn't resolve host ''
    ERROR: There was an error syncing meta-repo.
    Syncing browser-kit branch 1.4-release
    Cloning into '/var/git/meta-repo/kits/browser-kit'...
    fatal: unable to access '': Couldn't resolve host ''
    ERROR: Could not clone kit 'browser-kit' into '/var/git/meta-repo/kits/browser-kit'.
    Syncing core-gl-kit branch 2.0-release
    Cloning into '/var/git/meta-repo/kits/core-gl-kit'...
    fatal: unable to access '': Couldn't resolve host ''

    Meaning my edit of /etc/resolveconf.conf to add the local name server was not enough. Perhaps after rebooting as a live system instead of a chroot….


    Updating /etc/portage/repos.conf...
    Updating profiles at /etc/portage/make.profile/parent...
    !!! Section 'browser-kit' in repos.conf has location attribute set to nonexistent directory: '/var/git/meta-repo/kits/browser-kit'
    !!! Section 'core-gl-kit' in repos.conf has location attribute set to nonexistent directory: '/var/git/meta-repo/kits/core-gl-kit'
    !!! Section 'core-hw-kit' in repos.conf has location attribute set to nonexistent directory: '/var/git/meta-repo/kits/core-hw-kit'
    !!! Section 'core-kit' in repos.conf has location attribute set to nonexistent directory: '/var/git/meta-repo/kits/core-kit'
    !!! Section 'core-server-kit' in repos.conf has location attribute set to nonexistent directory: '/var/git/meta-repo/kits/core-server-kit'
    !!! Section 'desktop-kit' in repos.conf has location attribute set to nonexistent directory: '/var/git/meta-repo/kits/desktop-kit'
    !!! Section 'dev-kit' in repos.conf has location attribute set to nonexistent directory: '/var/git/meta-repo/kits/dev-kit'
    !!! Section 'xfce-kit' in repos.conf has location attribute set to nonexistent directory: '/var/git/meta-repo/kits/xfce-kit'
    !!! Unable to parse profile: '/etc/portage/make.profile'
    !!! ParseError: Parent 'core-kit:funtoo/1.0/linux-gnu/arch/arm-32bit' not found: '/etc/portage/make.profile/parent'
    Sync successful and kits in alignment! :)
    odroidxu4 /var/git # 

    So that’s some progress. Now on to those file swaps and a try as a running system…

  21. E.M.Smith says:

    Hmmm… /usr/share/portage/config has no repos.conf file to remove. OK I guess.

    The other stuff done:

    odroidxu4 /etc/portage # ls
    make.conf  make.profile  repo.postsync.d  repos.conf  savedconfig
    odroidxu4 /etc/portage # ls repos.conf
    ego-browser-kit      ego-haskell-kit      ego-nokit
    ego-core-gl-kit      ego-java-kit         ego-perl-kit
    ego-core-hw-kit      ego-kde-kit          ego-python-kit
    ego-core-kit         ego-lang-kit         ego-python-modules-kit
    ego-core-server-kit  ego-lisp-scheme-kit  ego-qt-kit
    ego-desktop-kit      ego-llvm-kit         ego-ruby-kit
    ego-dev-kit          ego-mate-kit         ego-science-kit
    ego-editors-kit      ego-media-kit        ego-security-kit
    ego-games-kit        ego-ml-lang-kit      ego-text-kit
    ego-gnome-kit        ego-net-kit          ego-xfce-kit
    odroidxu4 /etc/portage # ls /var/git/meta-repo/repos.conf
    core-hw-kit  editors-kit  kde-kit          ml-lang-kit  python-kit    xfce-kit
    core-kit     games-kit    lang-kit         net-kit      ruby-kit      xorg-kit
    default      gnome-kit    lisp-scheme-kit  nokit        science-kit
    desktop-kit  haskell-kit  llvm-kit         perl-kit     security-kit
    dev-kit      java-kit     media-kit        php-kit      text-kit
    odroidxu4 /etc/portage # mv repos.conf OLD_repos.conf
    odroidxu4 /etc/portage # ln -s /var/git/meta-repo/repos.conf /etc/portage/repose.conf
    odroidxu4 /etc/portage # chown -R portage:portage /var/git/meta-repo
    odroidxu4 /etc/portage # 

    Ought to just leave name resolution.

    On the off chance I’m just not passing it right in the chown partition, I’m going to boot as Funtoo and try it in a live system. (Which at present has no X-windows, browser, etc. so it will be a while before I can post status updates like this…)

  22. E.M.Smith says:

    Had to do an “rcupdate add dhcpcd default”

    As listed here:

    Desktop (Wired DHCP)
    For a home desktop or workstation with wired Ethernet that will use DHCP, the simplest and most effective option to enable network connectivity is to simply add dhcpcd to the default runlevel:

    chroot # rc-update add dhcpcd default

    When you reboot, dhcpcd will run in the background and manage all network interfaces and use DHCP to acquire network addresses from a DHCP server.

    If your upstream DHCP server is dnsmasq, it can be configured to assign addresses via mac address to make servers on DHCP feasible.

    Then reboot.

    Now “ego sync” looks like it is running fine!

    It slso looks like it may take a few hours to sync then update world, and capturing that output one terminal CLI land isn’t going to happen, so not much to update here for a while.

    But if looks like I’m over the bootstrap hump!

  23. E.M.Smith says:

    Well, the update step:
    emerge -auDN @world
    Looks to be running fine. At package 25 out of 34 updated ATM.

    Mostly Python 2.7 stuff, is seems. Lots of source compiles.

    When that completes, I’ll grab another backup copy, then proceed with installing X-windows and other stuff.

    Assuming all that works, next is to take my Debian software install script and make a Funtoo version with all my preferred bits. After checking what all gets auto installed as part of a “kit”.

    Since Firefox will be one of them, and the source build can take hours (days?) on smaller machines, I’ll need to do some tuning first. Things like putting the build scratch areas on real disk and setting compile flags to 8 cores…

    The really good thing is that I’m past the undocumented ARM XU4 not like a PC parts, mostly. From here on out, the documented procedures ought to help more than hurt.

  24. E.M.Smith says:

    So the @world update completed, backup in progress.

    Looks like about 2.5 hours

  25. E.M.Smith says:

    Attempting to add x11 failed on the Funtoo guide being 100% PCI bus PC. This page looks to have XU4 video driver advice:

  26. E.M.Smith says:

    Hey, I think I may have found where Devuan archived the Jessie stuff:

  27. E.M.Smith says:

    OK, One success! I now have a local Devuan Jessie repository. So no updates happening, but at least I can install new applications.

    I made a copy of the archived sources using a wget command (in a one line script named “getdevuanarch”)

    root@odroidxu4:# bcat getdevuanarch
    wget  -np -m

    Looking inside it has .gz files, so change “deb” to “deb-src” in your /etc/apt/sources.list file.

    root@odroidxu4:/SG2/ext/Devuan_Archive//merged/dists/jessie# ls *
    index.html  InRelease  Release	Release.gpg
    binary-all    binary-hppa  binary-mipsel   binary-sparc       Contents-i386.gz	   source
    binary-alpha  binary-i386  binary-or1k	   Contents-all.gz    Contents-ppc64el.gz
    binary-amd64  binary-ia64  binary-powerpc  Contents-amd64.gz  Contents-source.gz

    And change from an http: to file: at the head end (remember that you don’t put in the full path as “jessie” is found via the release level and “dists” is assumed):

    root@odroidxu4:/# cat /etc/apt/sources.list
    # Devuan Upgrade Set (swapped to local archive)
    deb-src file:///SG2/ext/Devuan_Archive/merged jessie main contrib non-free
    #deb-src file:///SG2/ext/Devuan_Archive/merged jessie-updates main contrib non-free
    #deb-src file:///SG2/ext/Devuan_Archive/merged jessie-security main contrib non-free
    #deb-src file:///SG2/ext/Devuan_Archive/merged jessie-backports main contrib non-free

    Note that there are not updates nor security patches being made anymore, and backports was not there (on the presumption it has all been rolled in?) so those gave errors and I commented them out. My bad.

    W: Failed to fetch file:/SG2/ext/Devuan_Archive/merged/dists/jessie-backports/non-free/source/Sources  File not found

    It’s obvious they are not there when you bother to do an ls in the dists directory…

    And now update and upgrade work without error (so I assume adding a package will work…)

    root@odroidxu4:/# apt-get update
    Get:1 file: jessie InRelease [29.4 kB]
    Reading package lists... Done  
    root@odroidxu4:/# apt-get upgrade
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    Calculating upgrade... Done
    0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

    Now the good news is it looks like I’d done an update / upgrade after the archive stabilized so I wasn’t out of date with the final image. Just could not install more packages. Now I can.

    That’s about 1/2 my “issues” on the XU4 right there. Pressure reduced to find an alternative!

    Now I’m going back to a more leisurely pace of trying to get X and LXqt working on Funtoo.

  28. Pingback: Slackware on RockPro64 – Progress | Musings from the Chiefio

  29. E.M.Smith says:

    There is a prebuilt Gentoo 64 bit image for the Raspberry Pi M3:
    Complete w/ working xWindows, browser, etc.

    I’m going to give it a tty “soon”. There are also directions for making a cross build environment for ARM systems.

    Also, every board I have has had a working Gentoo ported to it:

    Part of the problem with Gentoo on arm is the slow build speed of everything from sources. With a pre-built Pi version, I can bootstrap off of my 2 x RPiM3 boards with 8 cores of distcc compile power. Then each subsequent board built, adds more cores. I can break out ofvyhe “configuing Xorg is a pain” trap…

    There are also facilities to compile the 32 bit v7 code on the 64 bit v8 OS. Though I’d be very tempted to just boot the available 32 bit Gentoo on the Pi and avoid those cross compile issues.

    So sometime tonight or tomorrow I’ll be test driving this Gentoo prebuilt image and trying out some distcc distributed builds stuff just after.

    The directions for Gentoo on the XU4 look pretty clean, and it is 8 x 32 bit cores, so would make a good 32 bit distcc main node, with the 2 x PiM2 as added compile nodes. And the Odroid C1. 20 total cores ought to build quick. Then an SD swap on the 2 x PiM3 to run them 32 bit would make a 28 core cluster right quick.

    Similarly, using the Rock64, RockPro64, 2 x Orange Pi One, Pine 64, Odroud C2, and running a 64 bit OS on the 2 x PiM3 would give a 34 core 64 bit cluster.

    I’d have to clean off my desktop to have them all set up at once, though ;-)

    It will take a while to do all that, and Gentoo is a technically challenging culture… even with one build a day, it would take 2 weeks to make them all. I think I’ll start with just the Pi stack as that Devuan 1.0 is out of date…

  30. E.M.Smith says:

    Well, that was quick. I’m typing this on my Pi M3 running the full configured Gentoo.

    It unpacks to about 13.x GB (!) so you need at least a 16 GB chip.

    The wifi and keyboard come set to UK. It does present a nice configuration panel at first boot where you can change the WiFi domain. I’ve not yet changed the keyboard…

    It is fairly fast! The Pi is actually quite usable for browsing (Chromium installed already).

    All in all, quite painless.

    With gparted open showing the disk layouts, htop running, and Chromium open with 3 tabs, memory usage is just 704 MB. and CPU is running about 1/4 nicely spread over all four CPUs.

    OK, I’m sold on Gentoo on the Raspberry Pi. Next up will be converting my other M3, and then getting a port done for the M2 and even the B+ (eventually….)

    Then, over the next few weeks, as the mood hits me, I’ll be trying to convert each of my other boards. It is VERY nice to know the same Linux, without SystemD, can run on all of them and I can get back to making the cluster computing stuff “go”.

    Note that the default passwd is “raspberrypi64” and that it doesn’t let mere mortals set passwords it doesn’t like (I.I. short or in dictionary or…) so you might need to “su root” to make that happen.

    The dropdown menu shows distcc monitor installed and “which distcc” finds it already installed in /usr/bin/distcc so it is all set up for distributed compiles. ;-)

  31. E.M.Smith says:

    I’ve finished doing the basic “move in and make ready” on the RPiM3 Gentoo. (Add users, config hosts and fstab, etc.) I’m impressed. It will play video (with working audio) in the small size of panel as in a link in a posting, but has occasional ‘stutter’ of the image. Full size it has trouble computing enough and drops to 480 lines and still has a bit of image stutter. But for occasional small image video, it’s OK.

    Moving windows and terminal windows is smooth and jitter free (something some other releases have had issues with…) so is likely using the GPU properly.

    Gparted, Chromium, etc. all work fine (I’ve not tested all of Libreoffice, but it usually has no issues anyway.)

    I’m presently making a backup copy of the chip, then will dup it onto another chip so I can try both PiM3 boxes with distcc as a “cluster of 2”. After that, I think I’m just going to be cranking out Gentoo boxes for a while. One board at a time, making them “go”.

    I’m probably going to do the Odroid boards next. I’ve got a C1, C2, N2 and XU4. It looks like all of them have been done by others so ought to be fairly clear cut. The XU4 has weirdness, but the Gentoo HowTo is pretty detailed. I may also toss the Pine64 into the mixer too. It’s not my favorite board (has no heat sink so rapidly heat slows the clock way down… but maybe it’s time to order that heat sink…) but looks like lots of OSs port to it easily. I’m going to leave the RockPro64 as Slackware “for a while” just so that if I get in trouble converting the XU4 I still have a good fast Linux workstation that plays videos nicely ;-)

    I think I’m going to emphasize Gentoo over the FreeBSD / NetBSD ports. I’ll still keep one or two of them in the pack as a “keep the skills up” and sometimes daily driver, but really, they have not been as robust in working (NetBSD and broken FireFox / no SQL) or in configuring (FreeBSD painfully non-configured Xorg). So I’m going to put more time into what IS working and hasn’t been that hard to “make go”.

    I do need to install / test / port database for the MySQL / Python / Climate DB work I did some long time ago. IF that goes well, then I’m going to deprecate all the systems / chip images that is on.

    For anyone with a Raspberry Pi M3, that “download and go” Gentoo image just works nicely right out of the chute AND all the choices the packager made have been nice ones. Even puts up some advisory panels on first boot for things like overscan, and tosses you right into the “demouser” demo account.

  32. E.M.Smith says:

    Interesting… There was “another browser” named Aurora installed. I just tried it. It is actually FireFox {and a 77.x release too, not the 52 level… so written in Rust).

    It plays video full speed in the web page (560 or 640 bit wide) size and at 480p full screen without any video jitter. That makes the Pi M3 usable for general purpose INCLUDING video!

    Oh, and the Gentoo come up in UK keyboard, but there’s a little box with “UK” in it in the upper right corner of the desktop that, if you click it, turns to US and you have a USA keyboard. Nice.

    I’m REALLY liking the choices and overall build quality of this Gentoo!

    Now I just have to show that I can “roll my own” of equal quality ;-)

  33. Simon Derricutt says:

    EM – thanks for the report. If the PiM3 works out as a good daily system, seems like not that much of a need to get anything bigger for most people. The majority of the work I do these days just needs a competent browser, and occasional use of GIMP. For simulations etc. I can fire up the other boxes when needed.

  34. E.M.Smith says:


    The Pi M3 still has modest / slow disk speeds on USB. A copy of a 16 GB SD chip to my backup disk (that’s USB 3.0 capable) goes about 8 times faster on my boards with USB 3.0 ports.

    The browser also starts to roll out to swap with multiple tabs open (I’m a tab hog and use lots of them) so my 2 GB memory boards handle that a little better

    So all in all I like the RockPro64 and Odroid XU4 better. Then again, at about double the cost they ought to be better ;-)

    The Pi M3 / Gentoo is certainly adequate. I don’t feel like I’m prevented from doing anything on them. Just once or twice something pauses for a second as the hard disk swap spins up (yes, I moved swap to real disk to reduce uSD card wear) or a page loads in the browser.

    Oddly, the CPU is usually NOT fully loaded then. It’s the I/O subsystem that’s limiting then. I might just get a small Class 10 ultra SD card in a USB adapter and put swap on it to see what happens. I could see “burning” a $10 card every year or three as fast direct access swap…

    Actually, thinking about it, I have a class 10 with Centos on it from some years back, but for the intel machine in the corner I’ve not used in 3 years… It’s full sized SD so doesn’t fit my SBCs (other than the old model B+ that already has a card…). It would be pretty easy to just store the image from it (or toss it…) and do the test….

    Back in a bit? ;-)

    FWIW, I found the Rock64 that is nominally about the same CPU as the Pi M3, to be noticeably faster / snappier, likely due to the memory and USB 3.0 stuff. And not that much more money.

    I’d only chucked it in a box for a few years due to the “SystemD fstab Blank Screen Boot Bug”, where making an fstab entry of “noauto, 0 0” meant if the disk were absent your boot would just fail and give you a black screen causing it to seem like a dead board. Made me glade I’m an electronics pack rate when later I tried it with an entirely different OS and it just worked again. (Had the same issue with the Odroid C2 and another board. IIRC the XU4 was where I finally figured it out. I had an old non-SystemD OS chip and the upgrade to System D was done on a new chip. After fiddling some fstab settings, it “died”, yet the old chip worked.

    Once the penny dropped on what was happening, I went back to the old boards, made sure all disks were plugged in OR the fstab entry was commented out, and suddenly they worked again.

    That was the moment my dislike of SystemD turned into resolve to remove it from my shop as much as possible. A perfectly valid /etc/fstab entry ought not cause apparent complete failure to boot with no messages and no screen to log in and fix it.

    Well, I was going to play with swap on SD card…

  35. E.M.Smith says:


    What I thought would be a quick little experiment with swap turned into a very long OMG! WTF? process…

    I launched both Chromium and Firefox at the same time to generate a lot of swap activity. Firefox alone will cause about 300 MB of swap use with a 1/2 dozen typical tabs open. I opened a few more and got to about 450. Then Chromium had it rising past 600.

    Then at about 671 MB of swap, something very important to the kernel or OS got swapped out and the system just froze.

    Normally, you expect that kind of hang with NO swap and you run out of physical memory, OR with massive swap like 4 to 6 times physical memory. This was about 67% of physical memory. “Normal” allocation advice for swap is 1 or 2 x phys mem. That’s way low to be having a freeze.

    So, OK. I repeated the experiment. With physical disk. With only ONE disk. With only ONE partition. With only one SD card in USB adaptor. With “sleep 3600; halt” to try to get it to auto shutdown if my terminal was hung but background processes were still running (it didn’t…)

    So “something” in this fairly new 64 bit Gentoo is not staying memory resident when it ought. OK…

    So I’m going to make a ‘special” swap of 600 MB and use only that. (Then we’ll find out if running out of swap also crashes things…)

    In the mean time, this particular Gentoo is NOT for things that beat swap to death.

    Per the Pi:

    IIRC, it shares a channel for both the network device and the USB disks. That saturates fairly early on things like browsers that do both. Lots of red “D” disk wait symbols in “htop” display.

    So the Pi M3 is suited to running ONE browser with not too many tabs open at once (stay below 600 MB swap…) and with a willingness for some things to load slowly as cached tabs (disk) and new tabs (network) are fighting over the one interface chip… Liveable, but not lovable.

    Good for emergency use, when you don’t want to set up something else and this is already running, for kids, or for folks on a very tiny budget. Not so good for a College Kid looking to impress his or her friends… and spending $100 for a party that would instead get them a very nice 6 or 8 core 2 GHz SBC with 2 GB to 4 GB of memory instead.

    I’m also going to need to watch big compile jobs as they can “saturate memory” pretty quickly if you set -j job number high.

    With that, I’m done crashing the Pi for a while and I’m going back to getting Gentoo running on some other bit of hardware (where I’ll then find out if it too has the “crash on high swap” issue…)

  36. E.M.Smith says:

    FWIW, my guess is a device driver or other module and that a monolithic kernel build would prevent the swap crash. I had the problem on some other Linux about a decade ago… Every so often it shows up again.

    My guess is also that the folks doing builds don’t have an experienced QA Manager abusing their systems to find where it breaks. At one time, I was the QA manager for a company making Linux compilers. My job as I saw it, was to stress test things until they broke. How else can you say if it is a normal failure, or not? Ideally the code would not break, but admonish me not to do stupid stuff. Far too often it silently failed.

    So now you know why I do things like open TWO browsers at once with multiple tabs and video running in one of them. Because somewhere, someone, will do just that….

  37. E.M.Smith says:

    Well, as of now, I’m running Gentoo in a chroot on the XU4. I basically followed the directions here:

    With some minor convenience changes along the way. (Nothing structural, just things like mount point names). The current tarball to retrieve is:

    so in the wget you need to change to that (or whatever is current when you read this). I just went to the http site and read what was there:

    [PARENTDIR] Parent Directory –
    [ ] stage3-armv4tl-20200509T210605Z.tar.xz 2020-05-11 22:15 181M
    [ ] stage3-armv4tl-20200509T210605Z.tar.xz.CONTENTS.gz 2020-05-11 22:15 614K
    [ ] stage3-armv4tl-20200509T210605Z.tar.xz.DIGESTS 2020-05-11 22:15 758
    [TXT] stage3-armv4tl-20200509T210605Z.tar.xz.DIGESTS.asc 2020-05-11 22:41 1.3K
    [ ] stage3-armv5tel-20200509T210605Z.tar.xz 2020-05-11 22:18 180M
    [ ] stage3-armv5tel-20200509T210605Z.tar.xz.CONTENTS.gz 2020-05-11 22:18 611K
    [ ] stage3-armv5tel-20200509T210605Z.tar.xz.DIGESTS 2020-05-11 22:18 762
    [TXT] stage3-armv5tel-20200509T210605Z.tar.xz.DIGESTS.asc 2020-05-11 22:41 1.3K
    [ ] stage3-armv6j_hardfp-20200509T210605Z.tar.xz 2020-05-11 22:21 180M
    [ ] stage3-armv6j_hardfp-20200509T210605Z.tar.xz.CONTENTS.gz 2020-05-11 22:21 614K
    [ ] stage3-armv6j_hardfp-20200509T210605Z.tar.xz.DIGESTS 2020-05-11 22:21 782
    [TXT] stage3-armv6j_hardfp-20200509T210605Z.tar.xz.DIGESTS.asc 2020-05-11 22:41 1.3K
    [ ] stage3-armv7a_hardfp-20200509T210605Z.tar.xz 2020-05-11 22:24 179M

    [ ] stage3-armv7a_hardfp-20200509T210605Z.tar.xz.CONTENTS.gz 2020-05-11 22:24 611K
    [ ] stage3-armv7a_hardfp-20200509T210605Z.tar.xz.DIGESTS 2020-05-11 22:24 782
    [TXT] stage3-armv7a_hardfp-20200509T210605Z.tar.xz.DIGESTS.asc 2020-05-11 22:41 1.3K

    I didn’t create a clone of my existing XU4 OS chip, just backed it up to hard disk as a dd copy. Then I just put Gentoo in a partition on that chip. Also, I didn’t do long hand partition management, but used ‘gparted’ as it is just incredibly easier.

    Finally, the fetch of the tarball, the unxz of it, and the untar were all done on the Raspberry Pi M3 as it was what was running at the time. I then booted the XU4 in Armbian / Devuan uplift.

    To copy over the X11 directory, my mount point was /SD/Gentoo instead of /mnt so my command was: cp -L /etc/X11 /SD/Gentoo/etc

    Similarly, the other commands mount point changed:

    root@odroidxu4:/# mount /SD/Gentoo
    root@odroidxu4:/# mount -t proc none /SD/Gentoo/proc
    root@odroidxu4:/# mount --rbind /sys /SD/Gentoo/sys
    root@odroidxu4:/# mount --rbind /dev /SD/Gentoo/dev
    root@odroidxu4:/# cp -L /etc/resolv.conf /SD/Gentoo/etc
    root@odroidxu4:/# chroot /SD/Gentoo /bin/bash
    odroidxu4 / # 

    The “cp -L” says to follow symbolic links (i.e. don’t just do a link)

    So now I’m chrooted into a running Gentoo on the XU4. Next up is all the various config and build stuff, but that’s likely to take a long time…

    root #env-update (might fail without the portage snapshot)
    root #source /etc/profile
    Get a Portage snapshot

    We need to get the Portage snapshot, before we can do this we must set the date (emerge-webrsync didn’t work on my machine for some reason):
    root #date MMDDHHMMYYYY
    root #cd /usr
    root #wget
    root #tar -xvjf portage-latest.tar.bz2
    root #emerge –sync
    root #rm portage-latest.tar.bz2
    Set up make.conf

    Before we do anything we must alter the make.config file, if we don’t compilations will take a long time on a single arm core. Be sure to add makeopts=”-j9”. Use flags are up to you, for the purpose of this guide I kept them as small as possible. Future experimentation would be switching -march=armv7-a to native, though that will cause problems for distcc, but that’s for another guide.
    root #nano /etc/portage/make.conf
    CODE make.config sample/

    Eventually I’ll be able to boot it directly, and for that I’ll need to change the target of the /boot/boot.ini file. Here’s what I’d done for a similar boot of Funtoo:

    cat boot.ini
    setenv rootdev "UUID=dc9477cd-d43d-4082-82af-1cfadc352727"
    # Comment out the above and uncomment the below to use Funtoo
    #setenv rootdev "LABEL=SD_Funtoo"

    So now I’ll just change “LABEL=SD_Funtoo” to “LABEL=SD_Gentoo”. (Yes, UUID would be guaranteed unique, but LABEL works just fine too…)

    More when I get to the just booting it up Gentoo stage ;-)

  38. E.M.Smith says:

    At the end of the “emerge -sync” is said to update the portage stuff, so I am:

    * IMPORTANT: 9 news items need reading for repository 'gentoo'.
     * Use eselect news read to view new items.
    Action: sync for repo: gentoo, returned code = 0
     * An update to portage is available. It is _highly_ recommended
     * that you update portage now, before any other packages are updated.
     * To update portage, run 'emerge --oneshot sys-apps/portage' now.
    odroidxu4 /usr # emerge --oneshot sys-apps/portage 
  39. E.M.Smith says:

    Well that took a while, and compiled a LOT of stuff. It also threw a lot of “locale” warnings like:

    /var/tmp/portage/dev-python/chardet-3.0.4-r1/temp/environment: line 79: warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF-8)

    I’m hopeful that:
    A) As a warning it doesn’t matter. And
    B) I can figure out how to fix it
    C) It looks like it is defaulting to USA which is what I want anyway

    This looks promising:

  40. E.M.Smith says:

    emerge vim
    has let me get the “vi” editor that my fingers know. Now I can stop using the horrid “nano” that uses CTL-{Letter} to do things… Yes, it is nice tor folks who do not know any Unix editor. OTOH, for anyone who’s fingers have been doing “vi” for 40 years, it’s a slothful thing that keeps erroring on the instinctive vi finger strokes…

    But it is done now. Now I can try editing the “locale” stuff before finishing the install stuff per the script.

    It would likely be better to have set the “locale” stuff before the portage update.

  41. E.M.Smith says:

    OK, I think I got “locale” fixed, but I’m not sure what all did it. On the thesis it was the LAST thing tried:

    The /etc/locale.gen file had all options commented out. I “uncommented” the 2nd one, but that wasn’t enough. Uncommenting both US ones seems to have worked:

    odroidxu4 /etc # cat locale.gen
    # /etc/locale.gen: list all of the locales you want to have on your system.
    # See the locale.gen(5) man page for more details.
    # The format of each line:
    # Where  starts with a name as found in /usr/share/i18n/locales/.
    # It must be unique in the file as it is used as the key to locale variables.
    # For non-default encodings, the  is typically appended.
    # Where  is a charset located in /usr/share/i18n/charmaps/ (sans any
    # suffix like ".gz").
    # All blank lines and lines starting with # are ignored.
    # For the default list of supported combinations, see the file:
    # /usr/share/i18n/SUPPORTED
    # Whenever glibc is emerged, the locales listed here will be automatically
    # rebuilt for you.  After updating this file, you can simply run `locale-gen`
    # yourself instead of re-emerging glibc.
    en_US ISO-8859-1
    en_US.UTF-8 UTF-8
    #ja_JP.EUC-JP EUC-JP
    #ja_JP.UTF-8 UTF-8
    #ja_JP EUC-JP
    #en_HK ISO-8859-1
    #en_PH ISO-8859-1
    #de_DE ISO-8859-1
    #de_DE@euro ISO-8859-15
    #es_MX ISO-8859-1
    #fa_IR UTF-8
    #fr_FR ISO-8859-1
    #fr_FR@euro ISO-8859-15
    #it_IT ISO-8859-1

    Prior to that, on advice of another plaintiff, I added LC_ALL=”” to /etc/env.d/02locale

    odroidxu4 /etc # cat env.d/02locale 

    IIRC I’d added the LANG= and LC_COLLATE= earlier. None of these seemed to fix it, but might have been necessary precursor steps.

    I then did a “locale-gen”

    odroidxu4 /etc # locale-gen
     * Generating 3 locales (this might take a while) with 8 jobs
     *  (1/3) Generating en_US.ISO-8859-1 ...                                                                                                                                  [ ok ]
     *  (3/3) Generating C.UTF-8 ...                                                                                                                                           [ ok ]
     *  (2/3) Generating en_US.UTF-8 ...                                                                                                                                       [ ok ]
     * Generation complete
     * Adding locales to archive ...  

    And now it looks fixed. We’ll see if the warnings are gone on future emerge commands / builds.

    odroidxu4 /etc # locale

    This whole ‘locale’ stuff could really use a massive simplification. Just put your country code in one file and have everything else default (but over-rides manually available for someone who needs it…)

    Oh Well.

  42. E.M.Smith says:

    The next “emerge –sync” seems superfluous to me, but I did it anyway. It appeared to sit there doing nothing after an opening stanza of stuff, and I thought to killing it… BUT, some sloth at the keyboard convinced me something must be happening. Some “Long Time Later” (after sushi dinner and 1/2 bottle of sake) is appears to have completed.

    So, just realize that from this point on, there are long slow things that don’t talk to you a lot…

  43. E.M.Smith says:

    Well, the @world step runs for about 1/2 a day… It completed some time in the last 4 hours, but there were a couple of errors. At the very end is:

    >>> Failed to emerge dev-lang/python-3.8.5, Log file:
    >>>  '/var/tmp/portage/dev-lang/python-3.8.5/temp/build.log'
     * Messages for package sys-libs/timezone-data-2020a:
     * You do not have TIMEZONE set in /etc/timezone.
     * Skipping auto-update of /etc/localtime.

    So, OK, I need to set a timezone and I need to try re-making python. Looks like I also need to dig through the log files and see what else might have failed.

    During my spot checks (during dinner and into the evening up until about 5 hours ago when I hit the sack) it looked like everything was cooking along without failures. It would often saturate all 8 cores with gcc compile jobs. In the Gentoo wiki on the Odroid XU4 it says to put “-j 8” in the config (so run up to 8 jobs at once when compiling) yet says a couple of times to only put “-j 3” in the config file as more tends to “saturate memory”. My interpretation was that the “-j 3” was only when doing a kernel build, so I used “-j 8” , and everything seemed fine.

    OK, what I’m going to do now is shut down the XU4, and make a backup copy of the chip. At this point I’ve got about 24 hours of serious compute crunching invested in it and it isn’t backed up. Then I’m going to contemplate log files over morning coffee, and after that proceed with the rest of the procedure. It is highly likely that I have a working system even if some of the @world packages failed to update when I did the “emerge –update –deep –newuse @world “.

    The next three steps are all about cleaning out things no longer needed:

    root #emerge --depclean
    root #emerge -a app-portage/gentoolkit (needed for revdep-rebuild)
    root #revdep-rebuild 

    then adding the portage ‘gentoolkit’ to kernel generation. The revdep-rebuild does a reverse dependencies search and tries to figure out what bits depend on other bits to make sure it’s all there. Once all that is done, one is told to build a kernel. At that point I’ll likely change the config file to “-j 3” in keeping with my thesis about the conflicting directions. Worst case is that it takes a bit longer to build a kernel and I’ve got more cores left for me to use in the browser et. al. while the build runs ( I’ll change it back to -j 9 after the kernel build).

    I can see where doing this on a Raspberry Pi would be a real challenge. The XU4 has 8 cores, with 1/2 of them being much faster, plus 2 GB of memory. My guess is that you would take about 4 to 10 times as long as a R. Pi M4, or a couple of days, just for the @world step. Cross compilation from a faster machine or using distcc across several would really matter a lot. (Or just download and go with the prebuilt image like I did ;-)

    OK, enough of that. Time to shut down, start the backup, and go make coffee ;-)

  44. E.M.Smith says:

    Looks like how to set timezone et. al is here:
    and here:

    so I’m using UTC:

    odroidxu4 /etc # cat /etc/timezone
    cat: /etc/timezone: No such file or directory
    odroidxu4 /etc # ls -l /etc/time*
    ls: cannot access '/etc/time*': No such file or directory
    odroidxu4 /etc # echo "UTC" > /etc/timezone
    odroidxu4 /etc # cat /etc/timezone

    and it seems to have worked:

    odroidxu4 /etc # emerge --config sys-libs/timezone-data
    Configuring pkg...
     * Updating /etc/localtime with /usr/share/zoneinfo/UTC

    I may try a re-make of that Python package before doing the backup copy… but I’ll decide that AFTER that first cup-o-coffee ;-)

  45. E.M.Smith says:

    OK, coffee in hand, I did a simple check:

    odroidxu4 /etc # which python3

    So I do have an installed python3 and the failed “emerge of dev-lang/python-3.8.5” ought not prevent the system from running. At most, the existing python3 might be back rev a little bit and that ought not cause any issues as minor revs are supposed to be compatible.

    With that, time to start the backup, finish sucking on the coffee, and catch up on the morning news…

  46. E.M.Smith says:

    Well, the –depclean and related steps went very fast. I’ve now done all three of these:

    root #emerge --depclean
    root #emerge -a app-portage/gentoolkit (needed for revdep-rebuild)
    root #revdep-rebuild 

    This is the end of the install of gentoolkit and then running revdep-rebuild to assure all packages are consistent in their dependencies:

     * Messages for package app-portage/gentoolkit-0.5.0:
     * For further information on gentoolkit, please read the gentoolkit
     * guide:
     * Another alternative to equery is app-portage/portage-utils
     * Additional tools that may be of interest:
     *     app-admin/eclean-kernel
     *     app-portage/diffmask
     *     app-portage/flaggie
     *     app-portage/install-mask
     *     app-portage/portpeek
     *     app-portage/smart-live-rebuild
    >>> Auto-cleaning packages...
    >>> No outdated packages were found on your system.
     * GNU info directory index is up-to-date.
     * IMPORTANT: 9 news items need reading for repository 'gentoo'.
     * Use eselect news read to view new items.
    odroidxu4 / # revdep-rebuild
     * This is the new python coded version
     * Please report any bugs found using it.
     * The original revdep-rebuild script is installed as
     * Please file bugs at:
     * Collecting system binaries and libraries
     * Checking dynamic linking consistency
    Your system is consistent
    odroidxu4 / # 

    So looks like the next step is building a kernel…

    I could make this bootable as-is with some potential for library conflicts in a manner similar to what was done for Funtoo. Just copy over the kernel modules and headers and use the existing kernel. I’m going to follow the script and build a new kernel anyway (despite the long build time probable and the more complex changes to boot.ini). It’s just more “correct” to have a kernel built for your system on your system with your system… and once done, that system image is no longer tied to any other build / system / libraries etc.

    This is likely to take a while, so I may not say much on Gentoo until it is done. Today? Tomorrow? Who knows how long a kernel build takes on this machine… OTOH:

    Build the kernel

    Time to compile the kernel, unfortunately the official gentoo sources do not work for the odroid-xu4 SoC. If one tries to compile with gentoo-sources and configure the XU4 to boot, it will fail. If one tries to boot the XU4 with a non-gentoo kernel/different config, the system will boot however there will be problems(network interfaces not being detected for example). What needs to happen is one must git clone hardkernel’s official kernel and then compile it with any features one might want. There are 2 ways to do this, manual and automatically with genkernel. Below is how to do it with genkernel.

    Ensure that partitions are correctly mapped:

    root #nano /etc/fstab
    root #mount /dev/mmcblk1p1 /boot

    Unfortunately, they don’t say what “correctly mapped” means. I’m going to assume it means you know were /boot is located and boot.ini in it. But… some think time required…

    This next bit looks like I need to check things are installed or install them (with emerge FOO) for a few things. Then the dance of the kernel sources begins…

    Verify dev-vcs/git and sys-devel/bc are installed so that the next steps can operated as expected. Emerge the packages if necessary.

    For the 1st time:
    root #cd /usr/src
    root #git clone -b odroidxu4-4.14.y –depth 1 odroidxu4-4.14.y
    root #ln -s odroidxu4-4.14.y linux

    Followed by from now and future updates from the git tree:
    root #mount /dev/mmcblk0p1 /boot
    root #cd /usr/src/odroidxu4-4.14.y/
    root #git pull # simply put, it synchronizes the local with the remote repository;
    root #cd ..
    root #genkernel –kernel-config=/usr/src/linux/arch/arm/configs/odroidxu4_defconfig all

    You will then need the dev-embedded/u-boot-tools to create a uInitrd from the current initramfs, once all the files are created, let’s copy all of them to /boot
    root #cd /usr/src/odroidxu4-4.14.y/
    root #mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -d /boot/initramfs-genkernel-arm-`make kernelrelease` uInitrd-`make kernelrelease`
    root #cp arch/arm/boot/zImage /boot/zImage-`make kernelrelease`
    root #cp arch/arm/boot/dts/exynos5422-odroidxu4.dtb uInitrd-`make kernelrelease` /boot

    Remember the value returned by make kernelrelease you will need to adjust the file names in the boot.ini

    Once that actually completes successfully, then the whole adjust boot.ini and reboot stuff happens. So, OK, maybe after a bit of a think, some checking installed tools exist, and breakfast. Doing an alien kernel build on coffee only is probably not a good idea ;-)

  47. E.M.Smith says:

    OK, not as long to next comment as I expected ;-)

    First off, vi is giving me unreadable colored text. The dark blue of “comments” against black is impossible to read. So how to turn off that? Put “syntax off” in your .vimrc file.

    Second, why the ‘fstab is right’ and what IS right? Seems default /etc/fstab is just all example comments:

    odroidxu4 / # cat /etc/fstab
    # /etc/fstab: static file system information.
    # noatime turns off atimes for increased performance (atimes normally aren't 
    # needed); notail increases performance of ReiserFS (at the expense of storage 
    # efficiency).  It's safe to drop the noatime options if you want and to 
    # switch between notail / tail freely.
    # The root filesystem should have a pass number of either 0 or 1.
    # All other filesystems should have a pass number of 0 or greater than 1.
    # See the manpage fstab(5) for more information.
    # NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
    # NOTE: Even though we list ext4 as the type here, it will work with ext2/ext3
    #       filesystems.  This just tells the kernel to use the ext4 driver.
    # NOTE: You can use full paths to devices like /dev/sda3, but it is often
    #       more reliable to use filesystem labels or UUIDs. See your filesystem
    #       documentation for details on setting a label. To obtain the UUID, use
    #       the blkid(8) command.
    #LABEL=boot		/boot		ext4		noauto,noatime	1 2
    #UUID=58e72203-57d1-4497-81ad-97655bd56494		/		ext4		noatime		0 1
    #LABEL=swap		none		swap		sw		0 0
    #/dev/cdrom		/mnt/cdrom	auto		noauto,ro	0 0

    So what they are really saying is “Make an /etc/fstab that matches your system”…

    OK, back to breakfast making ;-)

  48. p.g.sharrow says:

    @EMSmith; I am sure glad it is you doing this and not me. Just reading all that gives me a headache. I think going out into the wood yard and splitting the winter supply of firewood sounds like more fun, 8-) A bit smoky here so we are, hanging out, inside with the Airwashers as much as possible.
    Just listening to the MSM reporters complaining about the Doctors report on President Trump’s condition. I would guess that they were hoping to hear that he was dieing from the Covid. Sounds like these Doctors are following the “Approved” use of Resmedvier instead of something that might actually work, but, at least also using antibodies from blood donors.

  49. E.M.Smith says:

    They have you put /boot in a FAT partition in mmcblk1p0 but my Armbian just has it as part of the root ext4 partition. I’m going to try leaving it that way, avoiding the FAT boot style.

    To that end, I’ve copied the Armbian /boot into the /SD/Gentoo /boot (that was empty) and will just build with that as the /boot target.

    I’m guessing it will be fine. If not, I’ll have to move stuff around on the SD card to make room for a FAT /boot partition…

    root@odroidxu4:/boot# cp -r . /SD/Gentoo/boot
    root@odroidxu4:/boot# ls -l /SD/Gentoo/boot
    total 17296
    -rw-r--r-- 1 root root    1557 Oct  3 09:13 armbian_first_run.txt
    -rw-r--r-- 1 root root   38518 Oct  3 09:13 boot.bmp
    -rw-r--r-- 1 root root    4882 Oct  3 09:13 boot-desktop.png
    -rw-r--r-- 1 root root   10267 Oct  3 09:13 boot.ini
    -rw-r--r-- 1 root root  151605 Oct  3 09:13 config-4.14.133-odroidxu4
    lrwxrwxrwx 1 root root      22 Oct  3 09:13 dtb -> dtb-4.14.133-odroidxu4
    drwxr-xr-x 2 root root    4096 Oct  3 09:13 dtb-4.14.133-odroidxu4
    drwxr-xr-x 2 root root    4096 Oct  3 09:13 dtb-4.14.94-odroidxu4
    drwxr-xr-x 2 root root    4096 Oct  3 09:13 dtb-4.9.61-odroidxu4
    lrwxrwxrwx 1 root root      22 Oct  3 09:13 dtb.old -> dtb-4.14.127-odroidxu4
    -rw-r--r-- 1 root root 4649272 Oct  3 09:13 initrd.img-4.14.133-odroidxu4
    -rw-r--r-- 1 root root 2390898 Oct  3 09:13
    lrwxrwxrwx 1 root root      26 Oct  3 09:13 uInitrd -> uInitrd-4.14.133-odroidxu4
    -rw-r--r-- 1 root root 4649336 Oct  3 09:13 uInitrd-4.14.133-odroidxu4
    -rwxr-xr-x 1 root root 5732424 Oct  3 09:13 vmlinuz-4.14.133-odroidxu4
    lrwxrwxrwx 1 root root      26 Oct  3 09:13 zImage -> vmlinuz-4.14.133-odroidxu4
    root@odroidxu4:/boot# du -s /boot /SD/Gentoo/boot
    18896	/boot
    19000	/SD/Gentoo/boot

    As usual “We’ll see”…

  50. E.M.Smith says:

    Not git or bc installed, so need to install them. I tossed in ‘htop’ too for monitoring activity on the chroot “machine” instead of just on the outer real machine:

    odroidxu4 / # which git
    which: no git in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
    odroidxu4 / # which bc
    which: no bc in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)

    So did:

    odroidxu4 / # emerge dev-vcs/git
    {longish process with many compile steps happens...}
    odroidxu4 / # emerge htop
    {short fast install happens|
    odroidxu4 / # emerge sys-devel/bc
    {medium short install happens}
  51. E.M.Smith says:

    The fetch of kernel sources took a little while (10? minutes?) but all in I/O waits on the transfer from what I saw (i.e. long distance internet slowest link)

    I’m using /boot in the file system itself, so skip the following mount. (It will complicate the first multi-boot in that the Armbian boot.ini in partition 1 will need to be appropriate, then gets overlain with the one from the Gentoo partition, but when I copy this Gentoo partition to partition 1 of a new SD card, later, it will simplify that).

    root #mount /dev/mmcblk0p1 /boot
    root #cd /usr/src/odroidxu4-4.14.y/
    root #git pull # simply put, it synchronizes the local with the remote repository;
    root #cd ..
    root #genkernel --kernel-config=/usr/src/linux/arch/arm/configs/odroidxu4_defconfig all 

    So I’ll do the cd, and the “git pull”, then it’s off to the actual genkernel. and most likely a long wait. Oh, and I need to drop to “-j 3” in the config file… /etc/portage/make.conf

  52. E.M.Smith says:

    Well, this is a disappointment… First off, “genkernel” is missing. Then, attempting to install it “has issues”:

    odroidxu4 /usr/src/odroidxu4-4.14.y # emerge genkernel
     * IMPORTANT: 9 news items need reading for repository 'gentoo'.
     * Use eselect news read to view new items.
    Calculating dependencies... done!
    [ebuild  N     ] app-arch/cpio-2.12-r1  USE="nls" 
    [ebuild  N     ] sys-devel/autoconf-archive-2019.01.06 
    [ebuild  N     ] sys-kernel/linux-firmware-20200918  USE="redistributable (-initramfs) -savedconfig (-unknown-license)" 
    [ebuild  N     ] sys-kernel/genkernel-4.1.2-r3  USE="firmware (-ibm)" 
    The following license changes are necessary to proceed:
     (see "package.license" in the portage(5) man page for more details)
    # required by sys-kernel/genkernel-4.1.2-r3::gentoo[firmware]
    # required by genkernel (argument)
    =sys-kernel/linux-firmware-20200918 linux-fw-redistributable no-source-code
    Use --autounmask-write to write changes to config files (honoring
    CONFIG_PROTECT). Carefully examine the list of proposed changes,
    paying special attention to mask or keyword changes that may expose
    experimental or unstable packages.
    odroidxu4 /usr/src/odroidxu4-4.14.y # 

    In the original, the stuff after USE=” is in red” and so is “license changes”.

    My guess is that now I get to go “dig here” on setting USE flags and how to deal with whatever that “license” issue might be. In any case, I still don’t have a “genkernel”:

    odroidxu4 /usr/src/odroidxu4-4.14.y # which genkernel
    which: no genkernel in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)

    IF this takes too long (ie. I’m too slow…) to figure out, I’ll likely just do it the Funtoo way. Copy over the kernel modules and firmware directories and boot off the Armbian kernel for a test run.

    In any case, again, I’m off for a bit of a think and some reading.

    Hopefully this running story of my experience with the Gentoo XU4 process will at least be amusing for others (and helpful notes for me some years on when I decide to try something like this again ;-)

  53. E.M.Smith says:

    OK, copied over /lib/modules and /lib/firmware from the Armbian partition to the Gentoo partition, changed boot.ini in partition one (Armbian slice) to point / at LABLE=SD_Gentoo and rebooted. Took about 2 minutes.

    I now have a booted, running, native Gentoo on XU4. “Someday” I’ll need to sort out “genkernel” and finish building the kernel on Gentoo. But for now, I can bypass that hurdle and continue with installing things like a windowing system, XFCE or LXQt, Libreoffice, GIMP, etc.

    At present, I’m logged in as root at a command line terminal. So it is working.

    I think I’m going to make another backup copy and take a news break… then learn more about USE flags, genkernel,

  54. E.M.Smith says:

    Well… went to install a package and found that networking isn’t working. OK…

    So I’m back running Gentoo in a chroot as I add things. So now 2 things on the todo list. Fix networking (that will be easier once install the networking tools bundle) and X11 / windows can then be installed; plus that kernel build “someday”.

    I’m continuing to follow (more or less ;-) the Gentoo guide at:

    Note that “layman” is an overlay manager for the Gentoo build system. The argument is an CAPITAL S for “sync all”, if you use a lower case “s” it complains that it wanted an argument (of ALL)…

    odroidxu4 / # emerge -vD --quiet-build layman && layman -S && layman -a hossie
     * IMPORTANT: 9 news items need reading for repository 'gentoo'.
     * Use eselect news read to view new items.
    These are the packages that would be merged, in order:
    Calculating dependencies... done!
    [ebuild   R    ] app-portage/layman-2.4.3::gentoo  USE="git -cvs (-darcs) (-g-sorcery) -gpg -mercurial -sqlite -squashfs -subversion -sync-plugin-portage -test" PYTHON_TARGETS="python3_7 -python3_6 -python3_8" 0 KiB
    Total: 1 package (1 reinstall), Size of downloads: 0 KiB
    >>> Verifying ebuild manifests
    >>> Running pre-merge checks for app-portage/layman-2.4.3
    >>> Emerging (1 of 1) app-portage/layman-2.4.3::gentoo
    >>> Installing (1 of 1) app-portage/layman-2.4.3::gentoo
    >>> Jobs: 1 of 1 complete                           Load avg: 1.07, 0.66, 0.37
    >>> Auto-cleaning packages...
    >>> No outdated packages were found on your system.
     * GNU info directory index is up-to-date.
     * IMPORTANT: 9 news items need reading for repository 'gentoo'.
     * Use eselect news read to view new items.
     * Fetching remote list...
     * Warning: an installed db file was not found at: ['/var/lib/layman/cache_930c3ed4a5f89f74fd810585751a06e3.xml']
     * Fetch Ok
     * Syncing selected overlay(s)...
     * Adding overlay...
     * Overlay "hossie" is not official. Continue installing? [y/n]: y
     * Running Git... # ( cd /var/lib/layman  && /usr/bin/git clone /var/lib/layman/hossie )
    Cloning into '/var/lib/layman/hossie'...
    remote: Enumerating objects: 821, done.
    remote: Counting objects: 100% (821/821), done.
    remote: Compressing objects: 100% (785/785), done.
    remote: Total 4885 (delta 338), reused 0 (delta 0)
    Receiving objects: 100% (4885/4885), 1.13 MiB | 1.02 MiB/s, done.
    Resolving deltas: 100% (2266/2266), done.
     * Running Git... # ( cd /var/lib/layman/hossie  && /usr/bin/git config "layman" )
     * Running Git... # ( cd /var/lib/layman/hossie  && /usr/bin/git config "layman@localhost" )
     * Successfully added overlay(s) hossie.

    But the next line puts me back in Portage Odd Stuff land with “masking” issues (whatever they are) to sort out:

    odroidxu4 / # emerge -vuDN --quiet-build x11-drivers/xf86-video-armsoc
     * IMPORTANT: 9 news items need reading for repository 'gentoo'.
     * Use eselect news read to view new items.
    These are the packages that would be merged, in order:
    Calculating dependencies... done!
    !!! All ebuilds that could satisfy "x11-drivers/xf86-video-armsoc" have been masked.
    !!! One of the following masked packages is required to complete your request:
    - x11-drivers/xf86-video-armsoc-1.4.1::hossie (masked by: ~arm keyword)
    For more information, see the MASKED PACKAGES section in the emerge
    man page or refer to the Gentoo Handbook.

    The page then goes on to say how to make networking go in an OpenRC world:

    odroidxu4 /etc/init.d # ln -s net.lo net.eth0
    odroidxu4 /etc/init.d # rc-update add net.eth0 default
     * service net.eth0 added to runlevel default
    odroidxu4 /etc/init.d # rc-update add sshd default
     * service sshd added to runlevel default

    so I’ll boot up again and see if that worked…

    I already have an /etc/resolv.conf set, so don’t need to re-do that step.

    And I’ve got the “Q” Quiet version of the XU4 without a fan, just a really big heat sink, so I can ignore the fan control stuff.

    Which puts me at the end of the script.

    IFF the networking is now working, then “when” I get the video driver masking sorted, I can then do “all the usual” as it says:

    Emerge all xorg/X11 stuff according to the usual Gentoo_Handbook at

    and maybe, just maybe, get more than a CLI interface…

  55. E.M.Smith says:

    Hooray! Hoorah! I have network working in native Gentoo boot!

    That puts me at the end of the linked page guide. So I’m basically done with the cook book for now.

    I have a booted, working, up to date Gentoo running on the Odroid XU4.

    It does not yet have a windowing system installed. It needs a native kernel build. I need to load a lot of added software. Then, the biggie, I need to learn about their package manager and build system. Masking, USE flags, and more.

    Not ready to be my daily driver, but far enough along to join a distcc cluster for builds, and can add software in native boot (i.e. not via chroot).

    I think that’s pretty good progress. Time for some reading manual pages (and a nap 9 -)

  56. E.M.Smith says:

    A note on USE flags.

    I think I’ve gained clue on them. They are a nested (almost recursive…) layering of what to leave out or put in your OS build. So, for example, if you need Python, you can specify just WHICH level of Python needs to have support included. So if you are using old 2.7 you need not build support for 3.5 (or others…). Similarly, you can include only drivers for YOUR video card. Or different graphics “kits”.

    They are specified in a default “profile” (that I’ve not yet found for the ARM boards so who knows) and several pages described how to shut off the default profile anyway. It looks like just a generic description of what works on a class of machine, and with ARM being highly variable, probably of less use.

    Then there is the portage config file that has a USE line / override. Naming a flag includes it while the name with a minus sign in front removes it. Then there’s a directory where you can list, per package, things to include or leave out. Finally, on the actual build command (emerge FOO) you can over ride all of that with another “USE=” statement.

    I suppose all this is useful for those times where you have a default profile, but need to change some stuff (while not wanting to deal with all of it) but then find one package that wants, say, Ruby24 support and you built with Ruby25 support…. HOWEVER, it’s a bit of a PITA when you walk into it cold with all that stuff in layers… More on that here:

    So, OK, I looked at the USE settings on the RPi M3 “include all the goodies” build, and it has a long list.

    Then I looked at the USE settings on the build for the XU4. It says in the description “I used minimal USE flags” or some such. When I first read that I thought “Oh, good, fewer to figure out”. Now I realise that means “I left out lots of stuff to make the build faster and smaller”…

    Then I compared the two and tried to come up with what I think is a good list for a full featured XU4 build. Realise that for many of these I’m guessing. Mostly I just added in what the RPi had if the XU4 didn’t have it. So turned “RUBY_TARGETS=”ruby25 ruby26″” into RUBY_TARGETS=”ruby24 ruby25 ruby26 ruby27″ since the RPi had RUBY_TARGETS=”ruby24 ruby25 ruby27″. I figured the ruby24 must have been for some package on the Pi that needed it, and the ruby27 was likely a new version that came out after the original XU4 build was made. It will make a slower build process (building more stuff) and a bigger OS (more stuff built) but the XU4 is a lot bigger than a Pi anyway ;-)

    The trickiest bit is likely the CPU spec parts. The XU4 had:
    CPU_FLAGS_ARM=”edsp thumb thumb2 v4 v5 v6 v7 vfp”
    while the RPi has:
    CPU_FLAGS_ARM=”edsp thumb thumb2 v4 v5 v6 v7 v8 vfp vfp-d32 vfpv3 vfpv4″

    The XU4 build is based off of he generic build, so limits to generic hardware.

    thumb and thumb2 are compact instructions used sometimes. v4, v5, v… are different era of instruction sets and ARM chips typically support older versions (often of shorter bit width so v7 is 32 and v8 is 64 bit while older ones can be 16 bit). I removed the v8 from the list as the XU4 is a 32 bit machine. Then, we have the vfp vpt-d32 vfpv4. Also, I’m interested in using video cores / NEON instructions for parallel math, so want NEON instruction set support included.

    SO I combined AND expanded to:

    CPU_FLAGS_ARM=”edsp neon thumb thumb2 v4 v5 v6 v7 vfp vfpv3 vfpv4″

    I left out the “vfp-d32” as that says your Floating Point Unit as 32 x 64 bit registers and I think that the V7 likely does not. But that’s a guess.

    What I think that says is to build support for “the usual” historical instruction sets and thumb instructions, AND include graphics instruction sets for 4 eras of video cores (figuring the XU4 chip is pretty new it ought to have the newer ones, but maybe being v7 it doesn’t and I’ll need to trim things back one at a time until it works… those vfp vfpv3 etc items) Yes, I ought to look it up instead of “build and break maybe” but where’s the fun in that? Also support the NEON instructions.

    Also on Input Devices, I just tossed in a few more. “synaptics” is for the mousepad driver.
    INPUT_DEVICES=”evdev libinput synaptics”

    Supposedly synaptics over rides evdev if both are present, but the RPi had both. The XU4 had libinput and I figured that’s likely some minimal bit. I decided to just build all 3 (on the theory that more is better and stuff can choose which one to use…)

    The only other odd bit is QEMU support. The RPi was build with support for QEMU virtual machines. I think it a bit daft to run a VM on a Pi, but hey, I like doing daft things to abuse hardware sometimes…. So I added those lines to the XU4 build, BUT the RPi is 64 bit and the XU4 is 32 bit so some guesses on changes were made:
    QEMU_SOFTMMU_TARGETS=”aarch64 arm i386 x86_64″ QEMU_USER_TARGETS-“arm”

    What I think that says is to be prepared to run VMs using 64 bit arm, and 32 or 64 bit Intel instruction sets, and run them on a 32 bit ARM target. Compare the RPi entry:
    QEMU_SOFTMMU_TARGETS=”aarch64 arm i386 x86_64″ QEMU_USER_TARGETS=”aarch64″

    So my guess is that I need “arm” where it has “aarch64” (and again, yes, I ought to look it up and make sure it isn’t aarmv7 or whatever…)

    These are just one very very very long line of text, and rather than crap up a comment with 90 lines of line wrap, I’m going to include the three versions of

    Now, one other minor problem. I copied these two configs to a work directory where I could compare them and make my own version… and now, the next morning, forgot where in the name space they live… Sigh. Didn’t write that in my notes. So, OK, more coffee and try to recreate what I knew last night… For now, here’s the three versions each on one VERY long line extending way off to the right ;-)

    The XU4 with generic build:

    GentooPi64 /SG2/ext/System_Backups/XU4_Gentoo # cat USE_Flags 
    USE="acl arm berkdb bzip2 cli crypt dri fortran gdbm iconv ipv6 libglvnd ncurses nls nptl openmp pam pcre readline seccomp split-usr ssl tcpd unicode xattr zlib" ADA_TARGET="gnat_2018" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_ARM="edsp thumb thumb2 v4 v5 v6 v7 vfp" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2 php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_7" RUBY_TARGETS="ruby25 ruby26" USERLAND="GNU" VIDEO_CARDS="exynos fbdev omap dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

    The PiM3 built with all the goodies:

    GentooPi64 /SG2/ext/System_Backups/RPi_Gentoo # cat USE_FLAGS 
    USE="X a52 aac acl acpi alsa arm64 berkdb bindist bluetooth branding bzip2 cairo cdda cdr cli crypt cups dbus dri dts dvdr egl elogind emboss encode exif ffmpeg flac fortran gdbm gif gles1 gles2 gpm gtk iconv icu ipv6 jpeg lcms ldap libnotify libtirpc lock mad mng mp3 mp4 mpeg ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt4 qt5 readline sdl seccomp spell split-usr ssl startup-notification svg tcpd thunar tiff truetype udev udisks unicode upower usb vorbis wxwidgets x264 xattr xcb xml xv xvid zlib" ADA_TARGET="gnat_2018" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_ARM="edsp thumb thumb2 v4 v5 v6 v7 v8 vfp vfp-d32 vfpv3 vfpv4" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" L10N="en en-GB" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="WebAssembly BPF" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_5 python3_6 python3_7" QEMU_SOFTMMU_TARGETS="aarch64 arm i386 x86_64" QEMU_USER_TARGETS="aarch64" RUBY_TARGETS="ruby24 ruby25 ruby27" USERLAND="GNU" VIDEO_CARDS="fbdev vc4" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

    The XU4 proposed all the goodies version:

    GentooPi64 /SG2/ext/System_Backups/XU4_Gentoo # cat New_Flags 
    USE="X a52 aac acl acpi alsa arm berkdb bluetooth branding bzip2 cairo cdda cdr cli crypt cups dbus dri dts dvdr egl elogind emboss encode exif ffmpeg flac fortran gdbm gif gles1 gles2 gpm gtk iconv icu ipv6 jpeg lcms ldap libglvnd libnotify libtirpc lock mad mng mp3 mp4 mpeg  ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt4 qt5 readline sdl seccomp spell split-usr ssl startup-notifications svg tcpd thunar tiff truetype udev udisks unicode upower usb vorbis wxwidgets x264 xattr xcb xml xv xvid zlib" ADA_TARGET="gnat_2018" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_ARM="edsp neon thumb thumb2 v4 v5 v6 v7 vfp vfpv3 vfpv4" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev libinput synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="WebAssembly BPF" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2 php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_5 python3_6 python3_7" QEMU_SOFTMMU_TARGETS="aarch64 arm i386 x86_64" QEMU_USER_TARGETS-"arm" RUBY_TARGETS="ruby24 ruby25 ruby26 ruby27" USERLAND="GNU" VIDEO_CARDS="exynos fbdev omap dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

    So once I figure out where I found these, I can test my proposed changes. ;-)


    Ah, the miracle of coffee and a warmer afternoon body temperature… I didn’t get these from a file, I got them via a query command:

    GentooPi64 /etc/portage/package.use # emerge --info | grep ^USE

    Which is giving me the net-net of the whole Profile, /etc/portage/make.config, etc. etc. stack of USE flags.

    So what I need to do is:

    a) Accept that the “profile” just is, as there are several admonishments about them being a pain.
    b) Look to my build make.conf as a place to overlay the desired changes to global USE flags.
    c) Perhaps, add some per-package USE changes if needed.


    I can in fact take on the pain and suffering of making a new Profile (once I figure out their add bits) and customise that.

  57. E.M.Smith says:

    Well this is really useful. Just wish I’d have found it days ago… or maybe weeks…

    GentooPi64 /var/db/repos/gentoo/profiles # cat use.desc
    # Copyright 1999-2020 Gentoo Authors
    # Distributed under the terms of the GNU General Public License v2

    # Keep them sorted

    3dfx – Enable support for Voodoo chipsets, also called as 3DFX and TDFX
    X – Add support for X11
    Xaw3d – Add support for the 3d athena widget set
    a52 – Enable support for decoding ATSC A/52 streams used in DVD
    aac – Enable support for MPEG-4 AAC Audio
    aalib – Add support for media-libs/aalib (ASCII-Graphics Library)
    accessibility – Add support for accessibility (eg ‘at-spi’ library)
    acl – Add support for Access Control Lists
    acpi – Add support for Advanced Configuration and Power Interface
    adns – Add support for asynchronous DNS resolution
    afs – Add OpenAFS support (distributed file system)
    alsa – Add support for media-libs/alsa-lib (Advanced Linux Sound Architecture)
    altivec – Add support for optimizations for G4 and G5/ppc970 processors
    ao – Use libao audio output library for sound playback
    apache2 – Add Apache2 support
    aqua – Include support for the Mac OS X Aqua (Carbon/Cocoa) GUI
    atm – Enable Asynchronous Transfer Mode protocol support
    appindicator – Build in support for notifications using the libindicate or libappindicator plugin
    audiofile – Add support for libaudiofile where applicable
    audit – Enable support for Linux audit subsystem using sys-process/audit
    ayatana – Build in support for Ayatana notification using the libindicate or libappindicator plugin
    bash-completion – Enable bash-completion support
    berkdb – Add support for sys-libs/db (Berkeley DB for MySQL)
    bidi – Enable bidirectional language support
    big-endian – Big-endian toolchain support
    bindist – Flag to enable or disable options for prebuilt (GRP) packages (eg. due to licensing issues)
    blas – Add support for the virtual/blas numerical library
    bluetooth – Enable Bluetooth Support
    branding – Enable Gentoo specific branding
    build – !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1]
    bzip2 – Use the bzlib compression library
    cairo – Enable support for the cairo graphics library
    calendar – Add support for calendars (not using mcal!)
    canna – Add support for the Canna kana to kanji conversion engine
    caps – Use Linux capabilities library to control privilege
    cdb – Add support for the CDB database engine from the author of qmail
    cdda – Add Compact Disk Digital Audio (Standard Audio CD) support
    cddb – Access cddb servers to retrieve and submit information about compact disks
    cdinstall – Copy files from the CD rather than asking the user to copy them, mostly used with games
    cdr – Add support for CD writer hardware
    cgi – Add CGI script support
    cjk – Add support for Multi-byte character languages (Chinese, Japanese, Korean)
    clamav – Add support for Clam AntiVirus software (usually with a plugin)
    colord – Support color management using x11-misc/colord
    connman – Add support for net-misc/connman
    coreaudio – Build the CoreAudio driver on Mac OS X systems
    cracklib – Support for cracklib strong password checking
    crypt – Add support for encryption — using mcrypt or gpg where applicable
    css – Enable reading of encrypted DVDs
    cups – Add support for CUPS (Common Unix Printing System)
    curl – Add support for client-side URL transfer library
    custom-cflags – Build with user-specified CFLAGS (unsupported)
    cvs – Enable CVS (Concurrent Versions System) integration
    cxx – Build support for C++ (bindings, extra libraries, code generation, …)
    dbi – Enable dev-db/libdbi (database-independent abstraction layer) support
    dbm – Add support for generic DBM databases
    dbus – Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc)
    debug – Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see
    dedicated – Add support for dedicated game servers (some packages do not provide clients and servers at the same time)
    dga – Add DGA (Direct Graphic Access) support for X
    djvu – Support DjVu, a PDF-like document format esp. suited for scanned documents
    doc – Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally
    dri – Enable direct rendering: used for accelerated 3D and some 2D, like DMA
    dts – Enable DTS Coherent Acoustics decoder support
    dv – Enable support for a codec used by many camcorders
    dvb – Add support for DVB (Digital Video Broadcasting)
    dvd – Add support for DVDs
    dvdr – Add support for DVD writer hardware (e.g. in xcdroast)
    eds – Enable support for Evolution-Data-Server (EDS)
    elogind – Enable session tracking via sys-auth/elogind
    emacs – Add support for GNU Emacs
    emboss – Add support for the European Molecular Biology Open Software Suite
    encode – Add support for encoding of audio or video files
    examples – Install examples, usually source code
    exif – Add support for reading EXIF headers from JPEG and TIFF images
    expat – Enable the use of dev-libs/expat for XML parsing
    fam – Enable FAM (File Alteration Monitor) support
    fastcgi – Add support for the FastCGI interface
    fbcon – Add framebuffer support for the console, via the kernel
    ffmpeg – Enable ffmpeg/libav-based audio/video codec support
    fftw – Use FFTW library for computing Fourier transforms
    filecaps – Use Linux file capabilities to control privilege rather than set*id (this is orthogonal to USE=caps which uses capabilities at runtime e.g. libcap)
    firebird – Add support for the Firebird relational database
    flac – Add support for FLAC: Free Lossless Audio Codec
    fltk – Add support for the Fast Light Toolkit gui interface
    fontconfig – Support for configuring and customizing font access via media-libs/fontconfig
    fortran – Add support for fortran
    freetds – Add support for the TDS protocol to connect to MSSQL/Sybase databases
    freewnn – Add support for FreeWnn kana to kanji conversion engine
    ftp – Add FTP (File Transfer Protocol) support
    gd – Add support for media-libs/gd (to generate graphics on the fly)
    gdbm – Add support for sys-libs/gdbm (GNU database libraries)
    geoip – Add geoip support for country and city lookup based on IPs
    geolocation – Enable physical position determination
    ggi – Add support for media-libs/libggi (non-X video api/drivers)
    gif – Add GIF image support
    gimp – Build a plugin for the GIMP
    git – Enable git (version control system) support
    gles2-only – Use GLES 2.0 or later instead of full OpenGL
    glut – Build an OpenGL plugin using the GLUT library
    gmp – Add support for dev-libs/gmp (GNU MP library)
    gnome – Add GNOME support
    gnome-keyring – Enable support for storing passwords via gnome-keyring
    gnuplot – Enable support for gnuplot (data and function plotting)
    gnutls – Prefer net-libs/gnutls as SSL/TLS provider (ineffective with USE=-ssl)
    gphoto2 – Add digital camera support
    gpm – Add support for sys-libs/gpm (Console-based mouse driver)
    gps – Add support for Global Positioning System
    graphicsmagick – Build and link against GraphicsMagick instead of ImageMagick (requires USE=imagemagick if optional)
    graphviz – Add support for the Graphviz library
    gsl – Use the GNU scientific library for calculations
    gsm – Add support for the gsm lossy speech compression codec
    gstreamer – Add support for media-libs/gstreamer (Streaming media)
    gtk – Add support for x11-libs/gtk+ (The GIMP Toolkit)
    gtk-doc – Build and install gtk-doc based developer documentation for dev-util/devhelp, IDE and offline use
    gui – Enable support for a graphical user interface
    guile – Add support for the guile Scheme interpreter
    gzip – Compress files with Lempel-Ziv coding (LZ77)
    handbook – Enable handbooks generation for packages by KDE
    hardened – Activate default security enhancements for toolchain (gcc, glibc, binutils)
    hddtemp – Enable monitoring of hdd temperature (app-admin/hddtemp)
    hdf5 – Add support for the Hierarchical Data Format v5
    headers-only – Install only C headers instead of whole package. Mainly used by sys-devel/crossdev for toolchain bootstrap.
    hscolour – Include coloured haskell sources to generated documentation (dev-haskell/hscolour)
    ibm – Add support for IBM ppc64 specific systems
    iconv – Enable support for the iconv character set conversion library
    icu – Enable ICU (Internationalization Components for Unicode) support, using dev-libs/icu
    idn – Enable support for Internationalized Domain Names
    ieee1394 – Enable FireWire/iLink IEEE1394 support (dv, camera, …)
    imagemagick – Enable optional support for the ImageMagick or GraphicsMagick image converter
    imap – Add support for IMAP (Internet Mail Application Protocol)
    imlib – Add support for imlib, an image loading and rendering library
    infiniband – Enable Infiniband RDMA transport support
    inotify – Enable inotify filesystem monitoring support
    introspection – Add support for GObject based introspection
    iodbc – Add support for iODBC library
    ios – Enable support for Apple’s iDevice with iOS operating system (iPad, iPhone, iPod, etc)
    ipod – Enable support for iPod device access
    ipv6 – Add support for IP version 6
    jack – Add support for the JACK Audio Connection Kit
    java – Add support for Java
    javascript – Enable javascript support
    jbig – Enable jbig-kit support for tiff, Hylafax, ImageMagick, etc
    jemalloc – Use dev-libs/jemalloc for memory management
    jit – Enable just-in-time compilation for improved performance. May prevent use of some PaX memory protection features in Gentoo Hardened.
    joystick – Add support for joysticks in all packages
    jpeg – Add JPEG image support
    jpeg2k – Support for JPEG 2000, a wavelet-based image compression format
    kde – Add support for software made by KDE, a free software community
    kerberos – Add kerberos support
    ladspa – Enable the ability to support ladspa plugins
    lame – Prefer using LAME libraries for MP3 encoding support
    lapack – Add support for the virtual/lapack numerical library
    lash – Add LASH Audio Session Handler support
    latex – Add support for LaTeX (typesetting package)
    lcms – Add lcms support (color management engine)
    ldap – Add LDAP support (Lightweight Directory Access Protocol)
    libass – SRT/SSA/ASS (SubRip / SubStation Alpha) subtitle support
    libav – Prefer libav over ffmpeg whenever both are supported
    libcaca – Add support for colored ASCII-art graphics
    libedit – Use the libedit library (replacement for readline)
    libffi – Enable support for Foreign Function Interface library
    libnotify – Enable desktop notification support
    libressl – Use dev-libs/libressl instead of dev-libs/openssl when applicable (see also the ssl useflag)
    libsamplerate – Build with support for converting sample rates using libsamplerate
    libwww – Add libwww support (General purpose WEB API)
    lirc – Add support for lirc (Linux’s Infra-Red Remote Control)
    livecd – !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used during livecd building
    lm-sensors – Add linux lm-sensors (hardware sensors) support
    lua – Enable Lua scripting support
    luajit – Use dev-lang/luajit instead of dev-lang/lua (ineffective with USE=-lua)
    lzma – Support for LZMA (de)compression algorithm
    lz4 – Enable support for lz4 compression (as implemented in app-arch/lz4)
    lzo – Enable support for lzo compression
    m17n-lib – Enable m17n-lib support
    mad – Add support for mad (high-quality mp3 decoder library and cli frontend)
    magic – Add support for file type detection via magic bytes (usually via libmagic from sys-apps/file)
    maildir – Add support for maildir (~/.maildir) style mail spools
    matroska – Add support for the matroska container format (extensions .mkv, .mka and .mks)
    mbox – Add support for mbox (/var/spool/mail) style mail spools
    memcached – Add support for memcached
    mhash – Add support for the mhash library
    mikmod – Add libmikmod support to allow playing of SoundTracker-style music files
    milter – Add sendmail mail filter (milter) support
    minimal – Install a very minimal build (disables, for example, plugins, fonts, most drivers, non-critical features)
    mmap – Add mmap (memory map) support
    mms – Support for Microsoft Media Server (MMS) streams
    mng – Add support for libmng (MNG images)
    modplug – Add libmodplug support for playing SoundTracker-style music files
    modules – Build the kernel modules
    mono – Build Mono bindings to support dotnet type stuff
    motif – Add support for the Motif toolkit
    mp3 – Add support for reading mp3 files
    mp4 – Support for MP4 container format
    mpeg – Add libmpeg3 support to various packages
    mpi – Add MPI (Message Passing Interface) layer to the apps that support it
    mplayer – Enable mplayer support for playback or encoding
    mssql – Add support for Microsoft SQL Server database
    mtp – Enable support for Media Transfer Protocol
    multilib – On 64bit systems, if you want to be able to compile 32bit and 64bit binaries
    musepack – Enable support for the musepack audio codec
    musicbrainz – Lookup audio metadata using MusicBrainz community service (
    mysql – Add mySQL Database support
    mysqli – Add support for the improved mySQL libraries
    nas – Add support for network audio sound
    ncurses – Add ncurses support (console display library)
    neXt – Enable neXt toolkit
    neon – Enable optimization support for ARM NEON processors
    netcdf – Enable NetCDF data format support
    networkmanager – Enable net-misc/networkmanager support
    nis – Support for NIS/YP services
    nls – Add Native Language Support (using gettext – GNU locale utilities)
    nntp – Add support for newsgroups (Network News Transfer Protocol)
    nocd – Install all files required to run the application without a CD mounted
    nsplugin – Build plugin for browsers supporting the Netscape plugin architecture (that is almost any modern browser)
    ocaml – Add support/bindings for the Ocaml language
    ocamlopt – Enable ocamlopt support (ocaml native code compiler) — Produces faster programs (Warning: you have to disable/enable it at a global scale)
    oci8 – Add Oracle 8 Database Support
    oci8-instant-client – Use dev-db/oracle-instantclient-basic as Oracle provider instead of requiring a full Oracle server install
    odbc – Add ODBC Support (Open DataBase Connectivity)
    offensive – Enable potentially offensive items in packages
    ofx – Enable support for importing (and exporting) OFX (Open Financial eXchange) data files
    ogg – Add support for the Ogg container format (commonly used by Vorbis, Theora and flac)
    openal – Add support for the Open Audio Library
    openexr – Support for the OpenEXR graphics file format
    opengl – Add support for OpenGL (3D graphics)
    openmp – Build support for the OpenMP (support parallel computing), requires >=sys-devel/gcc-4.2 built with USE=”openmp”
    opus – Enable Opus audio codec support
    oracle – Enable Oracle Database support
    orc – Use dev-lang/orc for just-in-time optimization of array operations
    osc – Enable support for Open Sound Control
    oss – Add support for OSS (Open Sound System)
    pam – Add support for PAM (Pluggable Authentication Modules) – DANGEROUS to arbitrarily flip
    pch – Enable precompiled header support for faster compilation at the expense of disk space and memory (>=sys-devel/gcc-3.4 only)
    pcmcia – Add support for PCMCIA slots/devices found on laptop computers
    pcre – Add support for Perl Compatible Regular Expressions
    pda – Add support for portable devices
    pdf – Add general support for PDF (Portable Document Format), this replaces the pdflib and cpdflib flags
    perl – Add optional support/bindings for the Perl language
    php – Include support for the PHP language
    pie – Build programs as Position Independent Executables (a security hardening technique)
    plasma – Build optional KDE plasma addons
    plotutils – Add support for plotutils (library for 2-D vector graphics)
    png – Add support for libpng (PNG images)
    policykit – Enable PolicyKit authentication support
    portaudio – Add support for the crossplatform portaudio audio API
    posix – Add support for POSIX-compatible functions
    postgres – Add support for the postgresql database
    postscript – Enable support for the PostScript language (often with ghostscript-gpl or libspectre)
    ppds – Add support for automatically generated ppd (printing driver) files
    prefix – Defines if a Gentoo Prefix offset installation is used
    profile – Add support for software performance analysis (will likely vary from ebuild to ebuild)
    pulseaudio – Add support for PulseAudio sound server
    python – Add optional support/bindings for the Python language
    qdbm – Add support for the qdbm (Quick Database Manager) library
    qmail-spp – Add support for qmail SMTP plugins
    qt5 – Add support for the Qt 5 application and UI framework
    quicktime – Add support for OpenQuickTime
    radius – Add support for RADIUS authentication
    raw – Add support for raw image formats
    rdp – Enables RDP/Remote Desktop support
    readline – Enable support for libreadline, a GNU line-editing library that almost everyone wants
    recode – Enable support for the GNU recode library
    rss – Enable support for RSS feeds
    ruby – Add support/bindings for the Ruby language
    samba – Add support for SAMBA (Windows File and Printer sharing)
    sasl – Add support for the Simple Authentication and Security Layer
    savedconfig – Use this to restore your config from /etc/portage/savedconfig ${CATEGORY}/${PN}. Make sure your USE flags allow for appropriate dependencies
    scanner – Add support for scanner hardware (e.g. build the sane frontend in kdegraphics)
    sctp – Support for Stream Control Transmission Protocol
    sdl – Add support for Simple Direct Layer (media library)
    seccomp – Enable seccomp (secure computing mode) to perform system call filtering at runtime to increase security of programs
    selinux – !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
    semantic-desktop – Cross-KDE support for semantic search and information retrieval
    session – Add persistent session support
    skey – Enable S/Key (Single use password) authentication support
    slang – Add support for the slang text display library (it’s like ncurses, but different)
    slp – Add Service Locator Protocol support
    smartcard – Enable smartcard support
    smp – Enable support for multiprocessors or multicore systems
    snappy – Enable support for Snappy compression (as implemented in app-arch/snappy)
    sndfile – Add support for libsndfile
    snmp – Add support for the Simple Network Management Protocol if available
    soap – Add support for SOAP (Simple Object Access Protocol)
    sockets – Add support for tcp/ip sockets
    socks5 – Add support for the socks5 proxy
    sound – Enable sound support
    source – Zip the sources and install them
    sox – Add support for Sound eXchange (SoX)
    speex – Add support for the speex audio codec (used for speech)
    spell – Add dictionary support
    split-usr – Enable behavior to support maintaining /bin, /lib*, /sbin and /usr/sbin separately from /usr/bin and /usr/lib*
    sqlite – Add support for sqlite – embedded sql database
    ssl – Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security)
    startup-notification – Enable application startup event feedback mechanism
    static – !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically
    static-libs – Build static versions of dynamic libraries as well
    subversion – Enable subversion (version control system) support
    suid – Enable setuid root program, with potential security risks
    svg – Add support for SVG (Scalable Vector Graphics)
    svga – Add support for SVGAlib (graphics library)
    symlink – Force kernel ebuilds to automatically update the /usr/src/linux symlink
    syslog – Enable support for syslog
    systemd – Enable use of systemd-specific libraries and features like socket activation or session tracking
    szip – Use the szip compression library
    taglib – Enable tagging support with taglib
    tcl – Add support the Tcl language
    tcmalloc – Use the dev-util/google-perftools libraries to replace the malloc() implementation with a possibly faster one
    tcpd – Add support for TCP wrappers
    telemetry – Send anonymized usage information to upstream so they can better understand our users
    test – Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
    theora – Add support for the Theora Video Compression Codec
    threads – Add threads support for various packages. Usually pthreads
    tidy – Add support for HTML Tidy
    tiff – Add support for the TIFF image format
    timidity – Build with Timidity++ (MIDI sequencer) support
    tk – Add support for Tk GUI toolkit
    truetype – Add support for FreeType and/or FreeType2 fonts
    uclibc – Enable uclibc specific patches and build or link uclibc
    udev – Enable virtual/udev integration (device discovery, power and storage device support, etc)
    udisks – Enable storage management support (automounting, volume monitoring, etc)
    unicode – Add support for Unicode
    unwind – Add support for call stack unwinding and function name resolution
    upnp – Enable UPnP port mapping support
    upnp-av – Enable UPnP audio/video streaming support
    upower – Enable power management support
    usb – Add USB support to applications that have optional USB support (e.g. cups)
    v4l – Enable support for video4linux (using linux-headers or userspace libv4l libraries)
    vaapi – Enable Video Acceleration API for hardware decoding
    vala – Enable bindings for dev-lang/vala
    vanilla – Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically
    vcd – Video CD support
    vdpau – Enable the Video Decode and Presentation API for Unix acceleration interface
    vhosts – Add support for installing web-based applications into a virtual-hosting environment
    videos – Install optional video files (used in some games)
    vim-syntax – Pulls in related vim syntax scripts
    vnc – Enable VNC (remote desktop viewer) support
    vorbis – Add support for the OggVorbis audio codec
    wavpack – Add support for wavpack audio compression tools
    wayland – Enable dev-libs/wayland backend
    webkit – Add support for the WebKit HTML rendering/layout engine
    webp – Add support for the WebP image format
    wifi – Enable wireless network functions
    wmf – Add support for the Windows Metafile vector image format
    wxwidgets – Add support for wxWidgets/wxGTK GUI toolkit
    x264 – Enable h264 encoding using x264
    xattr – Add support for extended attributes (filesystem-stored metadata)
    xcb – Support the X C-language Binding, a replacement for Xlib
    xcomposite – Enable support for the Xorg composite extension
    xemacs – Add support for XEmacs
    xface – Add xface support used to allow a small image of xface format to be included in an email via the header ‘X-Face’
    xft – Build with support for XFT font renderer (x11-libs/libXft)
    xine – Add support for the XINE movie libraries
    xinerama – Add support for querying multi-monitor screen geometry through the Xinerama API
    xinetd – Add support for the xinetd super-server
    xml – Add support for XML files
    xmlrpc – Support for xml-rpc library
    xmp – Enable support for Extensible Metadata Platform (Adobe XMP)
    xmpp – Enable support for Extensible Messaging and Presence Protocol (XMPP) formerly known as Jabber
    xosd – Sends display using the X On Screen Display library
    xpm – Add support for XPM graphics format
    xscreensaver – Add support for XScreenSaver extension
    xv – Add in optional support for the Xvideo extension (an X API for video playback)
    xvid – Add support for’s open-source mpeg-4 codec
    zeroconf – Support for DNS Service Discovery (DNS-SD)
    zip – Enable support for ZIP archives
    zlib – Add support for zlib (de)compression
    zsh-completion – Enable zsh completion support
    zstd – Enable support for ZSTD compression
    GentooPi64 /var/db/repos/gentoo/profiles #

  58. E.M.Smith says:

    Ok, I’ve gone through all those USE options and identified the ones that ought to be added. Many of them are various codecs or support for CD / DVD formats reading / writing. As I don’t have such a device on the UX4, I’ll likely leave those out on my first cut.

    The major goal is to get X windows working. For that I need to add “X” and likely “GTK” + “XCB”; plus some of the sound support (“alsa”, “pulseaudio”, , some codex types) and maybe some graphics format support (“PNG”, “TIFF”, “SVG”).

    I need to either choose to put them in a new profile (probably not at first) or in the make.conf (highly likely until stable). Some might be best added on a “per package” basis, but I don’t have enough information to know which ones and what packages just yet. So maybe for later.

    “Masking” is where a profile says “Don’t use Foo.” because it is either broken, ceased support years ago and is highly risky, or some other reason. I’m going to try initially to just accept whatever default masking exists and only dive into it if something I really want blows up.

    Initially also I’ll be leaving the various language versions as definded in the existing XU4 bld.
    For example, the Pi has Python version 2.7, 3.6, and 3.7 selected while the current XU4 build has Python 2.7 and 3.7 only. IFF something breaks and demands Python 3.6; well, I know how to add it. Same thing for Ruby 24, 25, and 27 vs just 25 and 26.

    I’m also going to leave out some things I doubt I’ll need. Like QEMU .

    So now I’m off to take a crack at making the USE command in the make.profile and trying another build. But while this box (The Pi M3 Gentoo) shuts down and the XU4 boots up, I think I’ll make a cup of coffee… I think I might need it…

  59. E.M.Smith says:

    After a few conflicts centered on Python levels (I think) I cut back the USE flags a lot, to mostly just X stuff and some image formats. Now it seems to be building OK with 82 new packages to install.

    With luck, this will get X working and I can get a set of windows going. That’s the big hurdle now. Once that’s done, the machine is a whole lot more comfortable to build on. Errors more easily captured. Build in one, monitor logs in another, etc.

    So now I wait… or check back in the morning ;-)

  60. Pingback: SBC OS Choices & Opinions | Musings from the Chiefio

Comments are closed.