Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Bootable 64-bit RPi3/Pi4 Gentoo image (OpenRC/Xfce/VC4) Pt 2
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4  
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM
View previous topic :: View next topic  
Author Message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Sat Nov 09, 2019 5:31 pm    Post subject: Reply with quote

orion777, Gavinmc42

The default autounmask behaviour in Portage changed with 2.3.77 (which the latest genup will have pulled in). Per release notes here:

Code:
portage-2.3.77
--------------
* The emerge --autounmask option is now disabled by default, except for
  portions of behavior which are controlled by the --autounmask-use and
  --autounmask-license options. For backward compatibility, previous
  behavior of --autounmask=y and --autounmask=n is entirely preserved.
  Users can get the old behavior simply by adding --autounmask to the
  make.conf EMERGE_DEFAULT_OPTS variable.

_________________
Regards,

sakaki
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Fri Nov 22, 2019 12:00 pm    Post subject: Reply with quote

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:
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:
#!/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 (sakaki@deciban.com)

Thanks!

References

[1] https://bugs.gentoo.org/378603
[2] https://projects.gentoo.org/council/meeting-logs/20180729-summary.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.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
n1ese
n00b
n00b


Joined: 29 Sep 2019
Posts: 26

PostPosted: Sat Nov 23, 2019 12:35 am    Post subject: Reply with quote

Sakaki wrote:
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:
pi64 ~ # emaint sync --repo genpi64
pi64 ~ # /etc/cron.weekly/fixup

I don't appear to have the script on my system. I just finished manually upgrading my 1.5.1 system today with genup.

Code:
ganymede /home/n1ese # emaint sync --repo genpi64
>>> Syncing repository 'genpi64' into '/usr/local/portage/genpi64'...
/usr/bin/git fetch origin
Already up to date.
=== Sync completed for genpi64

Action: sync for repo: genpi64, returned code = 0


ganymede /home/n1ese # /etc/cron.weekly/fixup
bash: /etc/cron.weekly/fixup: No such file or directory


Also, could you help me understand what is going on here while updating?

Code:
* Updating @world set (for new versions, or changed use flags)...
Calculating dependencies... done!

WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

dev-util/meson:0

  (dev-util/meson-0.52.0:0/0::gentoo, ebuild scheduled for merge) conflicts with
    <dev-util/meson-0.52 required by (gnome-base/dconf-0.32.0-r1:0/0::gentoo, installed)
    ^               ^^^^

>>> Auto-cleaning packages...
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Sat Nov 23, 2019 1:53 am    Post subject: Reply with quote

n1ese wrote:
I don't appear to have the script on my system. I just finished manually upgrading my 1.5.1 system today with genup.

Do you have the dev-embedded/rpi-64bit-meta package weekly-genup USE flag unset by any chance (check with "eix rpi-64bit-meta")?
If so, the package app-portage/weekly-genup won't be pulled in automatically (and it is this which in turn provides the cron script and fixup files).

However, you can just download and run the relevant fixup script file directly if you like in this case; from here.
n1ese wrote:
Also, could you help me understand what is going on here while updating?

This warning is benign: it just means that a newer version of dev-util/meson (0.52.0) is available and, in the absence of other constraints, could be updated to; however, one or more installed packages is preventing this (here, per the output, it is gnome-base/dconf-0.32.0-r1, which requires <dev-util/meson-0.52, due to this commit). As such, the version installed will remain at 0.51.2 pro tem.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
n1ese
n00b
n00b


Joined: 29 Sep 2019
Posts: 26

PostPosted: Sat Nov 23, 2019 2:03 am    Post subject: Reply with quote

Sakaki wrote:

Do you have the dev-embedded/rpi-64bit-meta package weekly-genup USE flag unset by any chance (check with "eix rpi-64bit-meta")?

It is not unset via the USE flag but not installed.

Code:
ganymede /home/n1ese # eix rpi-64bit-meta
[I] dev-embedded/rpi-64bit-meta [1]
     Available versions:  (~)1.5.0-r9 (~)1.5.1-r7{tbz2} (~)1.5.2-r2{tbz2} {apps +boot-fw +core +innercore +kernel-bin pitop -porthash +weekly-genup +xfce}
     Installed versions:  1.5.2-r2{tbz2}(05:56:43 PM 11/22/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -weekly-genup)
     Homepage:            https://github.com/sakaki-/gentoo-on-rpi-64bit
     Description:         Baseline packages for the gentoo-on-rpi-64bit image

[1] "genpi64" /usr/local/portage/genpi64
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Sat Nov 23, 2019 2:27 am    Post subject: Reply with quote

n1ese wrote:
It is not unset via the USE flag but not installed.

I think it is unset; look at the "Installed versions" line in your reported output from eix ("weekly-genup" has a minus sign in front of it):
n1ese wrote:
Code:
Installed versions:  1.5.2-r2{tbz2}(05:56:43 PM 11/22/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -weekly-genup)

_________________
Regards,

sakaki
Back to top
View user's profile Send private message
n1ese
n00b
n00b


Joined: 29 Sep 2019
Posts: 26

PostPosted: Sat Nov 23, 2019 2:31 am    Post subject: Reply with quote

Sakaki wrote:
n1ese wrote:
It is not unset via the USE flag but not installed.

I think it is unset; look at the "Installed versions" line in your reported output from eix ("weekly-genup" has a minus sign in front of it):
n1ese wrote:
Code:
Installed versions:  1.5.2-r2{tbz2}(05:56:43 PM 11/22/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -weekly-genup)

Where would I have it unset? I haven't modified the global USE flag in make.conf other than to set 'python' in order for gpsd to install. Otherwise, it is a very clean, and updated as of today, 1.5.1 install of your image.
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Sat Nov 23, 2019 2:35 am    Post subject: Reply with quote

n1ese wrote:
Where would I have it unset? I haven't modified the global USE flag in make.conf other than to set 'python' in order for gpsd to install. Otherwise, it is a very clean 1.5.1 install of your image.

Have a look in /etc/portage/package.use/rpi-64bit-meta to start with.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
n1ese
n00b
n00b


Joined: 29 Sep 2019
Posts: 26

PostPosted: Sat Nov 23, 2019 2:42 am    Post subject: Reply with quote

Sakaki wrote:
n1ese wrote:
Where would I have it unset? I haven't modified the global USE flag in make.conf other than to set 'python' in order for gpsd to install. Otherwise, it is a very clean 1.5.1 install of your image.

Have a look in /etc/portage/package.use/rpi-64bit-meta to start with.

Oh yeah, I'm dumb. Forgot I disabled all updates since I don't have a permanent internet connection on this device. Forgive me. :oops:
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Sat Nov 23, 2019 2:56 am    Post subject: Reply with quote

No worries, glad you got it tracked down ^-^
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
n1ese
n00b
n00b


Joined: 29 Sep 2019
Posts: 26

PostPosted: Mon Nov 25, 2019 2:05 am    Post subject: Reply with quote

Sakaki, something has changed in a recent update and I can't figure out how to fix it. On a fresh 1.5.1 install, emerge will ask me to autounmask packages but recent updates force me to manually unmask them.

For example, let's look at gpsd:

Fresh 1.5.1 install:

Code:
# emerge --ask gpsd

Local copy of remote index is up-to-date and will be used.
 * Last emerge --sync was 93d 1h 14m 20s ago.

These are the packages that would be merged, in order:

Calculating dependencies \

!!! Problem resolving dependencies for sci-geosciences/gpsd                   ... done!

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by gpsd (argument)
=sci-geosciences/gpsd-9999 **

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.

Would you like to add these changes to your config files? [Yes/No]


1.5.2-r3{tbz2}(08:31:50 AM 11/24/2019) does not do this, it says everything is unmasked due to missing keyword and I have to manually unmask:

Code:
# emerge --ask gpsd

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "gpsd" have been masked.
!!! One of the following masked packages is required to complete your request:
- sci-geosciences/gpsd-9999::gentoo (masked by: missing keyword)
- sci-geosciences/gpsd-3.19::gentoo (masked by: missing keyword)
- sci-geosciences/gpsd-3.18.1::gentoo (masked by: missing keyword)
- sci-geosciences/gpsd-3.17-r4::gentoo (masked by: missing keyword)
- sci-geosciences/gpsd-3.17-r3::gentoo (masked by: missing keyword)

# echo "=sci-geosciences/gpsd-9999 **" >> /etc/portage/package.accept_keywords/zzz_via_autounmask
# emerge --ask gpsd

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    *] sci-geosciences/gpsd-9999  USE="X bluetooth cxx dbus ipv6 ncurses python qt5 shm sockets udev usb -debug -latency-timing -ntp -static -test" GPSD_PROTOCOLS="aivdm ashtech earthmate evermore fury fv18 garmin garmintxt geostar gpsclock greis isync itrax mtk3301 navcom nmea0183 nmea2000 ntrip oceanserver oncore passthrough rtcm104v2 rtcm104v3 sirf skytraq superstar2 tnt tripmate tsip ublox" PYTHON_TARGETS="python2_7 python3_5 python3_6"

Would you like to merge these packages? [Yes/No]
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Mon Nov 25, 2019 2:12 am    Post subject: Reply with quote

Hi n1ese,

I think this is the same point I responded to above?

Basically, the autounmask behaviour of Portage changed with v2.3.77 (release notes), which your update will have pulled in.

To get the old behaviour back, edit your /etc/portage/make.conf and add to the bottom:
Code:
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --autounmask"

_________________
Regards,

sakaki
Back to top
View user's profile Send private message
n1ese
n00b
n00b


Joined: 29 Sep 2019
Posts: 26

PostPosted: Mon Nov 25, 2019 2:20 am    Post subject: Reply with quote

Sakaki wrote:
I think this is the same point I responded to above?

Basically, the autounmask behaviour of Portage changed with v2.3.77 (release notes), which your update will have pulled in.

To get the old behaviour back, edit your /etc/portage/make.conf and add to the bottom:
Code:
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --autounmask"

Ahh. yes. You are correct. I'm sorry once again, I know I read this earlier. :oops:
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Wed Nov 27, 2019 11:48 pm    Post subject: Reply with quote

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.

For a screenshot of the image running on a dual-display RPi4 B, please see here.

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 thread on the Raspberry Pi forums (here).

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

sakaki
Back to top
View user's profile Send private message
n1ese
n00b
n00b


Joined: 29 Sep 2019
Posts: 26

PostPosted: Sat Nov 30, 2019 10:35 pm    Post subject: Reply with quote

Sakaki, what would be the best way to remove bluetooth? Kernel support can stay.
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Sun Dec 01, 2019 10:11 pm    Post subject: Reply with quote

n1ese wrote:
Sakaki, what would be the best way to remove bluetooth? Kernel support can stay.

The simplest way would just be to start the pyconfig_gen app (Applications -> Settings -> RPi Config Tool), select the "Interfaces" tab, uncheck "Enable bluetooth (disables serial port)", and then click "Save and Exit" (being sure to confirm changes upon reboot when prompted).

This currently causes "dtoverlay=pi3-disable-bt" to be written to /boot/config.txt

I believe (though have not personally confirmed) that this will also work on the Pi4, despite the "pi3-" prefix, per this StackExchange post.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
n1ese
n00b
n00b


Joined: 29 Sep 2019
Posts: 26

PostPosted: Sun Dec 01, 2019 11:13 pm    Post subject: Reply with quote

Sakaki wrote:

The simplest way would just be to start the pyconfig_gen app (Applications -> Settings -> RPi Config Tool), select the "Interfaces" tab, uncheck "Enable bluetooth (disables serial port)", and then click "Save and Exit" (being sure to confirm changes upon reboot when prompted).

This currently causes "dtoverlay=pi3-disable-bt" to be written to /boot/config.txt

I believe (though have not personally confirmed) that this will also work on the Pi4, despite the "pi3-" prefix, per this StackExchange post.

Oh, I disabled this way a while ago. I was referring to all the software dependencies and so forth. I'm not sure how to remove blueman for instance.
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 340

PostPosted: Mon Dec 02, 2019 12:00 am    Post subject: Reply with quote

n1ese wrote:
Oh, I disabled this way a while ago. I was referring to all the software dependencies and so forth. I'm not sure how to remove blueman for instance.

Well, since e.g. blueman is pulled in by the dev-embedded/rpi-64bit-meta package (with xfce USE), the simplest thing might be to create a local overlay copy of this ebuild, and omit anything (like blueman) you don't want.

Or alternatively, you can also create /etc/portage/profile/package.provided (NB not simply /etc/portage/package.provided, that won't work); and put in it (e.g.):
Code:
net-wireless/blueman-99999

(no = or >= prefix!) and then forcibly unmerge blueman. And so on for any other deps you don't want.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
roylongbottom
n00b
n00b


Joined: 13 Feb 2017
Posts: 61
Location: Essex, UK

PostPosted: Mon Dec 02, 2019 4:33 pm    Post subject: Reply with quote

Hi Sakaki

Is there a command that clearly identifies that v1.5.2 is installed? I wanted to know after noting the peculiar result, identified below, using the lscpu command. To me, it looks as though my main Gentoo SD card has been updated, with such as gcc now 9.2.0 and Chromium 78.0, then Linux being updated from:

Code:
Wed Sep 25 23:13:36 2019
Linux pi64 4.19.67-v8-174fcab91765-p4-bis+ #2 SMP PREEMPT Tue Aug 27 13:58:09 GMT 2019 aarch64 GNU/Linux

To
Code:
Sun Dec  1 10:26:49 2019
Linux pi64 4.19.80-v8-3492a1b00349-p4-bis+ #2 SMP PREEMPT Tue Oct 22 13:59:52 GMT 2019 aarch64 GNU/Linux

To
Code:
Sun Dec  1 17:33:57 2019
Linux pi64 4.19.86-v8-c078c64fecb3-p4-bis+ #2 SMP PREEMPT Tue Nov 26 14:00:29 GMT 2019 aarch64 GNU/Linux


Running lscpu via the last two provided the following details. Results using the first Linux did not include Vulnerability entries and neither did details from an older Gentoo SD card (still Linux pi64 4.19.66).

Code:
Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           3
Model name:                      Cortex-A72
Stepping:                        r0p3
CPU max MHz:                     1500.0000
CPU min MHz:                     600.0000
BogoMIPS:                        108.00
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Vulnerable
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm crc32 cpuid

_________________
Regards

Roy
Back to top
View user's profile Send private message
n1ese
n00b
n00b


Joined: 29 Sep 2019
Posts: 26

PostPosted: Mon Dec 02, 2019 5:43 pm    Post subject: Reply with quote

roylongbottom wrote:
Is there a command that clearly identifies that v1.5.2 is installed?

Run: eix rpi-64bit-meta

Code:
ganymede /home/n1ese # eix rpi-64bit-meta
[I] dev-embedded/rpi-64bit-meta [1]
     Available versions:  (~)1.5.0-r9 (~)1.5.1-r7{tbz2} (~)1.5.2-r8{tbz2} {apps +boot-fw +core +innercore +kernel-bin pitop -porthash -systemd +weekly-genup +xfce}
     Installed versions:  1.5.2-r8{tbz2}(04:21:26 PM 11/28/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -systemd -weekly-genup)
     Homepage:            https://github.com/sakaki-/gentoo-on-rpi-64bit
     Description:         Baseline packages for the gentoo-on-rpi-64bit image

[1] "genpi64" /usr/local/portage/genpi64
Back to top
View user's profile Send private message
roylongbottom
n00b
n00b


Joined: 13 Feb 2017
Posts: 61
Location: Essex, UK

PostPosted: Tue Dec 03, 2019 8:51 am    Post subject: Reply with quote

n1ese wrote:
roylongbottom wrote:
Is there a command that clearly identifies that v1.5.2 is installed?

Run: eix rpi-64bit-meta

Code:
ganymede /home/n1ese # eix rpi-64bit-meta
[I] dev-embedded/rpi-64bit-meta [1]
     Available versions:  (~)1.5.0-r9 (~)1.5.1-r7{tbz2} (~)1.5.2-r8{tbz2} {apps +boot-fw +core +innercore +kernel-bin pitop -porthash -systemd +weekly-genup +xfce}
     Installed versions:  1.5.2-r8{tbz2}(04:21:26 PM 11/28/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -systemd -weekly-genup)
     Homepage:            https://github.com/sakaki-/gentoo-on-rpi-64bit
     Description:         Baseline packages for the gentoo-on-rpi-64bit image

[1] "genpi64" /usr/local/portage/genpi64


Thanks, that's what I see on my Pi 4.
_________________
Regards

Roy
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM All times are GMT
Goto page Previous  1, 2, 3, 4
Page 4 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum