User avatar
sakaki
Posts: 523
Joined: Sun Jul 16, 2017 1:11 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Sun Jan 12, 2020 6:14 pm

Hi Ian,

So, 32-bit Raspbian Buster exhibits this even after a full apt-get update, but not after rpi-update has been run? Did you record which kernel version was present before and after the rpi-update?

Anyhow, if you boot your Raspbian image under the official 64-bit kernel instead (by setting arm_64bit=1 in /boot/config.txt, and restarting) does the xset command still work?

If it does, then it should be possible to try booting the gentoo image with the Raspbian 64-bit kernel and module set (by copying over the relevant files in /boot and /lib/modules), and if xset still does not work, copying over the other /boot firmware files (other than config.txt and cmdline.txt) and trying again. This will indicate where the issue lies (boot firmware, boot settings, kernel/modules or userland).

Or if it does not, then it would appear a 32-bit/64-bit kernel issue (or a configuration difference between them at least) is at the root of this.

hth, sakaki

idpitt
Posts: 9
Joined: Sat Jan 04, 2020 2:28 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Mon Jan 13, 2020 12:30 am

Here's the background for most of what you asked for.

Raspian:

Clean image:

4.19.75-v7l+
With/Without hdmi_blanking=1, xset dpms force off doesn’t kill back light

Update to 4.19.93-v7l+

Xset dpms force off works fine regardless of setting of hdmi_blanking - i.e. the backlight goes off

Set kernel to 64 bit
4.19.93-v8+

Xset dpms force off works fine.



On Gentoo: 4.19.80-v8
Xset force just blanks screen

I did install the latest kernel on your build site ( 4.19.93-v8-9ee95326a181-p4-bis+) and xset dpms force off behaves as before - screen blanks but the back light stays on.

With the Raspian kernel and modules copied over, same as the two Gentoo image kernels.

Onwards! I'll try other combos tomorrow.

idpitt
Posts: 9
Joined: Sat Jan 04, 2020 2:28 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Tue Jan 14, 2020 1:01 am

DPMs challenges continue....

With the Raspian kernel and dtbs copied over to /boot, the machine boots but still no joy on the xset dpms force off. Incidentally, vcgencmd display_power on/off works fine.

with the dtbs copied over and all *.elf files copied, the machine failed to boot, stopping at

[0.768909] mmcblk0: p1 p2

When restored to a working gentoo image ( switching back the kernel, moving the gentoo build dtbs and elfs back ) , I did note that I was getting

raspberrypi-firmware soc:firmware: Request 0x00048019 returned status 0x80000001

in desg. Two entries are generated for every xset dpms call.

I noted in the gentoo forum ( https://forums.gentoo.org/viewtopic-t-1 ... t-100.html ) you recommended forcing use hdmi in rpi-settings but that made no difference either.

so.. there must be something lurking somewhere. Reaching for the off button when I leave isn't too onerous. Would be good to have automated power saves at some point though.

User avatar
secondhand
Posts: 11
Joined: Sat Nov 30, 2019 2:10 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Thu Jan 16, 2020 12:50 am

I commend you for your efforts to maintain an RPi distribution for Gentoo. Its good to experiment with this because the ARM platform is rapidly evolving. We will soon have more powerful and more energy-efficient ARM systems competing with Intel on the desktop. However, I do have several suggestions:

1. I was impressed by the fact that Gentoo is more responsive than Debian based distros under low memory conditions, but I cannot be building everything from source when updates take all day. This is just not practical on an SD card or a platform like the Pi3 with 1GB RAM. You should clearly state in bold, colored print that the minimum hardware configuration needed to run Gentoo/ARM is 2GB RAM with a faster storage medium (or 4GB RAM with a very high speed SD card.)

Excellent flash memory research & comparison tool (toggle desired matching criteria with control-click)
https://www.mouser.com/Embedded-Solutio ... ?P=1yxxwsy

The more I look at desktop Linux distros on the Raspberry Pi, the more impressed I am by Android: its the only Linux OS with a user interface that runs acceptably well on flash memory devices. The UI does not freeze when you run out of RAM and it automatically repairs file system corruption if a power loss occurs. (Most Linux distros do neither.) I can close applications on Gentoo to release some RAM during an update if needed (which I could not do on Raspbian) but was unable to operate menus like File|Save As.

2.
you will find that most packages (which don't have e.g. processor-specific assembly or 32-bit-only assumptions) will build fine on arm64 anyway, you just need to tell Gentoo that it's OK to try. To do so for this package, become root, then issue:
pi64 ~ # echo "app-editors/shed * ~*" >> /etc/portage/package.accept_keywords/shed
Then you can try installing it, using emerge:
https://github.com/sakaki-/gentoo-on-rp ... der-gentoo
a) That is not always enough... sometimes I have to do this for the dependencies too. If we have to do this frequently, then overriding keyword restrictions should be an option in the Porthole GUI that propagates to dependencies at merge time, through a check box or yes/no dialog.

In my opinion, the purpose of a desktop Linux distro should be to save people from the scourge of Microsoft Windows. That is not going to happen if you require the average user to issue terminal commands or edit text files just to perform routine operations -- and fixing that should take priority over other development tasks. System components like the file manager should present a GUI prompt for privilege escalation where needed like they do on Mac & Windows, instead of requiring sudo in terminal. (This is generic advice which applies to all Linux distros.)

b) This method does not work for Anydesk. I presume it is a binary application (and if so, then Porthole needs to indicate the difference more clearly.) Furthermore, ARM binaries exist for this app on other Linux distros, so if you are going to distribute one for the Intel platform, there should be one here for ARM too.


3.
Once you get a package working successfully, you can then explicitly keyword its dependencies if you like (in /etc/portage/package.accept_keywords/...), rather than relying on ACCEPT_KEYWORDS="* ~*" in /etc/portage/make.conf. Should you do so, please feel free to file a PR against the genpi64:default/linux/arm64/17.0/desktop/genpi64 profile with your changes, so that others can benefit
https://github.com/sakaki-/gentoo-on-rp ... der-gentoo
Why cant Porthole detect build success or failure and report automatically?

4.
If you'd like to install Flatpak apps on your RPi, please see these notes for further details.
https://github.com/sakaki-/gentoo-on-rp ... der-gentoo
At the time of writing, Gentoo does not have Flatpak in its main tree, so we need to leverage an appropriate overlay (user ebuild repository) from GitHub (here).
https://github.com/sakaki-/gentoo-on-rp ... s-on-your-
Flatpak does appear when I search in Porthole but it could not be installed that way. I proceeded with the manual method, but even after Flatpak was installed, I cannot install apps from Flathub.org because the file opens in Abiword !

5. In the properties for the CPU Graph panel application, the option to change the colors on the CPU bars does not work. The same goes for System Load Monitor. I would also recommend that all Linux desktop distros include the more advanced Multiload-NG.* Coming from Process Hacker on Windows, Cool Tool on Android and MenuMeters on Mac, I find the lack of a full suite of customisable panel gauges quite disappointing.

* https://github.com/nylen/multiload-ng
https://github.com/udda/multiload-ng

6. When you unmerge a package, it still appears as installed in Porthole until you repeat the search for the package name.

7. Porthole needs some animation to show that its working so I can monitor it with a glance instead of going right up to the screen to read that tiny print. We dont all have perfect vision.

8. I am pleased to see that I can drag shortcuts & pictures from the browser to the desktop since so many desktop Linux distros dont support this. But the default icon should be something that clearly indicates it is a web shortcut. (Reference Mac & Windows as examples.) And this feature is not very helpful when internet shortcuts open in Abiword !

9. Like most desktop Linux distros, Samba & Avahi network browsing is not enabled and/or partially broken, where it typically “just works” on Mac & Windows. (LibreELEC seems to have this sorted though, and the responsible parties on various Linux distros might want to have a look at their sources.)

User avatar
Gavinmc42
Posts: 4372
Joined: Wed Aug 28, 2013 3:31 am

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Thu Jan 16, 2020 2:08 am

secondhand, all valid points, BUT...
Gentoo64 is not a beginners OS, it is one person's (with help) version of a niche Linux distribution.
Any Linux distribution can never be perfect, those little niggles are what drives peoples "improvements".

Pi4 1GB, browsing barely works.
Pi4 2GB, usable browsing.
Pi4 4GB, does most desktop stuff, just a bit slower than a PC that is useful for compiling.

Those niggles have made me learn about Linux, window and desktop managers.
Never bother learning that on Raspbian.

Android is a big development effort over years, with Billion dollar corporations behind it
Mac and Windows, again lots of people work on that.
Gentoo64 is the main effort of one person part time championing a niche Linux OS that works very well on a 4GB Pi4.
I find the lack of a full suite of customisable panel gauges quite disappointing.
You could fix that, plenty to choose from.
Linux is "customisable" you just need to learn how.
That's what I'm doing, based on the lite version.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
sakaki
Posts: 523
Joined: Sun Jul 16, 2017 1:11 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Tue Jan 21, 2020 4:47 pm

Hi secondhand,

first, thanks for taking the time to try my Gentoo image on your RPi and to post such detailed feedback. Very much appreciated.

To your points:
secondhand wrote:
Thu Jan 16, 2020 12:50 am
1. I was impressed by the fact that Gentoo is more responsive than Debian based distros under low memory conditions, but I cannot be building everything from source when updates take all day. This is just not practical on an SD card or a platform like the Pi3 with 1GB RAM. You should clearly state in bold, colored print that the minimum hardware configuration needed to run Gentoo/ARM is 2GB RAM with a faster storage medium (or 4GB RAM with a very high speed SD card.)
Simply updating existing packages should not require large amounts of memory, since the image as shipped is set up to use a binhost, to which updates are pushed by a build server on a regular basis in binary package form (for more details, please see these notes). Only if you change USE flags (high-level configuration settings) or try to emerge (build) packages not on the binhost already, should you find yourself needing to compile from source. And even then, it is possible to set up a distcc / crossdev system to offload much of the necessary compilation work (notes here ff), or build e.g. memory constrained packages on your PC using a QEMU / binfmt_misc chroot (notes here). I built and maintained this Gentoo image on an RPi3B originally using a combination of these techniques.

So I guess it comes down to audience. It turns out (to my surprise, if I'm honest!) that there are quite a few people using this image just as a generic, ready-to-roll 64-bit desktop - and the majority of these don't install any additional packages (since it already bundles Firefox, Chromium, Libreoffice, various video players, GCC, Clang, Go, Java etc.) and rely on the provided genup weekly updater. For those users, even a 1GiB system should be fine, since essentially all updates will be from binary packages.

For those who go 'off piste' and start emerging new packages, changing global USE flags, unmasking things etc. then via a combination of the above strategies even a 1GiB system can be useable - although of course in this case the RPi4B 4GiB is the preferred choice.

This is what is meant when people say Gentoo is a "metadistribution" - it makes it possible for even an individual developer to curate a set of masks, USE flags etc to create a downstream (primarily binary) distro for others, which is what gentoo64 is, in effect. And ChromeOS too, for that matter (although they hide it better ^-^) That can then form the basis for someone else to customize, should they wish so to do. The further away from the curated downstream instance you go, the more you'll have to build and maintain yourself, and the more compute capacity - and memory - you'll require.

That's why I don't put a prescriptive minimal system requirement in the readme: because the true answer is, "it depends".
secondhand wrote:
Thu Jan 16, 2020 12:50 am
2.
you will find that most packages (which don't have e.g. processor-specific assembly or 32-bit-only assumptions) will build fine on arm64 anyway, you just need to tell Gentoo that it's OK to try. To do so for this package, become root, then issue:
pi64 ~ # echo "app-editors/shed * ~*" >> /etc/portage/package.accept_keywords/shed
Then you can try installing it, using emerge:
https://github.com/sakaki-/gentoo-on-rp ... der-gentoo
a) That is not always enough... sometimes I have to do this for the dependencies too. If we have to do this frequently, then overriding keyword restrictions should be an option in the Porthole GUI that propagates to dependencies at merge time, through a check box or yes/no dialog.
The keywording situation for arm64 on Gentoo is a bit annoying at the moment, yes. As I also note in the readme:
if you intend to install complex packages, you may find it easier to set ACCEPT_KEYWORDS="* ~*" in /etc/portage/make.conf, since many packages are not yet keyworded for arm64 yet on Gentoo.
secondhand wrote:
Thu Jan 16, 2020 12:50 am
In my opinion, the purpose of a desktop Linux distro should be to save people from the scourge of Microsoft Windows. That is not going to happen if you require the average user to issue terminal commands or edit text files just to perform routine operations -- and fixing that should take priority over other development tasks. System components like the file manager should present a GUI prompt for privilege escalation where needed like they do on Mac & Windows, instead of requiring sudo in terminal. (This is generic advice which applies to all Linux distros.)
I will look at some form of visual escalation prompt as a few people have asked for that.
secondhand wrote:
Thu Jan 16, 2020 12:50 am
b) This method does not work for Anydesk. I presume it is a binary application (and if so, then Porthole needs to indicate the difference more clearly.) Furthermore, ARM binaries exist for this app on other Linux distros, so if you are going to distribute one for the Intel platform, there should be one here for ARM too.
anydesk contains pre-built binaries and the ebuild currently only has handlers for 32 and 64bit x86; force-keywording the ebuild won't help you in these situations (as there is no source to try building). I should probably clarify that point, thanks.

As regards Porthole, once you diverge from using the bundled packages on the image (or from their installed versions, or their default configuration) you are getting into the innards of a source-based distribution, by construction. That brings with it the ability to customize, but, also the likelihood of having to navigate potentially conflicting choices of USE flags, masks, versions, slots and so on. The Porthole GUI makes a very good attempt to cover these bases, but, in my opinion anyhow, 'expert' use of Gentoo is inevitably going to require the command line at some point (NB: this doesn't mean 'basic' use should require this however, I agree about that).

Most binary distros avoid this problem by having, essentially, one set of 'blessed' package versions and configurations, for a large set of packages, which are then maintained either on a release or continuous basis (of course there may be multiple top-level versions of certain things available, such as e.g. Python). Such a choice makes things easier for those who just want to use something that wasn't on the original shipped image (a particular editor, say), but options like changing the init system, installing multiple versions of Clang etc., are generally off the menu ^-^

Now, to be clear, my Gentoo image does this too (i.e., preselects a set of package versions, USE flags, masks etc. for you), but has the following differences when compared to a 'normal' binary distro:
  • There are fewer packages built on the binhost compared to say Arch or Debian, because for this image, the binary maintainer is just me ><
  • You are free to migrate a little, not at all or wildly from the configuration provided however. The further you 'wander off' the more you'll have to build, but changing init systems, slotting etc. are very much possible.
That convenience / freedom tradeoff will solve differently for different users of course, and will determine whether, for you, the light from Gentoo is worth the candle. Most people should, for example, stick to 32-bit Raspbian for now, as that is the official OS and best supported. Others will just want a 64-bit userland with the maximum possible number of binary packages, and find e.g. Arch or Ubuntu meets their needs better.

Yet others just want a useable 64-bit desktop for the RPi that is well integrated (supports the camera, h/w video codecs, dual screen on the RPi4 etc.) and ships with a decent set of prebuilt apps - and at this point actually the Gentoo image is quite a viable option again (since the RPI-specific support is quite good, packages are built optimized for the RPi4's SoC while still running on the RPi3B/B+ etc). Drink deep, or taste not the Pierian spring ^-^

For more notes on Gentoo package management, please see my notes here.

Well, one thing I would recommend you have a quick look at is my raspbian-nspawn-64 image: this provides a standard 32-bit Raspbian userland, under the official 64-bit kernel, but with a 64-bit Debian system automatically booted in an lightweight, systemd-nspawn container, and set up so that launchers for 64-bit apps are automatically created on the host (32-bit) desktop when installed. You may find it a better tradeoff than Gentoo. Screenshot:

Image
secondhand wrote:
Thu Jan 16, 2020 12:50 am
3.
Once you get a package working successfully, you can then explicitly keyword its dependencies if you like (in /etc/portage/package.accept_keywords/...), rather than relying on ACCEPT_KEYWORDS="* ~*" in /etc/portage/make.conf. Should you do so, please feel free to file a PR against the genpi64:default/linux/arm64/17.0/desktop/genpi64 profile with your changes, so that others can benefit
https://github.com/sakaki-/gentoo-on-rp ... der-gentoo
Why cant Porthole detect build success or failure and report automatically?
So, as noted I maintain an 'overlay' used by the image, which contains inter alia a custom profile containing e.g. per-package keywording. This is not the official upstream keywording - to change that, you'd need to file a bug report and have it actioned by a Gentoo dev (or at least file a PR). I doubt the Porthole tool authors would want to get into that as an automated step, but you could always ask: http://porthole.sourceforge.net
secondhand wrote:
Thu Jan 16, 2020 12:50 am
4.
If you'd like to install Flatpak apps on your RPi, please see these notes for further details.
https://github.com/sakaki-/gentoo-on-rp ... der-gentoo
At the time of writing, Gentoo does not have Flatpak in its main tree, so we need to leverage an appropriate overlay (user ebuild repository) from GitHub (here).
https://github.com/sakaki-/gentoo-on-rp ... s-on-your-
Flatpak does appear when I search in Porthole but it could not be installed that way. I proceeded with the manual method, but even after Flatpak was installed, I cannot install apps from Flathub.org because the file opens in Abiword !
Don't understand this one, sorry ><
Which file opens in Abiword? The instructions linked in the project's wiki (here) worked fine last time I tried them (and others have also used this successfully); e.g.:
Image
Image
secondhand wrote:
Thu Jan 16, 2020 12:50 am
5. In the properties for the CPU Graph panel application, the option to change the colors on the CPU bars does not work. The same goes for System Load Monitor. I would also recommend that all Linux desktop distros include the more advanced Multiload-NG.* Coming from Process Hacker on Windows, Cool Tool on Android and MenuMeters on Mac, I find the lack of a full suite of customisable panel gauges quite disappointing.

* https://github.com/nylen/multiload-ng
https://github.com/udda/multiload-ng
I'll have a look at that. Thanks.
secondhand wrote:
Thu Jan 16, 2020 12:50 am
6. When you unmerge a package, it still appears as installed in Porthole until you repeat the search for the package name.

7. Porthole needs some animation to show that its working so I can monitor it with a glance instead of going right up to the screen to read that tiny print. We dont all have perfect vision.
Again, you would need to take this up with the Porthole developers: http://porthole.sourceforge.net
secondhand wrote:
Thu Jan 16, 2020 12:50 am
8. I am pleased to see that I can drag shortcuts & pictures from the browser to the desktop since so many desktop Linux distros dont support this. But the default icon should be something that clearly indicates it is a web shortcut. (Reference Mac & Windows as examples.) And this feature is not very helpful when internet shortcuts open in Abiword !
I have just tried this (from Firefox) and when I drop a link on the desktop, it brings up a dialog to create a link. Agreed - the default icon should be something more reasonable (I'll have a look at fixing that, and in the meantime you can change the default icon if you click on it in the Create Link dialog) but then, when I activate on it (and allow to launch when prompted) it does open in Firefox.

Have a look at your Applications -> Settings -> MIME type editor. Enter 'html' in the search box, and check whether Abiword has been set as the default for e.g. text/html. If so, click on this and change it (to Firefox (aka Aurora), or Chromium).

I'll have a look at ensuring there is a sensible system-wide default for this. It may be Abiword overrides it on install or upgrade.
secondhand wrote:
Thu Jan 16, 2020 12:50 am
9. Like most desktop Linux distros, Samba & Avahi network browsing is not enabled and/or partially broken, where it typically “just works” on Mac & Windows. (LibreELEC seems to have this sorted though, and the responsible parties on various Linux distros might want to have a look at their sources.)
Samba and friends are off deliberately as shipped, since many Gentoo users do not appreciate the security implications of having them active. For notes on enabling Samba (the necessary binaries are bundled) see e.g. here.

But I take your point, it would be nice to e.g. have a switch on e.g. the RPi Config Tool to turn this on, for those who want it (along with NFS etc.)

Thanks again for the feedback!

Best,

sakaki

User avatar
Gavinmc42
Posts: 4372
Joined: Wed Aug 28, 2013 3:31 am

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Thu Jan 23, 2020 11:19 am

Hi Sakaki, you snuck mesa 19.3.2 in.
Thanks, that going to be fun to lay with.
I just noticed it when playing with x11 on newest Lite.

I did a genup on this Desktop version but it seems stuck on 19.2.4.
Will try again and find the error message.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
Gavinmc42
Posts: 4372
Joined: Wed Aug 28, 2013 3:31 am

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Fri Jan 24, 2020 7:39 pm

While I still had a full desktop version with mesa 19.2.4 I thought I would compare vblank_mode=0 glxgears
About 880fps on the Gentoo64 Full and with Lite 1.5.3 genup to mesa 19.3.2 with x11/Openbox I got about 1380fps.

I don't know if it is Lite/Full or 19.2.4/19.3.2 related.
Will be getting the mesa demos for more testing on the 19.3.2/Lite/Openbox combo.
Both are abut 80fps full screen?

Do you have compositing on in the full version?
Ok yes, trying with that off.
Edit - Now getting 1430fps in Full 19.2.4 with compositing off.
So perhaps 19.3.2 is slower?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

ozbird
Posts: 13
Joined: Wed Dec 10, 2014 7:26 am

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Mon Jan 27, 2020 11:14 pm

Hi sakaki,

Thanks for making your bootable 64-bit Gentoo image available; I've been running it on my Pi 4 4GB for a while now.
I don't know if it runs any better than 32-bit Raspbian, but I enjoy the flexibility of building from source.

When I run "genup" now, I get the following message:
WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

sys-boot/rpi3-64bit-firmware:0

(sys-boot/rpi3-64bit-firmware-1.20200114:0/0::genpi64, ebuild scheduled for merge) USE="-dtbo -pitop" conflicts with
~sys-boot/rpi3-64bit-firmware-1.20190925[-dtbo(+)] required by (sys-kernel/bcmrpi3-kernel-bis-bin-4.19.89.20191217:0/0::genpi64, installed) USE="checkboot with-matching-boot-fw -pitop"
^ ^^^^^^^^^^
~sys-boot/rpi3-64bit-firmware-1.20190925[-dtbo(+)] required by (sys-kernel/bcm2711-kernel-bis-bin-4.19.89.20191217:0/0::genpi64, installed) USE="checkboot pi3multiboot with-matching-boot-fw -pitop"
^ ^^^^^^^^^^
As I'm running on a Pi 4, I assume that I don't need the Pi 3 firmware, kernel etc. Did I miss a step to remove/disable the Pi 3 components?

Cheers!

WODAK
Posts: 22
Joined: Thu Jan 23, 2020 1:53 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Tue Jan 28, 2020 10:35 am

Does Gentoo 64 support latest Mesa drivers 19.3.2? I'm confused because glxinfo shows 19.3.2 OpenGL ES...

User avatar
Gavinmc42
Posts: 4372
Joined: Wed Aug 28, 2013 3:31 am

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Tue Jan 28, 2020 11:08 am

Does Gentoo 64 support latest Mesa drivers 19.3.2? I'm confused because glxinfo shows 19.3.2 OpenGL ES...
I noticed that too :D

Checked again Sunday with the full version, 15.3 then did a genup and there is 19.3.2.
I'm still trying to find some test code to check to see if the compute shaders work.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

maxmars
Posts: 7
Joined: Mon Dec 09, 2019 11:46 am

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Tue Jan 28, 2020 3:17 pm

ozbird wrote:
Mon Jan 27, 2020 11:14 pm
Hi sakaki,

Thanks for making your bootable 64-bit Gentoo image available; I've been running it on my Pi 4 4GB for a while now.
I don't know if it runs any better than 32-bit Raspbian, but I enjoy the flexibility of building from source.

When I run "genup" now, I get the following message:
WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

sys-boot/rpi3-64bit-firmware:0

(sys-boot/rpi3-64bit-firmware-1.20200114:0/0::genpi64, ebuild scheduled for merge) USE="-dtbo -pitop" conflicts with
~sys-boot/rpi3-64bit-firmware-1.20190925[-dtbo(+)] required by (sys-kernel/bcmrpi3-kernel-bis-bin-4.19.89.20191217:0/0::genpi64, installed) USE="checkboot with-matching-boot-fw -pitop"
^ ^^^^^^^^^^
~sys-boot/rpi3-64bit-firmware-1.20190925[-dtbo(+)] required by (sys-kernel/bcm2711-kernel-bis-bin-4.19.89.20191217:0/0::genpi64, installed) USE="checkboot pi3multiboot with-matching-boot-fw -pitop"
^ ^^^^^^^^^^
As I'm running on a Pi 4, I assume that I don't need the Pi 3 firmware, kernel etc. Did I miss a step to remove/disable the Pi 3 components?

Cheers!
Same issue here, came to post it myself.
Thanks for any insight.
Max

User avatar
sakaki
Posts: 523
Joined: Sun Jul 16, 2017 1:11 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Wed Jan 29, 2020 4:49 pm

Hi ozbird, maxmars,

the issue you are seeing is not actually an error, but the expected behaviour.

What is happening, is that your binary kernel packages have been emerged (as is the shipped default) with the with-matching-boot-fw USE flag active. This, in turn, constrains the version of the sys-boot/rpi3-64bit-firmware package (which, despite its name applies to both the RPi3 and 4 models!) to that which was most modern at the time the kernel package was built. This is done to ensure compatibility.

If more modern firmware is released (wrt the kernel) then it will not be available for upgrade due to this constraint (although other packages on the system should upgrade) and so you get the "WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict" message.

When I unmask a more modern version of the kernel upstream, this issue will clear itself and the firmware will update too.

hth, sakaki


haaldemir
Posts: 58
Joined: Mon Jul 08, 2019 2:46 pm
Location: Istanbul, Turkey

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Sat Feb 15, 2020 9:12 am

Hi Sakaki

is update avaible? i check an error

Thanks
[email protected] ~ $ genup
* Checking Portage configuration, please wait...
* Gentoo System Updater v1.0.24
* Updating Portage tree and syncing the eix cache
* (this may take some time)...
* Syncing all portage overlays
/usr/bin/eix-sync: line 396: layman: command not found
* layman -S failed
* Running emerge --sync
>>> Syncing repository 'gentoo' into '/var/db/repos/gentoo'...
* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
* Refreshing keys via WKD ... [ ok ]
>>> Starting rsync with rsync://isshoni.org/gentoo-portage-pi64-gem...
>>> Checking server timestamp ...
receiving incremental file list
timestamp.chk

Number of files: 1 (reg: 1)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 1
Total file size: 32 bytes
Total transferred file size: 32 bytes
Literal data: 32 bytes
Matched data: 0 bytes
File list size: 41
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 104
Total bytes received: 127

sent 104 bytes received 127 bytes 154.00 bytes/sec
total size is 32 speedup is 0.14
rsync: mkdir "/var/db/repos/gentoo/.tmp-unverified-download-quarantine" failed: Permission denied (13)
rsync error: error in file IO (code 11) at main.c(664) [Receiver=3.1.3]
Traceback (most recent call last):
File "/usr/lib64/python3.6/site-packages/portage/util/_async/AsyncFunction.py", line 39, in _run
result = self.target(*(self.args or []), **(self.kwargs or {}))
File "/usr/lib64/python3.6/site-packages/portage/sync/controller.py", line 169, in sync
taskmaster.run_tasks(tasks, func, status, options=task_opts)
File "/usr/lib64/python3.6/site-packages/portage/sync/controller.py", line 68, in run_tasks
result = getattr(inst, func)(**kwargs)
File "/usr/lib64/python3.6/site-packages/portage/sync/syncbase.py", line 311, in sync
return self.update()
File "/usr/lib64/python3.6/site-packages/portage/sync/modules/rsync/rsync.py", line 340, in update
dosyncuri, timestamp, opts)
File "/usr/lib64/python3.6/site-packages/portage/sync/modules/rsync/rsync.py", line 712, in _do_rsync
command.append(self.download_dir)
File "/usr/lib64/python3.6/site-packages/portage/sync/syncbase.py", line 125, in download_dir
self._download_dir = self.repo_storage.init_update()
File "/usr/lib64/python3.6/site-packages/portage/util/futures/_sync_decorator.py", line 21, in wrapper
return loop.run_until_complete(func(*args, **kwargs))
File "/usr/lib64/python3.6/site-packages/portage/util/_eventloop/EventLoop.py", line 833, in run_until_complete
return future.result()
File "/usr/lib64/python3.6/site-packages/portage/util/futures/compat_coroutine.py", line 113, in _next
future = self._generator.throw(previous.exception())
File "/usr/lib64/python3.6/site-packages/portage/repository/storage/hardlink_quarantine.py", line 65, in init_update
self._user_location + '/', update_location + '/'])
File "/usr/lib64/python3.6/site-packages/portage/util/futures/compat_coroutine.py", line 111, in _next
future = self._generator.send(previous.result())
File "/usr/lib64/python3.6/site-packages/portage/repository/storage/hardlink_quarantine.py", line 53, in _check_call
format(p.returncode, ' '.join(cmd)))
portage.repository.storage.interface.RepoStorageException: command exited with status 11: rsync -a --link-dest /var/db/repos/gentoo --exclude=/distfiles --exclude=/local --exclude=/lost+found --exclude=/packages --exclude /.tmp-unverified-download-quarantine /var/db/repos/gentoo/ /var/db/repos/gentoo/.tmp-unverified-download-quarantine/
>>> Syncing repository 'genpi64' into '/var/db/repos/genpi64'...
>>> Syncing repository 'sakaki-tools' into '/var/db/repos/sakaki-tools'...
/usr/bin/git fetch origin
/usr/bin/git fetch origin
error: cannot open .git/FETCH_HEAD: Permission denied
!!! git fetch error in /var/db/repos/genpi64
error: cannot open .git/FETCH_HEAD: Permission denied
!!! git fetch error in /var/db/repos/sakaki-tools

Action: sync for repo: gentoo, returned code = 1
Action: sync for repo: genpi64, returned code = 255
Action: sync for repo: sakaki-tools, returned code = 255


* emerge --sync failed
* Time statistics:
12 seconds for syncing
13 seconds total

* genup: Error: Caught signal - exiting

User avatar
sakaki
Posts: 523
Joined: Sun Jul 16, 2017 1:11 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Sat Feb 15, 2020 12:54 pm

Hi haaldemir,

yes, as of last week a new update is available, yes (with mesa-20.0.0_rc2 etc), which you can get via genup.

The genup program needs to be run as the root user, or by using sudo genup as the regular user - can I just check that is how you are invoking it? The errors you are getting seem to be permissions ones.

Best, sakaki

haaldemir
Posts: 58
Joined: Mon Jul 08, 2019 2:46 pm
Location: Istanbul, Turkey

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Sat Feb 15, 2020 8:00 pm

sakaki wrote:
Sat Feb 15, 2020 12:54 pm
Hi haaldemir,

yes, as of last week a new update is available, yes (with mesa-20.0.0_rc2 etc), which you can get via genup.

The genup program needs to be run as the root user, or by using sudo genup as the regular user - can I just check that is how you are invoking it? The errors you are getting seem to be permissions ones.

Best, sakaki
Hi Sakaki

I forget sudo, ahaa thank you. It takes too long 4 hours still working 280 of 303 complete. Is it normal ?

Thank you

User avatar
Gavinmc42
Posts: 4372
Joined: Wed Aug 28, 2013 3:31 am

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Sun Feb 16, 2020 12:17 am

It takes too long 4 hours still working 280 of 303 complete. Is it normal ?
Sounds about right, looked to be a big update this time.
Mesa 20 was a surprise ;)
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
sakaki
Posts: 523
Joined: Sun Jul 16, 2017 1:11 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Wed Mar 18, 2020 5:10 pm

Hello,

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

As always, you can burn the image (~1,763MiB compressed) to a microSD card (>=16GB), then boot your RPi3 or RPi4 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. As before, a 'lite' (CLI-only) image is also provided.

Here's a screenshot of the image running on a dual-display RPi4 B (click to show a higher resolution view):

Image

A changelog from the prior release image (with upgrade instructions) may be viewed here, but in summary:
  • Added the media-video/smtube package. This provides a simple web-based front end allowing YouTube videos to be searched and selected, which are then handed off to media-video/smplayer for playback. This, in turn, is configured to use media-video/mpv under the hood, and can play (on an RPi4 with a fast Internet connection) 1080p videos at 30fps without glitching (it can use both v4l2m2m and MMAL endpoints for appropriate video types). (It would be nice if the vanilla firefox or chromium browsers could make use of the v4l2m2m codec endpoints, but they currently cannot, in any straightforward manner, so this tool at least provides an option for those wishing to watch hi-res video in the near term.)
  • Dropped the suggested use of distcc-pump from /etc/portage/make.conf, following Gentoo bug 702146.
  • Added a first cut build of bzt's usbimager program (lightweight alternative to Etcher).
  • Turned on anti-aliasing and full hinting for screen fonts by default.
  • Made switching keyboard layouts more straightforward, by adding the xfce-extra/xfce4-xkb-plugin into the top panel bar, and pre-populating two initial layouts (gb and us) in the config accessed via Applications->Settings->Keyboard, Layout tab. Also added xfce-extra/xfce4-kbsetup; this package installs a service, activated upon graphical login, which initialises the user's preferred keyboard layouts (if these have been set up), as Xfce does not do that correctly at the moment.
  • Upgraded the shipped kernels, to bcm{rpi3,2711}-kernel-bis-bin-4.19.106.20200225, and boot firmware, to sys-boot/rpi3-64bit-firmware-1.20200212.
  • Various minor ebuild tidy-ups.
  • All packages brought up-to-date against the Gentoo tree, as of 4 Mar 2020. So e.g., www-client/chromium bumped to 82.0.4068.4, www-client/firefox to 73.0.1, app-office/libreoffice to 6.3.5.2 etc.
Users already on the prior 1.5.3 or earlier release can upgrade manually by following the instructions given here.

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).

sakaki

PS the bootable images are also available for download via PINN, for those who prefer that route, called gentoo64 and gentoo64lite there.

Edit: update screenshot
Last edited by sakaki on Sat Mar 21, 2020 12:56 pm, edited 1 time in total.

ronmon
Posts: 5
Joined: Sun Oct 20, 2019 8:00 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Thu Mar 19, 2020 4:55 pm

As usual, you do beautiful work and your instructions are extremely clear and well written.

Thank you, oh so much!

micro_martin
Posts: 1
Joined: Fri Mar 20, 2020 11:30 am

Error installing gdb for 64-bit Gentoo RPi3B

Fri Mar 20, 2020 11:47 am

I am trying to install gdb using "emerge gdb". However, after lots of compiling it fails with:

{standard input}:Assembler messages:
{standard input}:34616:Warning: end of file not at end of a line; newline inserted
{standard input}:35028:Error: unknown relocation modifier at operand 3 -- 'add x0,x1,:'
{standard input}:Error: open CFI at end of file; missing .cfi_endproc directive

I am using the 64-bit Gentoo update 1.5.2 from 27 Nov 2019. Gentoo is working fine itself. I can compile using gcc (version 9.2) but I cannot install gdb. Note, emerge is trying to install gdb-8.3.1.

If you could offer me any help I would be very grateful.

User avatar
sakaki
Posts: 523
Joined: Sun Jul 16, 2017 1:11 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Fri Mar 20, 2020 10:18 pm

The current sys-devel/gdb version is 9.1, and is available on the binhost (but not shipped on the image by default).

Try running genup to update your system to v1.5.4 (further notes here) and once done, emerge gdb - you should then find it is bringing in this binary package, if all is well.

hth, sakaki

User avatar
Gavinmc42
Posts: 4372
Joined: Wed Aug 28, 2013 3:31 am

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Sat Mar 21, 2020 3:09 am

Upgrading to 1.5.4 seems to fix some issues, 1.5.3 was getting glitchy and slow.
Have yet to test the Gentoo USB imager but the new Raspberry PI imager worked on Windows, no need for Etcher now.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
sakaki
Posts: 523
Joined: Sun Jul 16, 2017 1:11 pm

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Sat Mar 21, 2020 1:10 pm

Hi Gavinmc42,

USBImager is bzt's program (I just packaged it for Gentoo): so any comments on it, please post in this thread.

Best,

sakaki

ozbird
Posts: 13
Joined: Wed Dec 10, 2014 7:26 am

Re: Updated 64-bit Gentoo Image for RPi3 Released (now also for RPi3B+ and RPi4B)

Fri Apr 03, 2020 3:26 am

With the latest bunch of updates, it looks like some/all packages are limited to MAKEOPTS="-j1 -l1"?
e.g. from /var/log/portage/elog/summary.log:

Code: Select all

>>> Messages generated by process 9334 on 2020-04-03 14:17:22 AEDT for package app-editors/vim-8.2.0360:

WARN: prepare
Forcing MAKEOPTS='-j1 -l1'
/etc/portage/make.conf has MAKEOPTS="-j5 -l4" so it looks like something else is overriding it.

It's sad seeing the Loadavg. stuck at around 1 when there are four cores available. :(
(I bought the Pi 4 4GB to replace my ye olde Atom N270 box that is genuinely CPU limited: one core, two threads.)

Update: I interrupted the "genup" process and started it again; it now appears to be using all cores. :)

Return to “Gentoo”