Recommended way to get gentoo on Raspberry Pi 4 Model B?

[russK]

I hate to ask this question that's probably on the wiki or in the forums, but my lame attempt to search for the answer brought me to pages that seem dated.

I have a Pi 4 B with a respectable samsung micro-SD that I want to use as a generic gentoo linux desktop.
Assuming that's a valid use case, can I get a stage 3 on there similar to following the amd64 handbook?

For older raspberry pi's that I have used before, I ditched gentoo and went with raspbian as the path of least resistance.

Since I like using gentoo I thought I would try it again if it's not too hard.
I also have a much more powerful amd64 gentoo I could use to provide binary packages if necessary.

Thanks much for any response.

Regards

[wwdev16]

https://wiki.gentoo.org/wiki/Raspberry_Pi4_64_Bit_Install
https://wiki.gentoo.org/wiki/Raspberry_Pi_VC4

Using a uSD card for the build process will wear it out pretty quickly. I just use the uSD
as a boot medium that specifies the real root device and the overlays to enable. You can
use multiple cards to have multiple boot configs. Note that this is not booting from USB,
that is about directly booting to a USB drive without a uSD card.

The following is what I would recommend based on my experience. I have recently
finished setting up an rpi 4b w/ 8G.

I've had issues using distcc and cross-compiling on x86 hosts. It probably works for a
lot of packages, but I had random crashes that went away when I used local building.
Just wasn't willing to spend the time to figure which packages are borked w/ distcc.

Package building can easily overheat the rpi, especially w/ MAKEOPTS="-j4".
Make sure to use a heat sink on the cpu and have fan cooling. There is an offical rpi
case fan for the offical rpi4 case. It can keep the cpu temp to about 65C. I think it
is moderately loud and not usable for a media center.

A good quality dc power supply and cable will also reduce the chances you will
have random behavior.

To get started use a kernel from sys-kernel/raspberrypi-sources. IIRC 5.10 kernels
are LTS so might not be too bleeding edge. Don't tweak the kernel or change use flags
from the stage3 until you can reliably boot your rpi. It will save you a lot of time.

With 4GB or less ram, use MAKE_OPTS="-j2" or MAKE_OPTS="-j1". You can add swap
to increase apparent memory size, but things will get really slow when you trigger a
lot of swapping. Even if the swap device is an ssd. So keep the parallelism down when
you don't have enough memory. You will still need to use -j1 for some large packages.

You don't say how much ram you have, but >= 4GB will be a much better experience.
If you can, exporting portage and distfiles from another machine via nfs can be useful. If
you have 8GB ram and have an intermediate knowledge of linux+portage, then use a tmpfs
for your temp dir. Otherwise export via nfs an area with a lot space for temp. IIRC the
default location for PORTAGE_TMPDIR is /var/tmp/portage.

With a 3.5G tmpfs I see the rpi4 is about 6-9 times slower than a Ryzen 5 3400G that
has a 16G tmpfs (out of 32G total ram). I still need to have libreoffice and some other large
packages use traditional storage for temp. Without a tmpfs for /var/temp/portage, I
have seen rpi package builds that were >20 times slower. Especially if your portage temp
is on the same usb disk as / (even a usb3 disk). A tmpfs also speeds up compiling the kernel on
the pi. 4 hours vs 1:15 for some of the recent pi foundation kernels.

The following are some starters for using a tmpfs on an rpi w/ 8G. If it doesn't apply, or
doesn't look familiar then use an nfs export for PORTAGE_TMPDIR.

[NeddySeagoon]

russK,

The install is much like an amd64 install but you don't do it on the Pi.

Populate the SD card however you like.
Think about your kernel. You can cross compile your own and put the bits onto the SD card or you can use the foundation supplied binary kernel.

The tricky bits are doing the setup that would normally be done in the chroot, like creating the root password or adding things to runlevels.
There are two ways.

Add symlinks to the Pis /etc/runlevels/* and copy a password hash to the Pis /etc/shadow or build a static-user QEMU for arm64 and add it to the SD card so you can chroot in as normal. (Yes it runs your Pi install on the random host you install from)

I also run an arm64 binhost. Its intended for keywording rather than end users but help yourself if its useful.

-- edit --

As has been said, you will need to cool the SoC. There are passive cooling solutions.
That keeps the Pi under 60C, even when its working hard.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[antonlacon]

[wwdev16]

russK

If you do a binfmt/arm64+chroot build, I'd be interested to know how some package
build times compare on the rip4 and in the chroot. When I did that my faster amd
system wasn't noticeably faster than the rpi 4b w/ tmpfs for PKG_TMP.

[flysideways]

@russK, I like your question, it is relevant. The Raspberry Pi Foundation Pi 4 B's have sold in the millions.

At the end of last year I posted https://forums.gentoo.org/viewtopic-t-1125523.html based on using the then, not too outdated, Sakaki builds.

I just finished an install, from a Pi 4 B running the current Raspberry Pi OS 64 bit, https://downloads.raspberrypi.org/raspios_arm64/images/raspios_arm64-2021-05-28/ in order to verify the following advice.

The quick and easy way; get the Raspberry Pi OS 64 bit, update and upgrade it, then running that system build your new shiny Gentoo userland. And I say userland, because you can just rsync the current Raspberry PI OS's /boot partition to your Gentoo /boot partition. Just remember to get the root= statement correct in your new cmdline.txt file.

The longer answer.

Partition your disk as you see fit. For my test, I used the AMD64 Handbook default layout of sda1,2,3. Plugged into the usb3 port it is seen as sda, I also am booting the completed install as a usb drive.

Roughly follow the Handbook. There will be no mirrorselect. Get the stage 3 tarball. Chroot, ignore the kernel and bootloader. Make sure to get the tools you want installed and root and user set up.

Rysnc the Raspberry Pi OS /boot/ to /mnt/gentoo/boot/, also copy /lib/modules to /mnt/gentoo/modules (per Neddy's note below)

Exit per the Handbook and shutdown (don't reboot). After removing the Raspberry Pi OS disk, move your new Gentoo disk to the port you want to run it from and start and enjoy. If you forgot to edit the cmdline.txt file with the correct root= statement it won't boot.

edit to add: It only took a few hours to do this using the default/linux/arm64/17.0 (stable) profile. Any of the desktop profiles will pull in stuff taking a long time to emerge, do that after your Pi is running on Gentoo, not chrooted from the RPi OS. My $.02.

further edit: we could have an arm64/pi handbook with the Raspberry Pi OS 64bit as the recommended installation media, all the rest could be Gentoo.

[NeddySeagoon]

flysideways,

Copying /lib/modules to match the RaspberryPI OS kernel before you reboot is a good idea.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[flysideways]

Thanks

I edited the post above to include copying the modules.

The Pi I used to test this is now /desktop/gnome profile and building 191 of 253, rust, that were required with the change from the basic profile. I haven't used gnome on a Gentoo install in a long while, so, I'm going to have a look see.

[flysideways]

I still like the Idea that all it takes is one Pi and 64 bit RPiOS to get started building a Gentoo Pi Install.

Hard to believe this was two years ago. Gnome on the Pi was a fool's errand, not to be done again.

In the time since the previous post, Apple has been shipping laptops, desktops, and all-in-ones with their own arm solution. I have confirmed that Gentoo runs in virtual machines in both UTM and VMWare Fusion. Be advised that UTM has issues attaching some usb devices to the vm that Fusion does not. Using a vm on the Apple Silicon avoids the need to cross-compile.