Updated 64-bit Gentoo Image for RPi3 Released (now also for RPI3B+)

[jamesh]

The old Pi2 uses the BCM2836 SoC, the newer Pi2 uses the BCM2837.
Old 32bit only, new 32/64bit.
So this should work on the new Pi2, but I don't have any.

Gentoo32?
I have only found DIY build instructions, no ready to go image?

Not all Pi2 manufacture uses the bcm2837, some are still made with the bcm2836.

[Gavinmc42]

Not all Pi2 manufacture uses the bcm2837, some are still made with the bcm2836.

Hmm that could be confusing if I needed a lower power WiFi-less 64bit Pi
BCM2836 rev 1.1 , BCM2837 rev 1.2?

[Gavinmc42]

Hey, which is the lower power Pi2?
32ibt 2836 or 64bit 2837?

I suppose just for Ethernet gadgets the Pi2 rev 1.2 would be better than Pi3B or 3B+.
Is there a Pi2 rev1.3 with the metal top 2837 clocking at 1.4GHz?
Probably not, need a PCB redesign to get the heat out, 1.3GHz?
But old lan chip, so not as network fast as a 3B+

Hmm Pi2B+ in the works?
Rhetorical question - no answer expected

[sakaki]

Not all Pi2 manufacture uses the bcm2837, some are still made with the bcm2836.

Hmm that could be confusing if I needed a lower power WiFi-less 64bit Pi
BCM2836 rev 1.1 , BCM2837 rev 1.2?

Yes, afaik the rev 1.2 RPi2 has a 64-bit-capable SoC, whereas the earlier revs do not.

I have been informed by a user that the gentoo-on-rpi3-64bit image will boot on a rev 1.2 Pi2 board, provided that an appropriate dtb is present in /boot, by e.g. mounting the first partition of the image on a pc, at /mnt/piboot say, then doing.:

Code: Select all

# cp /mnt/piboot/bcm2710-rpi-3-b.dtb /mnt/piboot/bcm2709-rpi-2-b.dtb

Unfortunately I don't have a Pi2 to test this out.

do we have 32bit for Rip2 ?

A bootable 32-bit Gentoo image with integrated desktop etc. would definitely be possible but it's not on my todo list. There are of course the usual stage 3s etc available if you want to roll your own.

hth, sakaki

[Solid924]

Hello,

I tried to install Team viewer on Gentoo but it doesn't work. What's the correct command to install it? Sudo emerge teamviewer does NOT work.

Thanks!!

[sakaki]

Solid924,

Apologies for the delay in replying, I am currently travelling with only very intermittent internet access, and will respond on my return (last week of August).

In the meantime, please post a topic on the ARM subforum of the Gentoo board for support.

Best,

Sakaki

[sakaki]

Solid924,

I saw you posted an issue about this in the Gentoo forums. Did it get resolved to your satisfaction? Note that if can run 32-bit Raspbian apps from within 64-bit Gentoo if you need to: see for example my notes here.

Best,

sakaki

[sakaki]

All -

an apology - there is a bug (introduced by me) in porthash-1.0.6, that in turn is causing genup to fail. I've put a fix into porthash-1.0.7, and posted a news article via the rpi3-overlay, and a GitHub issue with the resolution, also copied below. ><

Diagnostics

Look near the end of your /var/log/latest-genup-run.log file to see if the issue affects you; if it does, you'll see something similar to the below:

Code: Select all

=== Sync completed for gentoo
q: Updating ebuild cache for /usr/portage ...
q: Finished xxx entries in yyy seconds
Checking master signature on gentoo repo...
porthash: Using public key 09F2FF455D90CAF4
porthash: Entering /usr/portage...
porthash: Verifying existing hashfile...
porthash: Hashfile signature and format valid
porthash: Computing master hash of /usr/portage, may take some time...
porthash: error: Hashfile and computed hashes DIFFER
Killing parent process... 

Fixing the Issue

To address the issue, open a terminal and issue the following commands, as the root user, on your rpi3:
(if running as demouser, prefix the following commands with sudo):

Code: Select all

pi64 ~ # emaint sync --repo sakaki-tools
pi64 ~ # emerge --update --oneshot --verbose app-portage/porthash

This should upgrade porthash to >= 1.0.7. Once this is done, your automatic weekly genup run should start working again.

That's it!

Background to the Issue (Optional Reading)

The porthash utility creates, or by default checks, the validity of a repository master hash (repo.hash) and counterpart digital signature (repo.hash.asc), to allow verification of a Portage tree distributed over an unauthenticated channel such as rsync. There was no such 'official' facility in Gentoo when the tool was originally deployed.

However, when Gentoo started rolling out its official app-portage/gemato manifest verification tool, porthash was modified (at v1.0.6) to migrate the location of the repo.hash{,.asc} files, from the top level /usr/portage/ directory (where they would clash with gemato) to /usr/portage/local/, which gemato ignores.

Unfortunately, during an rsync process of the Portage tree with the isshoni.org binhost, this local directory is not synced by default, but since (due to faulty logic; my bad) porthash-1.0.6 checks this location first when looking for the repo.hash{,.asc} files, the next time the tree is synced after the files have been migrated, the old (stale) /usr/portage/local/repo.hash{,.asc} files will be checked (not the fresh /usr/portage/repo.hash{,.asc} versions), and accordingly the signature verification will fail, and genup will halt with an error. (example)

This error is addressed in >=porthash-1.0.7, so upgrading this single package is sufficient to fix the problem.

Thanks to orion777 and ericbish for reporting this issue, and apologies again to all users for any inconvenience caused

[sakaki]

Hello,

I've just posted a v1.3.0 release of my bootable 64-bit Gentoo image for the RPi3 (model B and B+) on GitHub (here, includes full download instructions).

A changelog from the prior release image (with upgrade instructions) may be viewed here, but in summary:

• Migrated from porthash repository verification to Gentoo's own, official gemato-based approach (with failure quarantine). Accordingly, the porthash USE flag on dev-embedded/rpi3-64bit-meta has switched from default-on to default-off as of v1.3.0, and the weekly-gated rsync URI has changed (to one without polluting porthash signatures), from rsync://isshoni.org/gentoo-portage-pi64 to rsync://isshoni.org/gentoo-portage-pi64-gem. (The older version will continue to be supported for a time, for backwards compatibility during the changeover period.)
• Added support for the transparent-compression write-through zswap cache to bcmrpi3-kernel-bis, and created a startup service (rpi3-zswap) to start using it. Given the highly compressible nature of most RAM pages on a running system, and the RPi3's relatively meagre I/O capabilities, this should materially improve system responsiveness under load. Parameterized via /etc/conf.d/rpi3-zswap.
• Added a startup service (rpi3-expand-swap), to increase the ('real', backing-store-based) swapfile size to 1GiB, space permitting, as a one-off operation post root partition and filesystem resize. Parametrized via /etc/conf.d/rpi3-expand-swap.
• Various minor ebuild tidy-ups.
• All packages brought up-to-date against the Gentoo tree, as of 16 September 2018, including Firefox Quantum v61.0, GIMP v2.10.4 etc. Most packages have been rebuilt on gcc-8.2 (which should bring a small performance improvement).
• Kernel upgraded to sys-kernel/bcmrpi3-kernel-bis-bin-4.14.71.20180922, accompanying boot firmware to sys-boot/rpi3-64bit-firmware-1.20180919 (these will of course auto-update as new versions are unmasked).

A variant image for the Pi-Top v1 (an RPi3-based DIY laptop) is also included.

Have fun ^-^

And, as always, any problems or comments, please post either in this thread, or in the project's (sticky) thread on the Gentoo forums (here).

[Gavinmc42]

Thanks Sakaki,
Just in time for our long weekend

[sakaki]

The v1.3.0 gentoo-on-rpi3-64bit image is now also available for install through PINN (called Gentoo64 there), courtesy of procount.

Best, sakaki

[sakaki]

Hello,

FYI, firefox-62.0.2 (64 bit) has just been pushed to the binhost. Following upstream, I've built this under clang-7 rather than gcc, with lto (link-time optimization) turned on; this route reportedly yields measurable speedups during use. I've also turned on the hwaccel USE flag, so hopefully video blitting from youtube etc. will now be using the vc4 gl pipeline.

Here's a screenshot (note the app's title name has changed from 'Aurora' to 'Nightly', as it is a release-channel build with the bindist USE flag):



Users on the latest v1.3.0 gentoo-on-rpi3-64bit image just need to run genup (as root, or using sudo) to get the updated browser via binary package - or, if you prefer, simply wait for the system's weekly autoupdate to do this for you. (If you have a significant amount of work invested in an older release of this image, I have also provided manual upgrade instructions (from 1.0.0 thru 1.2.2 → 1.3.0) here.)

As there are quite a few things changed with this new release of firefox, please let me know if you find it any faster / more flaky etc. than before, so I know whether to keep the changes or revert to gcc / no lto / no hwaccel. Many thanks!

have fun ^-^

sakaki

PS: firefox-62.0.2 requires a small patch to build on arm64; I discuss this here, and have pushed a matching www-client/firefox-62.0.2 ebuild to the rpi3-overlay used by the gentoo-on-rpi3-64bit image. If you want to build it yourself from source, you'll probably need to use a user mode binfmt_misc qemu chroot on a PC, as I did, to avoid stalling out on swap: the final lto link step is very memory hungry.

[katte]

Hi, thanks for your work.
Is possible to run 64bit Gentoo on the compute module 3?

[sakaki]

Is possible to run 64bit Gentoo on the compute module 3?

I don't see why not, although I don't currently own one to check. The inbuilt wifi and bluetooth are not present on the CM3, so you'd have to disable the matching services (rpi3-bluetooth and rpi3-wifi-regdom), but even with those left active the image should still boot, I think.

You may have an issue with storage though. The baseline CM3 has 4GB of onboard eMMC I believe, and my full Gentoo system as shipped needs at least 8GB (when uncompressed), but then this is for a system with a full graphical desktop, libreoffice, firefox quantum, clang/llvm, gcc, etc. (package list here).

You could almost surely pare the system down to <4GB if you uninstalled what you didn't need: I have instructions for doing this on the project's wiki here. You could also/alternatively use a compressed r/o 'base' filesystem (e.g. SquashFS) with changes written to a writeable fs (ext4 etc.) via e.g. OverlayFS (see e.g. here), this is relatively sane if your deployed embedded application won't try to update itself that often. Given that the (xz) compressed gentoo-on-rpi3-64bit system is <1.5GB, you could conceivably even run the full image that way.

Alternatively, according to this post, NEC produce a version of the CM3 with 16GB flash, or yet again, you could use the CM3L which allows an external SD to be used on the carrier.

If you try this out, please let me know how it goes; I'll help out if I can.

Best, sakaki

[sakaki]

Just pushed firefox-62.0.3 to the binhost. This is back to being built under gcc 8.2.0, as I had configuration issues under clang (probably something my side). Now using 'thin' LTO per the official Gentoo ebuild, so considerably faster and less memory-invasive to build (but hopefully retaining most of 62.0.2's full-LTO runtime speed improvements).

Users on the latest v1.3.0 gentoo-on-rpi3-64bit image just need to run genup (as root, or using sudo) to get the updated browser via binary package - or, if you prefer, simply wait for the system's weekly autoupdate to do this for you. (If you have a significant amount of work invested in an older release of this image, I have also provided manual upgrade instructions (from 1.0.0 thru 1.2.2 → 1.3.0) here.)

[sakaki]

FYI, firefox-63.0.1-r1 is now available on the binhost. This required a bit of tweaking to build with bindist set, but hopefully will work OK. Please let me know if you experience any problems with it.

As before, users on the latest v1.3.0 gentoo-on-rpi3-64bit image just need to run genup (as root, or using sudo) to get the updated browser via binary package - or, if you prefer, simply wait for the system's weekly autoupdate to do this for you. (If you have a significant amount of work invested in an older release of this image, I have also provided manual upgrade instructions (from 1.0.0 thru 1.2.2 → 1.3.0) here.)

Best, sakaki

[sakaki]

In case you'd like to try a different full-scale browser on your gentoo-on-rpi3-64bit system, you may be interested to know that I've just pushed chromium-70.0.3538.67 to the binhost.

Here's a screenshot:


Seems to run OK in initial testing (youtube etc.).

To get it, make sure your system is up-to-date (via genup), and then run:

Code: Select all

[email protected] ~ $ sudo emaint sync --auto
[email protected] ~ $ sudo emerge -av www-client/chromium

Note that one of the deps, media-libs/openh264, will have to be built locally, as I cannot lawfully distribute a binary package for it (unconditional bindist RESTRICT). Portage will take care of this automatically for you as part of the above emerge; it will only take about 15mins or so to compile. All other required components should be on the binhost.

Also, for the same reason, the main chromium binary has been built with the proprietary-codecs USE flag off.

Well, please let me know if you experience any problems with it!

Best, sakaki

[sakaki]

As I've had a few queries from users wanting to remotely connect in to their gentoo-on-rpi3-64bit desktop from another box, I've just posted a short article on the project's open wiki here, that covers how to set up a tigervnc server (package available on the binhost) and then connect to it (from both a Linux and Windows client PC). Tunnelling the connection over ssh for security is also described.

Example of connecting from Windows 10:



best, sakaki

[Gavinmc42]

Sakaki, can RDP (Remote Desktop Protocol) be run on the Pi?
I don't have a Windows10 box but I seem to remember running RDP on a Pi and Windows 7 has native RDP support so no VNC software was needed.
I sometimes have issues with VNC on Windows.

[sakaki]

Sakaki, can RDP (Remote Desktop Protocol) be run on the Pi?
I don't have a Windows10 box but I seem to remember running RDP on a Pi and Windows 7 has native RDP support so no VNC software was needed.
I sometimes have issues with VNC on Windows.

Not from the main tree I think, but there is an overlay ebuild here that covers xrdp. I've adapted this, and its partner xorgxrdp module ebuild, and put them into the overlay used by the image. I've also just built binary packages for these and pushed them to the binhost (along with their deps).

So if you do (on your RPi3):

Code: Select all

[email protected] ~ $ sudo emaint sync --repo rpi3
[email protected] ~ $ sudo emerge -av net-misc/xrdp net-misc/xorgxrdp

that should install the server for you.

Then edit the file /etc/xrdp/sesman.ini, and comment out the line near the top so it reads:

Code: Select all

#ListenAddress=127.0.0.1

Leave the rest of the file as-is, and save, exiting the editor. (This change instructs the server to listen on all interfaces for connections, not just localhost.)

Then issue:

Code: Select all

[email protected] ~ $ sudo rc-service xrdp start

You should have an RDP server running! If you find your PI's IP address you should then be able to connect to it via Windows Remote Desktop. I just tried this quickly now, it appears to work: note that Windows will complain about certificate authentication - just accept the warning and continue anyway when prompted (you'd need to set this up properly for production use, obviously, this is just a quick test). You'll then get a login dialog (hopefully) - choose Xorg as the session type (the default) and enter your login credentials (e.g. demouser as username, raspberrypi64 as password, or whatever you have set). Note that you can't log in directly as root, for security.

Well, let me know if it works for you, if so I'll try to write it up properly when I have a moment.

hth, sakaki

[gilius]

I've been using this again over the past few days, and with sakaki's attention to detail - not to mention love and care - this definitely feels like the most solid of all distros for the Rpi3! That portage system is starting to look more attractive everyday..

[code_exec]

I might try Gentoo64 on the Pi 3. I've tried to stick with 32-bit in the past, since the performance of Ubuntu ARM64 was poor; the Pi froze each time I opened a web browser or even ran a simple apt command! I believe that the experimental GL driver was enabled in the u-boot kernel, since the picture on my TV seemed to go off screen. When the Pi froze, I had no other option but to hard reboot it (hard reboot = yank the power lead in anger).

Gentoo, Fedora, and Arch Linux are also available as 64-bit distros for the Pi 3 (as well as the RPi 2 Rev 1.2).

Fedora - https://fedoraproject.org/wiki/Architec ... berry_Pi_3

Arch - https://archlinuxarm.org/platforms/armv ... berry-pi-3

Gentoo - https://wiki.gentoo.org/wiki/Raspberry_ ... e_for_RPi3

[gilius]

I couldn't get Fedora to work on the B+ and neither Ubuntu 18.04 - both in some kind of freeze-like state at the desktop.

[code_exec]

I couldn't get Fedora to work on the B+ and neither Ubuntu 18.04 - both in some kind of freeze-like state at the desktop.

What Fedora flavour did you use? If you used Fedora GNOME then it's bound to freeze and be slow, you need at least 2GB RAM for GNOME if you don't plan on lauching any apps. If you do plan on launching any apps, you need at least 4GB.

I would like to see GNOME 3 and standard Ubuntu running on the Pi someday, but performance won't be all that great on 1GB RAM. I would try GNOME myself, but I don't want to enable the experimental OpenGL driver (since it doesn't play nicely with my TV) but GNOME requires it for rendering.

Maybe try one of the Fedora spins such as Fedora XFCE, those will be faster.

[gilius]

I tried Fedora 28 and 29 - both don't work on my B+
29 didn't reach the gui
28 started a frozen gui