| Selection | Testing | Setup | Top |
Need to revise
Websites for OpenSuSE installation:
I got the Vilros Basic Starter Kit for Raspberry Pi 4 (8Gb)
on amazon.com for $140 (2023-08-17). In the box:
Made in the UK
The instructions say to defer installing the heat radiators and the SD card until after the case has been assembled around the motherboard. In this case the order doesn't matter as much as for the RPi 3B.
Dis/assembling the case:
So far, I have never been able to put the OpenSuSE installation DVD on a USB stick and boot the RPi 4B or 3B. Even with USB booting enabled, I'm pretty sure that the ISO-9660 filesystem completely confuses the boot ROM. My next strategy will be, rather than installing OpenSuSE off the DVD, to install an image and then upgrade and reconfigure it. So which image do I want to download? Since I'm eventually going to put XFCE on the machine, I'm going to use the XFCE image.
This description of installing an image is actually a composite of quite a number of installation attempts. Do these steps on your laptop or desktop computer:
The name of the new machine will be needed in a few places. I'm
going to name this one Kaa
, after the python in Rudyard
Kipling's Jungle Book. Oops, the WAF (wife acceptance factor)
of this name was low. Now I'm calling it Beaver
; I have a
cute logo image for it from Wikipedia.
The containing directory for all of this is /s1/rasp-pi . The image file will be downloaded to here.
Knowing that I would have to repeat the installation procedure several times, I made a directory /s1/rasp-pi/config which matches up with Beaver's root. It has subdirectories ./etc ./home and ./root . Populate it with up-to-date instances of my hacked configuration files.
Downloading the image file. Start at the Hardware Compatibility List. If you're re-installing, check if there is an updated XFCE image.
raw. Download $imname.xz.sha256.asc $imname.xz.sha256 $imname.xz . The last one was about 1.2 GB and took almost 7 minutes to download.
raw. Try the command:
openSUSE Project Signing Key <opensuse@opensuse.org>. Which I'm supposed to have, so why couldn't I find it? Anyway, I cut corners; I trusted the imported key rather than either finding my existing copy or doing the research to reassure myself that this is really the real openSUSE Project Signing Key. Now the signature over $bname.xz.sha256 is accepted as valid.
ddfor more efficient writing:
Insert your SD card in the host's card slot.
Check carefully in log files which device the card is on. You want
the whole card, versus a partition (maybe only one) on the card.
In my case the device name is /dev/sda but /dev/mmcblk0 is used on
Intel NUCs. It's a good idea to double check with this command:
parted /dev/sda print
and verify that you have the correct device (and not, e.g. your
boot volume).
Write the decompressed image on the SD card; I'm using $bname to
represent its name:
dd bs=4M if=$bname of=/dev/sda iflag=fullblock oflag=direct status=progress
My card took 168 sec to copy 5.6GB, 33.2 MB/s. This is double
the speed of the cards from 2016 in the RPi-3B's, but 1/3 of the
measured speed in one review article. (Blame the card reader?)
The image has three partitions on /dev/sda1,2,3 already labelled EFI ROOT and SWAP; see /dev/disk/by-label/ . Having been burned several times when the device's major and minor numbers changed unexpectedly, I make a habit of mounting by the names in /dev/disk/by-label . But the labels have to be unique, so I put a suffix on the semantic parts, which is the first two letters of the hostname, and a digit just in case I need to replace the disc. For this host it will be BE1. Here's how to re-label the partitions; check in /dev/disk/by-label afterward to see if it's right:
The partitions are in order EFI, SWAP, ROOT. The root partition size is 5 MB; when you boot for the first time it will be expanded to fill the media. They give you 0.5GB swap, which should be fine for normal RPi-3B use, but if you expect to do big data things like compiling Firefox, now is a really good time to expand the swap partition. The EFI partition size is 67MB which is more than enough for SuSE (but more might be helpful on Debian or Gentoo, which put the kernel in the EFI partition).
Attention: in the not too distant future SuSE will switch to direct booting of a kernel+initrd unified image in the EFI partition, which can then be attested by your Trusted Platform Module (TPM2). Presumably the distributed image will be resized to match, but homebuilt partitions may need to be expanded.
Copy generic and Beaver-specific files into the image.
ssync is my wrapper for rsync that sets a more useful log format.
> fsck /dev/disk/by-label/EFI-BE1 # It passes
> fsck -f /dev/disk/by-label/ROOT-BE1 # It passes
> mount /dev/sda3 /mnt
> ssync -a /s1/rasp-pi/config/ /mnt/
> umount /mnt
Replace the SD card in the Raspberry Pi, connect anything that was disconnected, and turn on power.
It boots.
When shutting it down: systemctl poweroff
shuts down the OS and claims it is turning off power, but the red light
is still on and it's actually just halted. Upon power off the GPU will
blink the green light 10 times. Wait for it to finish before
disconnecting power. The need to wait is probably an urban legend, but
blinking assures you that the OS has done as much syncing as it's going
to and has given up control to EFI Runtime Services on the GPU.
I updated and installed DNS, /etc/hosts, /etc/ethers, etc. with Beaver's MAC address, fixed IP address, and appropriate hostgroups. On the next boot, Beaver got its correct address.
Tidbit: the image includes repository 'Open H.264 Codec (openSUSE Tumbleweed)'
One of my main goals was to validate the Raspberry Pi 4B in a desktop replacement role, which the RPi-3B's had a lot of trouble to do. As an early step, using the pristine image with a few packages added, I repeated the tests from my browser test procedure that I used in 2020 to try (unsucessfully) to find a browser that was satisfactory on RPi-3B. My conclusion is that the user experience of Firefox on RPI-4B (Beaver) is just as good as on a x86_64 Intel laptop (Acer Aspire 5, A515-54-51DJ, Intel Core i5-8265U, 2019). The RPi did use 2 to 3 times as much CPU, because it's slower and we're comparing elapsed seconds. But the RPi delivered the pages on time, and the CPU is there to be used. The page linked above has URLs to the pages used for testing. This was out of the box, lacking Jimc's codec collection:
Start up Firefox and shut it down. 15sec elap, 29sec CPU (sum of user + system time). CPU can be greater than elapsed time because multiple cores can be used (and usually are used).
Scrolling through a family of pages on Wikipedia with a lot of images but little Javascript and no advertising. 299sec elap, 317sec CPU. Completely normal, pages were displayed quicker than I could move the mouse to switch to the new tab.
Tests multimedia things that the browser should be able to do. Images (JPEG, PNG, GIF) were perfect. PDF was shown in the builtin viewer. MP3 was played; OGG was attempted but not played; WAV was just downloaded. Theora played but not the other video formats tried. More formats would have been played if I had installed my usual codecs first.
364 sec elap, 482 sec CPU. The test was to view the whole front page, then three text articles, and one video clip. It finished the test with no problems, good speed in all cases, not distinguishable from the experience on the Intel laptop. Only problem: couldn't play the video clip due to a missing codec.
Looked perfect except acid3 score was 97/100. Speed was normal. 212 sec elap, 66 sec CPU.
34 sec elap, 38 sec CPU, score 510 (555 is recent record high score).
Firefox on the Raspberry Pi 4B is working, unlike on the RPi-3B.
This is actually from a subsequent run of kernel 6.6.6 after upgrading to current packages and successful post_jump.
The random number generator was initialized.
It's using EFI v2.10 by Das U-Boot.
108.50 BogoMIPS (an underestimate).
Switched to clocksource arch_sys_counter. This was the only clocksource ever tried.
It's initializing KVM, i.e. this CPU has hardware virtualization.
The RPi 4 does not have a TPM (Trusted Platform Module).
raspberrypi-firmware soc:firmware: Attached to firmware from 2023-10-17T15:39:16
No sign that it would attempt to resume (de-hibernate) from disc if there were a hibernation image in the swap file.
Chrony startup: waitsync was botched. The RPi has no realtime clock, but the time is saved when it goes down, and various maneuvers are used to init the clock to the saved time as early as possible. Even so, this will be slow by however many hours the RPi was shut off. It takes a while for Chrony to be sure what time it is on the timeservers, longer than waitsync was configured to wait. But eventually it will step the clock (if chrony.conf has a makestep directive, as it should).
Permission problem on /var/lib/lightdm, added it to /etc/permissions.local .
# lightdm homedir for Xauthority files. Too bad you can't make this recursive. /var/lib/lightdm lightdm:lightdm 770 /var/lib/lightdm/.Xauthority lightdm:lightdm 600 /var/lib/lightdm/.cache lightdm:lightdm 755 /var/lib/lightdm/.cache/lightdm-gtk-greeter lightdm:lightdm 755 /var/lib/lightdm/.cache/lightdm-gtk-greeter/state lightdm:lightdm 644 /var/lib/lightdm-data lightdm:lightdm 770 /var/lib/lightdm-data/lightdm lightdm:lightdm 770
If you have a private configuration directory (/s1/rasp-pi/config for me) and, when installing the image, you overwrote /etc/passwd, /etc/shadow, /etc/group with the files from your own net, you would already have your own root password and ordinary users' identities. But I wanted to snoop and save files from the pristine image, so I didn't use the /s1/rasp-pi/config files on the first installation attempt.
User ID is root
, password is linux
. These work on
the console greeter and SSH. Presumably also the console TTY(s) and
the serial cable, but these were not tested this time around. Some
distros, but not OpenSuSE, have an ordinary user pre-configured and
do not allow root to log in directly.
Raspbian's ordinary userID is pi
and its password is
raspberry
.
Change to your usual root password immediately. If you have a
pre-configured ordinary user, change its password too, and/or replace
with your own identity and password. The command is
passwd $USER
.
(Omit this step if you already copied this and similar files onto
the SD card when it was mounted on the big computer.) From a normally
configured host like your laptop, install /root/.ssh, which will
authorize root (and yourself) to get on with publickey auth, and which
will pre-authorize your usual host keys.
rsync -a /root/.ssh beaver:/root/
(Give the root password for the last time.)
Wi-Fi has its needed driver (brcmfmac.ko) and firmware. It is up, but has not been configured with an ESSID and password, so it is not associated with any access point — and I'm not going to configure it, since Beaver has wired Ethernet.
/sys/class/bluetooth does exist, unlike on RPi-3B. But I wasn't able to discover the MAC address. Bluetooth is a can of worms, so let's leave Bluetooth setup for a later section, and use the wired USB keyboard and mouse.
You are now ready to dig into the software.
Kernel versions:
| Where | aarch64 | x86_64 |
|---|---|---|
| Image | 6.4.6 | -- |
| Repo | 6.4.6 | 6.4.11 |
| Hosts | 6.4.3 | 6.4.8 |
This image is fairly up to date; my hosts are not up to the minute (week, actually) because of an issue with version skew. I did these steps to install my desired software packages on Beaver.
slogin root@beaver (from the laptop): It lets me on. It's using the key agent on my laptop and /root/.ssh/authorized_keys that I installed while the memory card was still on the laptop. I could also have logged on at the console, but I can copy and paste to and from the session from an xterm.
My post_jump script is going to install /etc/passwd, /etc/shadow, /etc/group, which have my ordinary users plus root, all with their current passwords. It knows how to re-own files, changing the UID assignments on the image to the ones on my other hosts, per the configuration control system.
Storage statistics: During initial boot, a swap partition was added (0.5Gb) and the root partition was expanded to fill the remaining space. 3.8Gb is occupied; 55.4Gb free; 3.1Gb in reserve; 60.7Gb total.
Do any needed snooping and hacking on the pristine image.
Run post_jump (on the distro master site, Iris).
It did a normal-looking reboot, up until it loaded the kernel and
initrd, whereupon it allegedly
Failed to boot both default and fallback entries
.
(There is no fallback entry specified in the Grub menu, so it couldn't
boot that.)
This has been seen before. I will need to solve this problem before
I can proceed.
Update: somewhere in reconciling boot files, I got Iris' /boot/efi/EFI/BOOT/grub.cfg onto Beaver, and it gives the UUID of the root filesystem, which is on Iris, not Beaver. Fixing the UUID got it booting the OS from its own SD card. More details further on.
Beaver passes checkout.sh, my suite of operational tests of many runtime daemons. So the installation procedure is successful — with a few issues that haven't yet been dealt with.
The next set of features to be set up are:
I need to turn on onboard sound, and to evaluate whether I am going to use it for audio playback, or a USB sound module. The proceure to activate sound is documented: dtparam=audio=on in /boot/efi/extraconfig.txt , and the onboard sound does basically work, but it needs a more careful evaluation.
Also the HDMI audio channel has to be checked: it shows all the signs of being functional, but I need to move the RPi to the monitor (TV) that has HDMI audio.
The Raspberry Pi, as delivered, has no 3D acceleration and renders licensed formats, such as MPEG-2, in software, not on the GPU. I need to buy the extra-cost graphics license, and to run graphics benchmarks with and without it.
Enable graphics acceleration on Raspberry Pi 4B by Jian-Hong Pan (2023-06-03):
The OP is a developer on EndlessOS with Gnome desktop
environment. He put it on a RPi 4B, and he finds that it's
almost good enough to be a normal computer for daily usage
now.
Why almost
? Because it lacks the driver to
support the V3D GPU on BCM2711.
This blog post is a progress report: he has more issues to track down.
He applied a set of recently released patches (listed in the blog post) to the mainline Linux kernel version 5.15, and enabled CONFIG_DRM_V3D and CONFIG_DRM_VC4. Testing in the Ubuntu 21.10 RPi 4B image.
Jimc is repeating the tests on the OpenSuSE aarch64 kernel version 6.6.6.
GL_RENDERER: V3D 4.2.
The XMPP image has been seen to connect to the access point and receive a DHCP address. I want to get this working, because the upstairs audio playback node (which I very much want to modernize with a RPi) has a pathetic MOCA connection: it works for audio, but maintenance tasks are annoyingly slow because of the combination of a slow CPU and slow networking.
Update: Wi-Fi works completely normally, if correctly configured,
The video playback node needs a Bluetooth keyboard and mouse, for maintenance.
For audio playback I have my own software based on GStreamer. All the relevant components seem to be installed and just have to be checked. [Update: it's working fine.]
For video capture and playback I plan to install Kodi, assuming that video playback is satisfactory.
I plan to have a third RPi as my office desktop machine. My needs for CPU power are modest and the RPi is not wimpy so I expect this will go well. Also I use a compute server across the net when significant CPU power is needed.
| Selection | Testing | Setup | Top |
