STICKY: Raspberry Pi OS (64 bit) beta test version feedback

[jahboater]

For sysbench you can do

Code: Select all

curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
sudo apt -y install sysbench

Then, on PIOS64, run it with something like:

Code: Select all

sysbench cpu --threads=4 --cpu-max-prime=100000 run

The version in the PIOS32 repository is much older, so I don't know if the results are comparable:

Code: Select all

sysbench --test=cpu --num-threads=4 --cpu-max-prime=100000 run

[rwcooper]

https://github.com/akopytov/sysbench

The instructions given on this site do not work as mysql is not available. Instead you have to install mariadb-dev. When you do this you will be given a list of other mariadb software to install as well. Once that is done it works. The syntax has changed as well, for example --num-threads is now --threads. There are other syntax changes as well. I hope this helps someone else...Randy

[CaptainMidnight]

Although this is a 'technical' post, posting here as it specifically relates to the latest Pi OS 64 BETA build.

Just loving the latest rpi-update download that I picked up today, overall impression is great - system boots without issue from a UAS compatible USB 3.0 attached M.2 256GB NGFF SATA drive. From purely my perspective and use, this system is already highly stable.

Generally system boot (to command line and somewhat customised) is expremely quick:

Code: Select all

$ systemd-analyze
Startup finished in 1.138s (kernel) + 2.053s (userspace) = 3.192s 
multi-user.target reached after 2.028s in userspace

I've noticed in this latest build, that the start of the LAN connection initialisation has reduced down to within the first 2 seconds, although there is still an additional 5 seconds delay before the interface is reported as up and ready:

Code: Select all

[    1.986330] bcmgenet: Skipping UMAC reset
[    1.987981] bcmgenet fd580000.ethernet: configuring instance for external RGMII
[    1.989134] bcmgenet fd580000.ethernet eth0: Link is Down
.........
[    7.102744] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

My question is can this additional 5 second delay be further reducd - could this be an inbuilt kernel spanning tree protocol forwarding delay?

As part of my customisation, various kernel modules are already blacklisted - one of those being 'stp', if this is as I believe spanning tree protocol within the kernel - is my kernel module blacklist file being implemented too late to take effect in the boot initialision of the LAN connecton - if it's not, specifically what other kernel elements could be at play here that I'm not aware of?

Just contemplating the benefits of creating my own custom kernel build (and all that entails), as apposed to continuing to use a kernel module blacklist file.

YES! it's only 5 seconds - I fully understand that, I'm just trying to confirm my thoughts and observations here.

EDIT: just to confirm in the rest of the missing dmesg output - after 2.8s there is no further reported activity, until the next report is at 7.102744 as above.

[mitchind]

Hi,

I've installed Raspberry Pi OS 64 bit (beta) on my Raspberry Pi 4 (4GB),
and tested Raspberry Pi camera with it,
but it is not working as expected.

Can you or anyone else confirm that raspistill and raspivid are working in current 64 bit build?

[6by9]

Hi,

I've installed Raspberry Pi OS 64 bit (beta) on my Raspberry Pi 4 (4GB),
and tested Raspberry Pi camera with it,
but it is not working as expected.

Can you or anyone else confirm that raspistill and raspivid are working in current 64 bit build?

None of MMAL (on which raspivid/still and Picamera rely) is currently working on 64 bit builds.
V4L2 is working.

[RonR]

Raspberry Pi 4B 4G 1.1

Linux raspberrypi 5.4.47-v8+ #1322 SMP PREEMPT Wed Jun 17 18:05:46 BST 2020 aarch64

BOOTLOADER: up-to-date
CURRENT: Mon 15 Jun 13:36:19 UTC 2020 (1592228179)

vcgencmd bootloader_config:

Code: Select all

[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

/boot/config.txt:

Code: Select all

 
dtoverlay=gpio-shutdown

Grounding GPIO3 while the system is running does a halt and leaves the red power LED on as expected

Grounding GPIO3 again restarts the system as expected.

Running halt from the command line extinguishes all LED's.
Grounding GPIO3 will not restart the system.
Power must be removed and reapplied to restart the system.

[mistermix]

I'm testing the 64-bit version here and removed everything from the desktop packages transforming into a lite version and it's running smoothly
using open media vault + kubernetes k3s, low processing, running several pods and no problems, to run local server is very good, good work.
I signed up here today just to thank u, and I'm waiting for an official Lite image, it could even be beta too

[CaptainMidnight]

Hi just a simple question before I go off kernel building, is the beta Pi OS (64 bit) using the standard 64-bit kernel that is available to custom build via the previously published GitHub https://github.com/raspberrypi/linux or has it been changed with regards to being able to use a 64 bit user space?

[dom]

Hi just a simple question before I go off kernel building, is the beta Pi OS (64 bit) using the standard 64-bit kernel that is available to custom build via the previously published GitHub https://github.com/raspberrypi/linux or has it been changed with regards to being able to use a 64 bit user space?

It's using the standard kernel you linked to. Just built with ARCH=arm64.

[CaptainMidnight]

It's using the standard kernel you linked to. Just built with ARCH=arm64.

Super, thanks for the confirmation.

[RonR]

Halt vs PowerOff

Halt and PowerOff are reversed:

halt performs a poweroff
poweroff performs a halt

'shutdown -h now' works correctly
'shutdown -P now' works correctly

[procount]

I just re-installed pios-64 and did sudo apt update & upgrade.

sudo halt - red power LED goes off, but HDMI screen displays a message saying "system halted", so the GPU is not shut down.
sudo poweroff - red power LED stays on, but no HDMI signal is output.

[RonR]

I just re-installed pios-64 and did sudo apt update & upgrade.

sudo halt - red power LED goes off, but HDMI screen displays a message saying "system halted", so the GPU is not shut down.
sudo poweroff - red power LED stays on, but no HDMI signal is output.

My major concern is not being able to restart after a halt without cycling the power.

[sakaki]

Congrats on getting PiOS64 into beta - have been trying it out on a Pi4 over the last few days, looks great!

One minor thing (which actually came up in testing the forthcoming 1.6.0 gentoo-on-rpi-64bit release on a Pi4, but happens on PiOS64 too), is pulseaudio's behaviour with the headphone output under a dual monitor setup / fkms.

Under the current rpi-5.4.y kernel / firmware (in the 64-bit OS anyway, haven't tested a 64/32 or 32/32 system - so apologies if this isn't 64-bit specific), each of the HDMI0 and HDMI1 port's audio, and the onboard headphone jack, show up as separate ALSA devices. Without pulseaudio installed (or the pulseaudio daemon suspended) all three can be used without issue (e.g. via speaker-test). So far so good.

However, when pulseaudio is running, it detects all three sinks OK, but does not allow output to the headphone port. What's particularly odd is that when the Pi4 is booted with only one HDMI port connected, the headphone jack works under pulseaudio just fine (and can be switched via pavucontrol etc). Also, adding e.g. a USB-to-headset adaptor to the system also works (even with two monitors connected) under pulse.

I appreciate pulseaudio isn't on the PiOS64 image as shipped, but I wonder if something at the driver level might be going on here (given that pulse locks all the ALSA endpoints when it starts up). I have worked around this (sort-of) with the following udev rule (which works on PiOS64 too), placed in /lib/udev/rules.d/79-rpi-pulseaudio-fixes.rules:

Code: Select all

SUBSYSTEM!="sound*", GOTO="end"
ACTION!="change", GOTO="end"
KERNEL!="card*", GOTO="end"

# remove the 'internal' sound form factor, so more descriptive
# names are used in pulseaudio for bcm... entries
ENV{SOUND_FORM_FACTOR}=="internal", ENV{SOUND_FORM_FACTOR}=""

# uncomment to ignore audio sink on HDMI1, even if present, so that
# headphones + HDMI0 audio will work in pulseaudio - temporary workaround
ATTRS{id}=="b2", ENV{PULSE_IGNORE}="1"

LABEL="end"

This stops the "b2" endpoint from being picked up by pulseaudio at all (making a two-monitor system look like a single-monitor system from the PoV of audio), which allows the user to access the HDMI0 monitor's audio, and the built-in headphone jack, successfully. Obviously not ideal but probably better than 2 HDMI outputs, but no headphones.

best,

sakaki

[rtfmoz]

Installed on Pi4 4GB v1.1 no issues, tested the following packages...

Telegram Desktop Client
apt install telegram-desktop
NGINX w/PHP
apt install nginx php-fpm
Tested above integration with phpinfo() - using this guide.
Disabled GUI login and installed remote access using RDP successfully with
apt install xrdp ; reboot
to provide on-demand desktop environment.
Installed Node RED using their install script
https://nodered.org/docs/getting-started/raspberrypi

Connection with w10 built-in RDP client works flawlessly.
PiOS GUI scaling defaults for high resolution monitors worked nicely (4K screen).

[SkywalkingZulu]

I've tested out the 64 bit upgrade on my Rpi4B. So far I'm seeing better speeds(Could also be the placebo effect ). I'm optimising for mining alt coins and working as my fall back server for some of my projects. So far haven't run into too many problems. There is however a few projects that need you to follow different instructions from the main instructions because of differences in packaging. E.g I had to look for people in forums that were using 64 bit Rpi's and tried installing packages/libraries and had issues.

[dickon]

So I've just installed this on a brand new 8G Pi 4, and it seems to work quite well. vlc is running, clearly unaccelerated, but is quite happy to stream BBC News HD from a tvheadend instance I have as a PVR. Windowed, anyway. Full-screen (in X), it plays fine when the control panel is displayed; when that disappears the video is thoroughly scrambled. Interestingly, an 'import -screen broken.png' takes forever, and produces a perfectly sensible image.

[maxbit]

Hi there,

in the file share https://downloads.raspberrypi.org/raspi ... 020-05-28/, I can only find the full versions. Is there either a prebuilt lite image of PiOS 64 bit or a package diff such that I can remove all the unnecessary packages myself? I was not able to find any information on this, help is much appreciated. Thank you.

Kind regards.

[dickon]

Not yet, but you can get remarkably close by:

* (qemu-)debootstrap debian/arm64 into a new filesystem,

* Copying /etc/apt/sources.list.d from the full version of PiOS64 into your new debootstrap,

* chroot into it, apt update, some apt descriptions dance dpkg will complain about next; I forget, but the page it points to is clear,

* From a PiOS32 Lite image, dpkg --get-selections | grep '\sinstall$' | grep -v ':armhf' | chroot debootstrap dpkg --set-selections; this gets you all the Pi-specific packages I can never remember the names of (raspberrypi-sys-mods and the like) plus all the other packages the Lite versions install by default,

* chroot, and apt-get dselect-upgrade

* Patch up to taste, as you would for any other debootstrapped OS.

Works well, but does require you to know what you're doing, and it isn't for the faint-hearted. I think it took me about half an hour or so the other night, mostly waiting for packages to install.

[RonR]

Is there either a prebuilt lite image of PiOS 64 bit or a package diff such that I can remove all the unnecessary packages myself?

Based on comments in another topic, I've been using the following script to remove the desktop components from Raspberry Pi OS (64 bit).

rm-desktop:

Code: Select all

#!/bin/bash

errexit()
{
  echo ""
  echo "$1"
  echo ""
  exit 1
}

if [ $(id -u) -ne 0 ]; then
  errexit "Must be run as root user: sudo $0"
fi
apt update
apt purge -y x11-common gnome-menus gnome-icon-theme gnome-themes-standard gnome-themes-extra-data libfm4 vlc vlc-data
apt purge -y hicolor-icon-theme desktop-base desktop-file-utils bluealsa
apt autoremove -y
rm -r /usr/share/X11/xorg.conf.d
rm -r /usr/share/raspi-ui-overrides/applications
rm -r /usr/share/fonts/truetype/freefont
rm -r /usr/share/fonts/truetype/piboto
rm -r /usr/share/fonts/truetype/quicksand

There's also a problem in Raspberry Pi OS (64 bit) with halt and poweroff being reversed. The following script will correct that.

fix-halt-64:

Code: Select all

#!/bin/bash

errexit()
{
  echo ""
  echo "$1"
  echo ""
  exit 1
}

if [ $(id -u) -ne 0 ]; then
  errexit "Must be run as root user: sudo $0"
fi
if [[ "$(uname -n)" != "raspberrypi" || "$(uname -m)" != "aarch64" ]]; then
  errexit "O/S is not Raspberry Pi OS (64 bit)"
fi
if [[ ! -h /sbin/halt || ! -h /sbin/poweroff ]]; then
  errexit "halt and/or poweroff not a symlink"
fi
mv /sbin/halt /sbin/halt_orig
mv /sbin/poweroff /sbin/poweroff_orig
cat <<EOF > /sbin/halt
#!/bin/bash

/bin/systemctl poweroff
EOF
cat <<EOF > /sbin/poweroff
#!/bin/bash

/bin/systemctl halt
EOF
chmod +x /sbin/halt /sbin/poweroff

[maxbit]

Thanks for the suggestions! I will try these tomorrow. As I'm setting up a cluster of 5 Pis, I would be more happy to have a way to create an img file I can just flash several files, but if that's not possible I'm gonna automate your suggestions using Ansible.

I've also considered using pi-gen, but I couldn't figure out how to specify for which architecture to build. By some issues on Github, I've seen that its able to build 64 bit, but it seems like a 32-bit Debian in the Dockerfile is needed or something and additionally, I just cannot find the trigger setting for armhf vs arm64. Or is that not public yet for pi-gen? That would be the most easy way to build a 64-bit lite image, I think.

On another note:
I've noticed that on the full image, the terminal still states armv7. Why is that so? I thought 64bit version of PiOS brings 64-bit userland as well.

Kind regards.

[RonR]

As I'm setting up a cluster of 5 Pis, I would be more happy to have a way to create an img file I can just flash several files, but if that's not possible I'm gonna automate your suggestions using Ansible.

Raspberry Pi OS (64 bit) looks pretty healthy from here. Since I run mostly headless, I've also been hoping to see a Lite image available soon.

I've noticed that on the full image, the terminal still states armv7. Why is that so? I thought 64bit version of PiOS brings 64-bit userland as well.

I get:

Code: Select all

Linux raspberrypi 5.4.47-v8+ #1322 SMP PREEMPT Wed Jun 17 18:05:46 BST 2020 aarch64

[dickon]

That's more or less why I did what I did: I don't need or want a full GUI -- xterm, evilwm, firefox, and a few support tools do it for me -- so produced an unofficial 'lite' version the way I did.

I don't at all approve of your rm -r of the font directories, BTW. /usr/share/fonts/truetype/freefont -- to pick one example -- is part of fonts-freefont-ttf; why not remove --purge that?

[RonR]

I don't at all approve of your rm -r of the font directories, BTW. /usr/share/fonts/truetype/freefont -- to pick one example -- is part of fonts-freefont-ttf; why not remove --purge that?

It should have been removed by the purge operation, but apt complained it couldn't remove the directory because it wasn't empty (it contained a single hidden file, named .user IIRC).

[dickon]

.uuid, if mine's the same as yours (which I imagine it is). Interesting. I haven't much cared, by the looks of it.