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

[bomblord]

Yes, depending on the codec, I've found smplayer and kodi can be significantly smoother than vlc. Try smplayer, and see if that is any better for your use case.

Best, sakaki

Thank you for the info

[sakaki]

You can also try using V4L2 M2M (hardware-assisted) codec playback, for certain file types, by selecting:
Applications→Multimedia→RPi Video Player (HW Codecs):


The above is a screengrab from an older version of the image, but the player is still present on the latest one (and works on the RPi4 also, hence the slight change of name).

It's not really a full-featured player, just a proof-of-concept, but m2m support will be more broadly integrated soon.

Best, sakaki

[manemobiili]

Thanks sakaki!
I was a bit hesitant to start off rolling when last disk image was few months old. In the end genup went really well from minimal install to stumpwm desktop.
Edit: Dang it! How do i drive this thing

[manemobiili]

I was a little hesitant to start rolling when last image was 1 month old. Still, genup did it's thing and everything went well without any problems. Thanks sakaki!

[sakaki]

Migration of certain Gentoo directory paths

Hello,

I'm in the final stages of preparing a v1.5.2 release of the image, and as part of this have, following upstream policy [1,2], migrated certain Gentoo system paths, as follows:

• /usr/portage -> /var/db/repos/gentoo ($PORTDIR)
• /usr/portage/distfiles -> /var/cache/distfiles ($DISTDIR)
• /usr/portage/packages -> /var/cache/binpkgs ($PKGDIR)
• /usr/local/portage/<overlay> -> /var/db/repos/<overlay>

If you are currently using v1.5.1 or earlier of this image, please be aware that a fixup script has been added to the repo, which will migrate the directories on your system to the new locations for you (script here).

This fixup script will be run automatically, within a week at most, by a cron.weekly service already installed on your RPi. However, if you wish
to correct the directory locations immediately (or you have the weekly fixup service disabled), then simply issue the following commands on your RPi (if running as demouser, prefix them with sudo):

Code: Select all

pi64 ~ # emaint sync --repo genpi64
pi64 ~ # /etc/cron.weekly/fixup

Results may be viewed in /var/log/latest-fixup-run.log (the relevant fixup is number 0009, and lives at [3] pre-migration, and [4] post-migration). It does nothing on a system where the directories have already been migrated. (Also, if you are using any layman repos, note that these will not be moved.)

The migration script also ensures that /etc/portage/make.conf contains appropriate definitions for PORTDIR [5], PKGDIR and DISTDIR, and corrects the /etc/portage/make.profile symlink (so it still refers). It also leaves symlinks from the old to new locations, to ease migration (e.g., /usr/portage becomes a symlink to /var/db/repos/gentoo).

Because of the symlinks, any scripts you have that use the old locations should still work, but ideally, replace hardcoded references therein to the appropriate portageq calls. For example:

Code: Select all

#!/bin/bash
# My local script
PORTDIR="$(portageq get_repo_path / gentoo)"
PKGDIR="$(portageq pkgdir)"
DISTDIR="$(portageq distdir)"

Any issues, please post here or email me ([email protected])

Thanks!

sakaki

References

[1] https://bugs.gentoo.org/378603
[2] https://projects.gentoo.org/council/mee ... ummary.txt
[3] /usr/local/portage/genpi64/app-portage/weekly-genup/files/fixup-0009-migrate-portage-paths.sh
[4] /var/db/repos/genpi64/app-portage/weekly-genup/files/fixup-0009-migrate-portage-paths.sh
[5] Now deprecated, but still used by various downstream scripts.

[Gavinmc42]

Hi Sakaki,
Not sure what happened but all my Gentoo64's now sit on command line and don't start up the x11 desktop.
Been using the uSD's a lot so it could be wear, lots of file fixing on booting too.
Was also getting a lot of seg faults trying to "pip install" python libs.

Will acquire some new uSDs for 1.5.2 just in case.

[Gavinmc42]

Update,
Those uSD's that don't boot to desktop on Pi4, do work ok on Pi3's.
Time to roll back the beta eeprom files?
But just noticed there are some new ones.
Not sure why that would affect the Pi4's x11.

[sakaki]

Update,
Those uSD's that don't boot to desktop on Pi4, do work ok on Pi3's.
Time to roll back the beta eeprom files?
But just noticed there are some new ones.
Not sure why that would affect the Pi4's x11.

It doesn't seem likely that it is the uSD card, more likely the contents. If you have one of these cards you can spare, try writing a vanilla v1.5.1 image onto it (obviously, that'll delete the existing OS on there, so be sure to back up anything important first), and then booting this on an RPi4. Does this work OK and get you to a graphical desktop?

If it does, run "sudo genup" on there and leave it to do its thing (will take a few hours to complete). Reboot once done. Does that also get you to a graphical desktop?

It is technically possible that it is an issue with the beta updates (I leave the updater set to only 'critical' updates myself) to the RPi4's EEPROM, but also unlikely (since there'd likely be a flood of bug reports in that case).

Best, sakaki

[Gavinmc42]

Not sure what the issue is at the moment.
The usual sudo genup is failing with error messages, I got as high as kernel 4.19.84.
Will write a new 1.5.1 and try from that.

Trying now, got a PI4 to boot to desktop.

Edit - genup worked, now at 4.19.84

Tried

Code: Select all

sudo pip install --user pyglet

Got this

Collecting pyglet
Segmentation fault

Whoops, got my distributions mixed up - emerge is working.

[Gavinmc42]

Hi Sakaki,

OK boot mystery getting clearer.
Took my new Gentoo64 uSD made and working fine on a Pi4B2 and put it on my Pi4B4.
It start booting and then it stopped at the login prompt before getting a x11 desktop.

That 4B4 had been running a new Buster fully updated/upgraded and rpi-updated all day fine.
The only difference I can think of is the Pi4B4 has beta eeprom code, this 4B2 does not.

Preliminary conclusion is beta eeprom works with newest Buster Raspbian but not Gento64.
I will roll back to critical and retest.
Also have other non booting uSDs I can test too.
Might not have to buy more uSD's.

Might have to put my Gentoo64 netbooting server plans back a few months.

There is a new DVFS, voltage/frequency scaling that works on Buster.
The 4B4 was running about 12C cooler than the Gentoo64 4B2.
I don't overclock so it worked fine for me.

Not sure how you can roll that into Gentoo64, but something for you to keep an eye on.

Good news, Warzone2100 still works better in Gentoo64.

[Gavinmc42]

Once "critical" was /etc/default/rpi-eeprom-update then my Pi4B4 Gentoo64 booted and ran ok.
https://www.raspberrypi.org/documentati ... teeprom.md
It did take a boot and reboot to fix obviously.

Moral of the story - don't mess with this yet.

[sakaki]

Once "critical" was /etc/default/rpi-eeprom-update then my Pi4B4 Gentoo64 booted and ran ok.
https://www.raspberrypi.org/documentati ... teeprom.md
It did take a boot and reboot to fix obviously.

Moral of the story - don't mess with this yet.

Thanks for this. It'd be great if you could file a report on the relevant thread (or start a new one) about this, so the RPI engineers are aware: I'm obviously nervous that the current EEPROM beta doesn't get promoted to critical, until the underlying cause is discovered. As I'm in the final run-up to the v1.5.2 image release I unfortunately don't have the bandwidth to dive into this myself, but it would be sensible to put a marker down now.

Best, S.

[Gavinmc42]

I still have one Buster and one Gentoo64 uSDs that refuse to update/genup.
But that could be because of suspected security certificate issues.
These two were my main two working OS's so I will need to have a backup system.

If I can make the fault repeatable on clean installs and my other Pi4's I will report it.
But as you say it takes time to track this stuff down.
Have some time off this week I will see what I can find.

More important for me is to figure out rsync and servers.
This just highlighted to me how dependent I was getting on Gentoo64

[sakaki]

Hello,

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

In addition to the usual package version bumps, this update also includes (inter alia):

• (preliminary) support for MMAL from a 64-bit userland (including raspivid, raspistill, ffmpeg etc.);
• an EEPROM firmware auto-updater for the RPi4; and
• initial network setup for headless boot support.

A more detailed list of changes is provided below.

As always, you can burn the image (~1,842MiB 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):



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

• Added a service, rpi4-eeprom-updater, to automate the upgrading of the RPi4's bootloader and VL805 (USB) EEPROM firmware, patterned on the official rpi-eeprom deb. This service has no effect on the RPi3. For further details, please see this post.
• Added (preliminary!) MMAL 64-bit userland support, via the inclusion of 6by9's pointer-wrangling PR#586 into media-libs/raspberrypi-userland (he tagged it "RFC", but as the functionality provided is useful and reasonably orthogonal, I've merged it anyway ^-^). As a result, tools such as raspivid and raspistill are now bundled with the image! (So now if, for example, you have the optional camera module attached, you should be able to issue e.g. raspivid -v -o test.h264 -t 10000 -g 1). (For those interested, OpenMAX-IL is not yet supported in 64-bit.)
• Also turned on the mmal USE flag for media-video/ffmpeg, as the necessary support libraries and headers are now present (thanks to the above PR). So, for example, you could play back the above test.h264 file using ffplay -vcodec h264_mmal -i test.h264 (as well as via e.g. ffplay -vcodec h264_v4l2m2m -i test.h264 of course, since the V4L2-M2M h/w codec endpoints remain supported too).
• In line with Gentoo upstream, migrated a number of core system paths, as follows (for more details, please see this post):
  • /usr/portage -> /var/db/repos/gentoo ($PORTDIR)
  • /usr/portage/distfiles -> /var/cache/distfiles ($DISTDIR)
  • /usr/portage/packages -> /var/cache/binpkgs ($PKGDIR)
  • /usr/local/portage/<overlay> -> /var/db/repos/<overlay>
  and added a fixup to effect the migration for updating users as well.
• Added the rpi-onetime-startup service. This runs the script startup.sh from the top-level directory of the FAT filesystem in partition 1, if present, on the first boot (after partition resizing), having first disabled itself from future invocation. It is particularly intended to allow e.g. initial networking to be configured for users of headless systems, and to that end the bundled (/boot/)startup.sh script contains a number of (commented) examples of configuring the wired and wireless interfaces (using nmcli). To use, edit the startup.sh script (on e.g. a Windows or Linux desktop box) on the microSD card to which you have just written the image, prior to first using the card to boot your headless RPi3/4 (users booting the image on a system with attached mouse, keyboard and monitor do not need to do use this facility of course, since networking can be configured via the GUI, once booted).
• Added support for the Pimoroni Fan SHIM (a neat, solderless active-cooling daughtercard for the RPi4) to pyconfig_gen (which allows you to set the temperature setpoint for spin-up; the driver has a built-in 10°C hysteresis); also added support for hdmi_enable_4kp60 (allows 60Hz modes on (one) 4K HDMI output). Accessed via Applications->Settings->RPi Config Tool> on the image.
• In line with the deprecation (by its author) of wiringpi, removed this from the image, and in its place added dev-libs/pigpio's pigpiod daemon to the default runlevel. Its counterpart command-line tool pigs may be used to access the Pi's GPIO (a set of python library bindings for the underlying C library is provided also). wiringpi remains in the binhost, for now (so you can still emerge it if you wish).
• Following a suggestion by arizonadrscott (and the pattern used by Raspbian), set up groups and udev rules for GPIO, I2C and SPI, and made demouser a member of these groups. Also added some video group and serial-port aliasing udev rules, again following Raspbian. See sys-apps/rpi-gpio, sys-apps/rpi-i2c and sys-apps/rpi-spi; also sys-apps/rpi-serial and sys-apps/rpi-video for details. Added migration pkg_postinst() rules to join all wheel group members to the gpio, i2c and gpio groups, and dropped the (largely Pi-Top-specific) rpi3-i2cdev and rpi3-spidev services.
• Adopted more aggressive MAKEOPTS and MAKE_DEFAULT_OPTS values in /etc/portage/make.conf, as the restricted parallelism (conservatively) enforced in the last release turned out to be confusing for many new users.
• Added a fixup to turn off Xfce4-driven DPMS monitor power down, as this was causing (sometimes unrecoverable) monitor blanking during e.g. long genup runs. Thanks to Heeboo for the suggestion.
• As of v1.5.0 of the image, the custom x11-misc/arandr on the image installs an /etc/xdg/autostart entry, which invokes the config file ~/.screenlayout/default.sh (if one has previously been saved (from the arandr GUI) by the user). This is useful to create e.g. persistent dual-monitor layouts, but there was no (user-facing) way to stop it running if the commands therein were somehow inappropriate. However, in this release, any default.sh script is not run if the Ctrl key is held down during graphical login.
• Added usbhid.mousepoll=0 to /boot/cmdline.txt to improve mouse lag (reported for some setups); thanks to k3lt for the suggestion.
• Upgraded the shipped kernels, to bcm{rpi3,2711}-kernel-bis-bin-4.19.86.20191126, and boot firmware, to sys-boot/rpi3-64bit-firmware-1.20190925. Inter alia, the kernels now have CONFIG_STRICT_DEVMEM unset.
• Various minor ebuild tidy-ups (including making OpenRC deps conditional on -systemd USE (as requested by Avamander) etc.).
  > Note: the affected services do not yet have systemd unit files and so forth; this change is just to allow those who wish to e.g. cut over the 'lite' image to systemd boot, more easily so to do.
• All packages brought up-to-date against the Gentoo tree, as of 16 November 2019. So e.g., chromium bumped to 78.0.3904.50-r2, firefox to 70.0.1, libreoffice to 6.3.3.2 etc.

Users already on the prior 1.5.1 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: fix formatting

[Gavinmc42]

Thanks Sakaki,
Lots of useful hardware GPIO/i2c.. access rules now and that Pi camera interface needs some testing.
Nice to see Joan's pigpio software in Gentoo64 now, it's very useful.

Was on Khronos pages this week looking at OpenVX, 1.3 is out.
In theory Picameras and USB cameras should be both usable using the Linux driver.

All these changes make Gentoo64 1.5.2 now my focus for robot development.
All the pieces are in place or coming together.
Time to try to see if the Pony compiler can talk to the I/O via those rules.

[Gazzy]

Hi Sakaki,

When running the dispatch-conf after this update, the changes reset all my wifi reg dom
To GB, and also reset any changes I had in config.txt.

I used u to use the new versions, but may have been better to keep the old versions.

Just in case you didn’t know, the associated conf files reset wifi reg to gb, and wipe the config.txt to default.

But I think I have them worked out.

Thanks for all your work.
Gazzy

[sakaki]

When running the dispatch-conf after this update, the changes reset all my wifi reg dom
To GB, and also reset any changes I had in config.txt.

I used u to use the new versions, but may have been better to keep the old versions.

Just in case you didn’t know, the associated conf files reset wifi reg to gb, and wipe the config.txt to default.

Yes, that's the way dispatch-conf works - it asks you what to do about any configuration file that would be overwritten during a package upgrade (iff you have altered the previous version's copy of that file from its installed default). If you press "u", this will overwrite any changes you have made to that file.

You would have been safe, in the case of the files in question, to use "z" (instead of "u") to zap the new versions (translation: keep your old files), or alternatively (which is what I mostly do) use "m" to perform a merge of proposed changes.

I have some more notes on dispatch-conf here.

Best, sakaki

PS: I'll perhaps set dispatch-conf up to use meld by default (where available) for the next release of the image, much nicer to do merges that way ^-^

[Gavinmc42]

If you press "u", this will overwrite any changes you have made to that file.

That explains the keyboard country change back to UK layout.
The Pi4B4 and Gentoo64 is good enough I am browsing, coding and compiling while genup is emerging.
All of a sudden my keyboard is typing wrong characters

[Gazzy]

My keyboard maps did not change back to UK
Or my locale, but I have set up a new user.

Maybe they revert if you use demouser as your user.

I think my reverting had to do with the update of pyconfig, all the settings were defaulted with the update of pyconfig, thus my regdom was suggested to reset to UK and my config.txt was defaulted and had all extras removed.

Gazzy

[BRX7]

I am having some difficulties with getting to the web interface on my docker running pihole.
after upgrading from 1.5.2 rc5 to the latest 1.5.2 rc8

I get this message inside the docker container of pihole:latest

2019-12-02 12:25:12: (server.c.970) couldn't get 'max filedescriptors' Operation not permitted


Stopping lighttpd


ghttpd: no process found
.

portainer works fine. but not sure what is gone wrong here.

[BRX7]

I should add I ran hello world demo test for a webserver and I had the following problem
standard_init_linux.go:211: exec user process caused "exec format error"


I think its related to port 80 being blocked between docker and gentoo host

[sakaki]

2019-12-02 12:25:12: (server.c.970) couldn't get 'max filedescriptors' Operation not permitted


Stopping lighttpd

Per e.g. this article, seems like you may need to increase the maximum permitted number of open file descriptors.

Edit the file /etc/security/limits.conf, and add to the end (e.g.)

Code: Select all

* - nofile 32768

Save, restart, and try again.

hth, sakaki

[BRX7]

Ive tried that host and the docker image , i posted on Pihole discourse, permissions issue was mentioned, portainer on port 9000 works fine, but pihole web server doesn't.
I tried the same pihole docker image on manjaro arm and it works fine,
Was working perfectly on older 1.52 rc builds.
I cant see what can be blocking it.
Thanks

[sakaki]

There's not a lot changed across the various v1.5.2 revisions that would have a likely impact on you, other than the kernel. You can try masking this back to an earlier version if you like. To do so, put the following in /etc/portage/package.mask/kernel:

Code: Select all

~sys-kernel/bcm2711-kernel-bis-bin-4.19.86.20191126
~sys-kernel/bcm2711-kernel-bin-4.19.86.20191126
~sys-kernel/bcmrpi3-kernel-bis-bin-4.19.86.20191126
~sys-kernel/bcmrpi3-kernel-bin-4.19.86.20191126

Then:

Code: Select all

pi64 ~ # emerge -v1u sys-kernel/bcm2711-kernel-bis-bin sys-kernel/bcmrpi3-kernel-bis-bin

This should downgrade your kernel (but not affect userland). Once the emerge completes, reboot and try your app again.

hth, sakaki

[BRX7]

I ve tried it another pi which was also working and on that particular kernel and getting the same issue.
something else has changed ? maybe docker version needs to be bumped to fix.

tried clean reinstall and again same problem (reinstalling via PINN)

On the second pi latest kernel 3/12 and nexcloudpi is working fine, so maybe its something else