community
How can we help you today?
64-bit Gentoo Linux Image for Pi-Top (Xfce4 Desktop)
Hi,
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 ^-^
sakaki
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.
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
command.
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?
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.
OK looking at the emerge --info I can see a few issues.
First, you are using rsync://rsync.gentoo.org/gentoo-portage as your Gentoo rsync mirror. For stability, the image uses a gated version of the Gentoo repo, with URI rsync://isshoni.org/gentoo-portage-pi64. 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
Hi,
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
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
PORTDIR="/usr/portage"
# 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 https://wiki.gentoo.org/wiki/Raspberry_Pi_VC4
VIDEO_CARDS="fbdev vc4"
INPUT_DEVICES="evdev synaptics"
# use (and verify) signed package snapshots
#FEATURES="${FEATURES} webrsync-gpg"
#PORTAGE_GPG_DIR="/etc/portage/gpg"
# uncomment to build binary packages as a byproduct of each emerge
# (these are useful backups) in /usr/portage/packages
FEATURES="${FEATURES} buildpkg"
# 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"
PORTAGE_BINHOST="https://isshoni.org/pi64pie"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://trumpetti.atm.tut.fi/gentoo/"
demouser@pi64 ~ $
demouser@pi64 ~ $ ls /etc/portage/package.use rpi3-64bit-meta systemd zzz_via_autounmask demouser@pi64 ~ $
But yes, I did try to set up systemd but never got it working.
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 USE="pitop"
you'll probably find the upgrade will go through OK.
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:
sys-block/gparted-0.28.1::gentoo
dev-cpp/gtkmm-2.24.5::gentoo
app-admin/system-tools-backends-2.10.2::gentoo
dev-cpp/cairomm-1.12.0-r1::gentoo
dev-libs/libsigc++-2.10.0::gentoo
dev-cpp/atkmm-2.24.2::gentoo
dev-cpp/pangomm-2.40.1::gentoo
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
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)
Homepage: https://github.com/sakaki-/gentoo-on-rpi3-64bit
Description: Baseline packages for the gentoo-on-rpi3-64bit image
[1] "rpi3" /usr/local/portage/rpi3
demouser@pi64 ~ $
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.
Sakaki
Hello,
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 ^-^
sakaki