Start a new topic

64-bit Gentoo Linux Image for Pi-Top (Xfce4 Desktop)


if you want to try running Gentoo Linux in 64-bit mode on your Pi-Top, you might like to have a look at the bootable image I've just released, on GitHub (please search there for "gentoo-on-rpi3-64bit", the forum seems to swallow messages with links in the body text).

You can burn the image (~829MiB compressed) to a microSD card (>=8GB), then boot your Pi-Top from it directly (the root partition will be automatically resized to fill the card on first boot). Full instructions for download and use are provided on the project's GitHub page (be sure to download the Pi-Top variant, as it contains additional drivers for your Pi-Top's battery, screen brightness etc.).

The image contains a complete (OpenRC-based) Gentoo system, and has a reasonably populated userland (Xfce v4.12, LibreOffice v5.3.4.2, Firefox v53.0.3, Thunderbird v52.2.0, VLC v2.2.6, GIMP v2.9.4 etc.) so that you can get productive without having to compile anything first. Just download, write to a microSD card, and boot to an Xfce desktop!

WiFi and Bluetooth both work, as does sound (via onboard headphone jack, and over HDMI). VC4 acceleration is supported via the mixed-mode vc4-fkms-v3d device-tree overlay / kernel module / Mesa driver, and performance seems reasonable (glxgears 400-1200fps, real-time video playback). The kernel on the image is 4.10.17-v8 from raspberrypi/linux, in pure bcmrpi3_defconfig form.

Courtesy of Rene Richarz's work, the Pi-Top image also contains:
* a patched xfce4-battery-plugin that queries the RPi3's battery over I2C (and displays a gauge in the panel);

* working backlight brightness (communicates with the Pi-Top's controller hub over SPI) with keyboard shortcuts;

* full poweroff on shutdown (ditto); and

* support for playing HDMI audio via any installed pitopSPEAKER units.

There's a 64-bit version of Gordon Henderson's handy wiringpi library (and gpio utility) included on the image too, as the above drivers need it to operate.

If you get a chance to try it, please let me know how you get on!

Have fun ^-^



I've just posted an updated (v1.1.3) Gentoo image for the Pi-Top on GitHub (please search there for "gentoo-on-rpi3-64bit", the forum seems to swallow messages with links in the body text).

The new image adds a JVM (OpenJDK v8), plus Kodi (a media hub) and Clementine (a music player / library manager). All other packages (LibreOffice, Firefox etc.) have been brought up-to-date against the Gentoo tree, as of 15 Sep 2017.

As before, there's nothing to configure to try it out, just write the image to a microSD card and boot! Starts up straight into an Xfce4 desktop.

Have fun ^-^


PS: Existing users of the previous mage can simply run genup (as root) to effect the upgrade (or wait for the weekly autoupdate to take care of this on your behalf); however you will need to emerge kodi and clementine directly, as these are not pulled in automatically, being top-level apps.

I've been attempting to upgrade my v1.1.2 installation to v1.2.0, following the instructions here.
A couple of the problems I ran into, I've been able to resolve using google.

The first issue was that emaint didn't appear to be working on my system - this was resolved, I think, by using eix-sync.
The second issue was that autofs (which I had installed in the past) appeared to mess with glibc in the emerge command, so I removed autofs.
Now I think that everything is clean, up to the


nice emerge --ask --verbose --emptytree --with-bdeps=y @world


This gets upset with four unresolved Blocks - sysvinit, systemd, gentoo-systemd-integration and eudev.  Then there's a list of 26 binary packages ignored due to non matching USE and seven binary packages ignored due to changed dependencies.

Much googling has left me confused as to how to deal with these issues.  Is it possible to deduce what I've done wrong, or should I post the entire output of the emrge command?


Hi Peter,

sorry to hear you're having problems with the upgrade ><

The most likely issue (particularly since you are getting systemd blocks) is due to custom packages installed or custom changes to USE flags (particularly since you are getting the non-matching USE error on binary packages).

Accordingly, probably best if you could paste the output of emerge --info and the contents of /var/lib/portage/world to start with.

PS I plan to release a v1.2.1 in the next month or so, with updates for the new Pi 3B+ (the Pi3 will remain supported too). I have a 3B+ in my PiTop now, makes it quite a bit snappier, and it is much less prone to thermal throttling.

Best, sakaki

 Hi, thanks for your response.

I've attached those to this post.

I presume that v1.2.1 update will be possible by genup.

Good to hear that Pi3B offers worthwhile enhancement.  Shame it can't support more memory - I have been wondering whether an upgrade to Tinker would be possible - I've read that someone has it working with PiTop OS.

(542 Bytes)
(5.66 KB)

OK looking at the emerge --info I can see a few issues.

First, you are using rsync:// as your Gentoo rsync mirror. For stability, the image uses a gated version of the Gentoo repo, with URI rsync:// You should probably set this (at least until you get the upgrade completed), in /etc/portage/repos.conf/gentoo.conf.

Secondly, compared to my system you do not appear to have the consolekit USE flag set, but you do have the systemd flag set (which will definitely mess things up). This makes me think you may not have the correct profile set. What do you get if you run eselect profile show? Do you have any additional USE flags declared in /etc/portage/make.conf or in /etc/portage/package.use/<file>?

Best, sakaki



I answered this but the forum seems to have swallowed it - so apologies if this is a duplicate.

You appear to have a different USE flag set from me: in particular you do not have consolekit set, but you do have systemd. The latter will definitely cause problems. What do you get if you run eselect profile show? Do you have any additional USE flags set in /etc/portage/make.conf or in /etc/portage/package.use/<...>?

Best, sakaki

Also, in case the forum does eventually unblock my previous post (i.e., not the one above beginning "I answered this..."), please ignore the comment in it about the rsync URI. You have the correct value set.


Hi, thanks again!


demouser@pi64 ~ $ eselect profile list
Available profile symlink targets:
  [1]   default/linux/arm64/13.0
  [2]   default/linux/arm64/13.0/desktop
  [3]   default/linux/arm64/13.0/desktop/systemd
  [4]   default/linux/arm64/13.0/developer
  [5]   default/linux/arm64/13.0/systemd
  [6]   default/linux/arm64/17.0
  [7]   default/linux/arm64/17.0/desktop
  [8]   default/linux/arm64/17.0/desktop/systemd
  [9]   default/linux/arm64/17.0/developer
  [10]  default/linux/arm64/17.0/systemd
  [11]  default/linux/musl/arm64
  [12]  hardened/linux/musl/arm64
  [13]  rpi3:default/linux/arm64/13.0/desktop/rpi3
  [14]  rpi3:default/linux/arm64/17.0/desktop/rpi3 *
demouser@pi64 ~ $ 

Oooo, am I not allowed to use systemd?  I think I tried to set it up and didn't get it working!

demouser@pi64 ~ $ cat /etc/portage/make.conf
# Simple make.conf for 64-bit Raspberry Pi 3

# NB most settings now taken from the default/linux/arm64/13.0/desktop/rpi3
# profile
# See /usr/local/portage/rpi3/profiles/targets/rpi3/<...>
# You can override as desired in this file (/etc/portage/make.conf)
# (and via the other /etc/portage/<...> subdirectory entries)

# Some scripts looks for PORTDIR in make.conf explicitly

# platform-specific USE flags, space separated
USE="pitop systemd -consolekit"

# for use when compiling locally
MAKEOPTS="-j5 -l4"
EMERGE_DEFAULT_OPTS="--jobs=5 --load-average=4"
# for use with compiling with distcc only
#MAKEOPTS="-j8 -l4"
#EMERGE_DEFAULT_OPTS="--jobs=5 --load-average=4"

# per
VIDEO_CARDS="fbdev vc4"
INPUT_DEVICES="evdev synaptics"

# use (and verify) signed package snapshots
#FEATURES="${FEATURES} webrsync-gpg"

# uncomment to build binary packages as a byproduct of each emerge
# (these are useful backups) in /usr/portage/packages

# uncomment to disribute emerges, where possible, using distcc
#FEATURES="${FEATURES} distcc distcc-pump"

# uncomment to use binary packages from PORTAGE_BINHOST, where available,
# (and build normally, where not)
FEATURES="${FEATURES} getbinpkg"

demouser@pi64 ~ $ 



demouser@pi64 ~ $ ls /etc/portage/package.use
rpi3-64bit-meta  systemd  zzz_via_autounmask
demouser@pi64 ~ $ 


Mmmm,I think my reply went awol. I'll try again after sleep - it's now almost 3am.

But yes, I did try to set up systemd but never got it working.


Hi Peter, your original reply is visible now.

You are allowed to use systemd of course, but doing so is not compatible with the binhost, which is setup for OpenRC.

So, if you change the USE line in your /etc/portage/make.conf to read:

# platform-specific USE flags, space separated

you'll probably find the upgrade will go through OK.

1 person likes this
Wow, thanks, that's made a significant difference - all the hard blocks have gone now. There's still one "non matching USE", and a few "changed dependencies".  would it be safe to use the suggested options to work around these, or do I need to fix something else?

Sorry, I know just enough Linux to be dangerous but am not familiar with portage -- I'm more familiar with ubuntu/mint, archlinux and even slackware.


Total: 909 packages (355 upgrades, 2 downgrades, 52 new, 9 in new slots, 491 reinstalls, 893 binaries, 2 uninstalls), Size of downloads: 1,426,802 KiB
Conflict: 5 blocks

!!! The following binary packages have been ignored due to non matching USE:

    =dev-embedded/rpi3-64bit-meta-1.2.0 -pitop

NOTE: The --binpkg-respect-use=n option will prevent emerge
      from ignoring these binary packages if possible.
      Using --binpkg-respect-use=y will silence this warning.

!!! The following binary packages have been ignored due to changed dependencies:


NOTE: The --binpkg-changed-deps=n option will prevent emerge
      from ignoring these binary packages if possible.
      Using --binpkg-changed-deps=y will silence this warning.
demouser@pi64 ~ $





what you are getting now looks fine. You'll always get a non-matching USE on dev-embedded/rpi3-64bit-meta, as the pitop flag is not set for the standard image. There's no problem building it locally though, as it is just a meta package (i.e. very lightweight). The deps changes don't look that bad either.

You don't need to work around anything, just let the process run through now (I assume you are using --pretend or similar to get the emerge output?). The binary packages that are ignored will actually be built locally on your machine, so you won't miss out on anything; but there aren't very many of them.

Good luck! Please let me know if you encounter any other problems during the upgrade process.

Best, sakaki


Thanks again - you're correct - I still had the --pretend option set.  When I re-ran, the command completed fairly quickly, about 30 minutes, which I suspect was too quick.

I performed the rest of the commands from the instructions and eix still reports v1.1.2.
demouser@pi64 ~ $ eix rpi3-64bit-meta
[U] dev-embedded/rpi3-64bit-meta [1]
     Available versions:  (~)1.1.0-r4 (~)1.1.1 (~)1.1.2 (~)1.1.3 (~)1.1.3-r1 (~)1.2.0 {apps +boot-fw +core +kernel-bin pitop +porthash +weekly-genup +xfce}
     Installed versions:  1.1.2(18:28:06 02/08/17)(boot-fw core kernel-bin pitop porthash weekly-genup xfce -apps)
     Description:         Baseline packages for the gentoo-on-rpi3-64bit image

[1] "rpi3" /usr/local/portage/rpi3
demouser@pi64 ~ $ 


What puzzles me is: why didn't the genup make the update to v1.1.3 at least?


 Looks like the emerge step may have hit an error. Issue (as root, all on one line):

pi64 ~ # nice emerge --ask --verbose --emptytree --with-bdeps=y @world |& tee /var/log/full_emerge.log

 This should save a copy of the emerge output to /var/log/full_emerge.log (as well as echoing it to the console). When it completes, please attach the log here and I'll have a look at it.

To answer your question, genup will also try running an update emerge, so if an error is occurring, that'll stop it too. When changing profiles, it is however required to do an "emptytree" emerge (as above), as that will rebuild everything (using the binary packages where available). genup can only do incremental updates.

Any issue at this stage will probably be something quite simple though.

Login or Signup to post a comment