Hi,

many thanks for your request. Basically DietPi on Raspberry Pi devices is a Raspbian Lite and it will be support. As well it's planned to create 64bit images for RPi2 PCB1.2 and up.

See https://dietpi.com/phpbb/viewtopic.php?p=25160#p25160

Joulinar on 28 May 2020

So we may start to have some work on it

FusionPlmH on 28 May 2020

Lol, copy&paste from forum:

I'm was just checking the 64bit beta OS. It is not called Raspbian, lets see which repo they use: https://downloads.raspberrypi.org/raspios_arm64/images/raspios_arm64-2020-05-28/
...
Lol, it's default Debian:

deb http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free
deb http://deb.debian.org/debian buster-updates main contrib non-free

Actually makes sense. Raspbian was actually only created since the first RPi1 (and RPi Zero now) are armv6hf which is not supported by Debian. For ARMv7 + ARMv8 boards there is no point in using a different distro. All RPi specific firmware/kernel packages, special board-feature/GPU builds of things like Kodi, ffmpeg etc, are all provided by the archive.raspberrypi.org repo and have nothing to do with Raspbian.

I think this means that we need to change our code in many places so that we do not assume RPi <=> Raspbian anymore but instead check /etc/os-release for whether it's Raspbian or Debian.

GitHub repo: https://github.com/raspberrypi/Raspberry-Pi-OS-64bit

MichaIng on 28 May 2020

I've started working on this: #3617

RPi is now detected based on the existence of a device tree file, which is required to boot any RPi with official kernel. I wanted to allow correct detection as well when chrooting into such image or using systemd-nspawn, hence it must not depend on /proc or /sys content which one would use usually. Checking for a device tree file looked like the most compatible, still quite accurate solution. Basically it must be an ondisk file (or content) which is only present on RPi images (as much assured as we can be) while being present on most of them, even when e.g. customising it, e.g. removing the APT kernel package and installing via rpi-update only, or compiling oneself. If someone finds a more accurate/failsafe/better method, I'm open to change it. Note that this check is only reached of no /etc/.dietpi_hw_model_identifier is present, which is created during DietPi-PREP for all non-RPi models.
On RPi, there is a new global variable G_RASPBIAN introduced which equals 1 by default and 0 if /etc/os-release contains ID=debian. Also here in rare circumstances theoretically this file can be wrong, so the choice is whether to assume Raspbian by default (and check for Debian explicitly) or the other way round. For now, where Raspbian is still the most used image, we'll assume it by default.
ToDo: Implement into DietPi-Survey, so we can see how the share between both versions develops over time and could and differentiate benchmark results between both, which might be quite interesting.

Now the new variable needs to be rolled out into our scripts, most importantly the one for APT sources.list creation/change. Means we'll need to go through every G_HW_MODEL call, see where we do some Raspbian-only step if we find RPi and in case check for G_RASPBIAN instead or additionally. Puhh... will take some hours, lets see 😅.

MichaIng on 22 Jun 2020

sounds like quite a lot of search > find > replace > next 😂

Joulinar on 22 Jun 2020

❤1

Good that we have grep and https://github.com/MichaIng/DietPi/search?q=G_HW_MODEL&unscoped_q=G_HW_MODEL 😄.

MichaIng on 22 Jun 2020

Support ready for review/testing. I'll now create an image and test DietPi-PREP compatibility by this.

MichaIng on 23 Jun 2020

Let me know if you need something tested. Otherwise I will download Raspberry OS 64bit and run PREP script

Joulinar on 23 Jun 2020

👍1

Otherwise I will download Raspberry OS 64bit and run PREP script

Already in progress 😃, would be great if you could test the resulting image instead.

The image can run on all RPi models from RPi1 v1.2 on, those have an ARMv8-capable CPU.

MichaIng on 23 Jun 2020

Currently I have a RPi3B+ and RPi4B 4GB only. Don't have that much SBC's :smile:

Joulinar on 23 Jun 2020

Here we go: https://dietpi.com/downloads/images/testing/DietPi_RPi-ARMv8-Buster.7z

A note to all testers:

This is bloody alpha on several layers!
Kernel is a snapshot from the current in-dev RPi Linux 5.4 branch, possibly this commit: https://github.com/raspberrypi/firmware/tree/62fc8c01165a80021054a430182b504f7b877c2d
Many think that you expect from Raspbian (and DietPi RPi) images have not yet been finished/ported to 64-bit. See the bug tracker for Raspberry Pi OS (64-bit) for known issues: https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues
DietPi code is based on current dev branch, support for Debian-based RPi images (which Raspberry Pi OS (64-bit) is) has been added in one full day of searching, coding, reviewing and testing, so bear with me if I might have overseen something 😉.

All RPi models from RPi2 v1.2 and up (excluding RPi Zero) are supported, hence all which have an ARMv8-capable CPU: https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications

MichaIng on 24 Jun 2020

ok first observation. On boot, the system tries to login as user pi automatically.

20200624_201847

Joulinar on 24 Jun 2020

👍1

Oh, there must be some [email protected] drop-in left:

systemctl cat getty@tty1

Found it:

cat /etc/systemd/system/[email protected]/autologin.conf
[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin pi --noclear %I $TERM

=> e.g. on SSH session

rm /etc/systemd/system/[email protected]/autologin.conf
systemctl daemon-reload
systemctl restart getty@tty1

Done by PREP script: https://github.com/MichaIng/DietPi/commit/3f4cc7b0e14d275fe82b7974fce78e10a22e0eb2

Image repacked with removed "pi" autologin.

MichaIng on 24 Jun 2020

sorry for delay. I used the old image still. attached the install output from CLI.

RPi64bit.txt

I tried to change NTP to my Router, but this is failing. Same behaviour once installation finished using dietpi-config

root@DietPi:~# dietpi-config
[  OK  ] DietPi-Config | Setting in /boot/dietpi.txt adjusted: CONFIG_NTP_MIRROR=Gateway
[ SUB1 ] DietPi-Set_software > ntpd-mode (2)
[FAILED] DietPi-Set_software | No local gateway detected. Reverting NTP mirror back to system defaults.
[  OK  ] DietPi-Set_software | Setting in /boot/dietpi.txt adjusted: CONFIG_NTP_MODE=2
[FAILED] ntpd-mode 2 | An issue has occurred
[  OK  ] DietPi-Run_NTPD | systemctl restart systemd-timesyncd
[  OK  ] DietPi-Run_NTPD | systemd-timesyncd synced
[  OK  ] Network time sync | Completed

Joulinar on 24 Jun 2020

👍1

I used the old image still.

Jep that is perfectly fine, no difference besides the removed autologin.

I tried to change NTP to my Router, but this is failing.

Good find 👍, a syntax issue (local does not allow to assign and alter a variable in one call, ; required): https://github.com/MichaIng/DietPi/commit/66f937ab3e4e2edba74918bd8107162c36078de0

MichaIng on 24 Jun 2020

how did you like to continue from here? Not sure what to test currently. Do we need to run thru all software title to ensure they are running on Raspberry OS 64bit? I already found WireGuard not working. I guess due to kernel dependency not fully available yet. Maybe I'm wrong.

Joulinar on 25 Jun 2020

Yes WireGuard currently fails as the is no matching headers package available yet for the arm64 kernel package: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/
Amiberry requires as well new pi64 target builds.
OpenTyrian can/needs to be pulled from Debian repo (is not available on Raspbian): https://packages.debian.org/search?searchon=names&keywords=opentyrian
DXX-Rebirth need to be rebuild for arm64 or in general as an update, otherwise disabled for arm64 for now.

And 3rd party installers might not yet be prepared, e.g. Pi-hole, PiVPN, Docker.

MichaIng on 25 Jun 2020

ok let's wait on the further development of Raspberry OS 64bit.

Joulinar on 25 Jun 2020

This is awesome! :)

camdenorrb on 29 Jun 2020

Just managed to install on running on raspberrypi 3b+ , with pihole and unbound , it working like a charm performance over better than Ubuntu 20.04 64bit and dietpi 32bit system

FusionPlmH on 1 Jul 2020

👍1

Many thanks for testing. Awesome. Please let us know if you face any issues at a later time or if any expected feature is missing.

MichaIng on 1 Jul 2020

How I missed this earlier I don't know, but will share some other results after many weeks' time on and off getting a 64-bit OS to run correctly that would execute the DietPi conversion script successfully. Summary:

Starting with the new Raspberry Pi OS 64-bit on Raspberry Pi 3 B+, I could run the conversion script - but the amount of bloat that was removed was quite high.
Starting with the new Raspberry Pi OS 64-bit on Raspberry Pi 4, I could run the conversion script, but the subsequent reboot would fail.
Starting with the vanilla Debian image in UEFI mode vis-a-vis https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html was very fast and ran the conversion script just fine. The resultant image was small and easy to reproduce.
I plan on testing the alpha image offered here on the Raspberry Pi 4 and compare the results to the process in step #3 above but with the RPi 4 firmware https://github.com/pftf/RPi4/releases instead.

@MichaIng - will this ultimately help meet your objectives, or is this testing redundant with previous efforts?

irousom on 6 Jul 2020

👍1

Starting with the new Raspberry Pi OS 64-bit on Raspberry Pi 3 B+, I could run the conversion script - but the amount of bloat that was removed was quite high.

Indeed, the current 64-bit image is a huge fully fledged desktop image, so not the best start. However there will be a Lite version for sure at a later time, when a final release comes closer.

Starting with the new Raspberry Pi OS 64-bit on Raspberry Pi 4, I could run the conversion script, but the subsequent reboot would fail.

Strange, that worked quite fine for our testing image. Did you face any error messages or some display (or serial console) output on failing boot? Since that image contains future version bootloader/kernel/firmware packages, the essential parts should not be touched.

Starting with the vanilla Debian image in UEFI mode vis-a-vis https://pete.akeo.ie/2019/07/installing-debian-arm64-on-raspberry-pi.html was very fast and ran the conversion script just fine. The resultant image was small and easy to reproduce.

Not sure if UEFI has any benefit here, however good to know it works. Yes result for sure is cleaner. Cleanest and what I aim for mid/long-term is creating our images from scratch via debootstrap which allows to still install bootloader+kernel+firmware from official repositories, archive.raspberrypi.org in this case.

I plan on testing the alpha image offered here on the Raspberry Pi 4 and compare the results to the process in step #3 above but with the RPi 4 firmware https://github.com/pftf/RPi4/releases instead.

While this is generally interesting and might bring some future benefits, we don't aim to go with experimental firmware and IMO the use for UEFI here is currently minimal. But at least we can take care that DietPi-PREP is compatible with an RPi UEFI images in general and probably the RPi foundation is gonna pick it up by times as well.

From my side, most important is that our scripts and software installers work as expected with the new official Raspberry Pi OS 64-bit, as this is a fundamental difference compared to Raspbian and we needed to change a lot of code throughout DietPi 🙂.

MichaIng on 6 Jul 2020

Start test with x64 version
I mount old NTFS drive without issue, and share with samba without problem
add drive to fstab
But after restart the drive is not mounted again, need to mount manually
And in samba I have access to the share but not see the content anymore
I check multiple time the config and all seems correct, and work perfectly on x86 version
waiting for my new hard drive for testing with Ext4 partition

magloui on 7 Jul 2020

pls can you have a look to /etc/fstab how the entry looks like for your drive. Usually it should be auto mounted as soon as someone is trying to access

Joulinar on 7 Jul 2020

👍1

pls can you have a look to /etc/fstab how the entry looks like for your drive. Usually it should be auto mounted as soon as someone is trying to access

I check in the x86 config fstab
UUID=E69EB5EF9EB5B87F /mnt/plex ntfs noatime,lazytime,rw,permissions,nofail,noauto,x-systemd.automount

In X64 is not the same
UUID=E69EB5EF9EB5B87F /mnt/plex ntfs mft_zone_multiplier=1,fmask=0177,dmask=077,nls=utf8,errors=continue,noatime,noauto 0 0

But after copy x86 in the fstab of x64 and reboot, issue exactly the same, no automount and samba return an empty link

But may be it's mistake work on the system only since 2 week ;-)

magloui on 7 Jul 2020

UUID=E69EB5EF9EB5B87F /mnt/plex ntfs mft_zone_multiplier=1,fmask=0177,dmask=077,nls=utf8,errors=continue,noatime,noauto 0 0

But this is not the result of dietpi-drive_manager. The x86 is what dietpi-drive_manager adds, containing x-systemd.automount which is responsible for automount. Please run dietpi-drive_manager 3 on the x64 system which should enable automount.

MichaIng on 7 Jul 2020

Ok I manually mount drive, clean up and i mount drive with dietpi-drive_manager, I saw system install ntfs-3g and after my drive is mounted all the time, I used and samba correctly show disk content
Thank's

magloui on 8 Jul 2020

👍1

Since I was reinstalling everything anyway, I decided to give this one a try.

1.Initial flash and install to SD works.
2.Moving everything to a USB SSD with the latest bootloader work as well.
3.SSH is functional as well.
4.Resize of the RootFS to use the full SSD capacity works as well.
5.Ethernet works, Internet connectivity test as well.
6.The following apps were installed sucessfuly and are working without any issues:
-vsFTPD
-RealVNC Server
-SABNzbd
-nzbhydra2
-Nextcloud
-Sonarr
-Radarr

I'll update this as I move along with configuring the Pi4.

Pillendreher on 15 Jul 2020

❤1 👍1

Many thanks for testing and feedback!

MichaIng on 15 Jul 2020

One issue I've been able to reproduce: Whenever I upload files to the SSD via FTP, my SSH client suddenly turns very sluggish (there's a noticeable pause between key strokes turning into letters). Connecting via VNC, the system itself is sluggish as well. The cursor is moving slowly, the file manager opens five seconds after clicking on the icon.

htop has the load average of the last minute at 1.71.

Pillendreher on 15 Jul 2020

Which file system is on the SSD?
VNC is sluggish only during file upload or in general?
Which VNC server do you use? TigerVNC or RealVNC?
And which desktop?

Sorry for question bombardment, but those could all be relevant 😉.

MichaIng on 15 Jul 2020

Which file system is on the SSD?

ext4

VNC is sluggish only during file upload or in general?

only during the file upload. Otherwise is very quick. The same goes for SSH btw.

Which VNC server do you use? TigerVNC or RealVNC?

RealVNC

And which desktop?

I'm afraid I don't know what you mean - the Raspberry Pi is not set up with a monitor and I didn't install another UI. Under dietpi-config => Display Options => Display Resolution I'm using the standard "vc4-kms-v3d-pi4 : OpenGL | 1920 x 1080"

Sorry for question bombardment, but those could all be relevant 😉.

No worries at all, I'm just glad I can be of help.

Pillendreher on 15 Jul 2020

Okay, I'm not sure how CPU intense FTP usually is (I use SFTP for everything), also of course it depends on transfer rate, as the SSD write speed very likely is not the limiting factor. Have you tried other file transfer methods, just to compare?

ext4 and RealVNC should be best options, although, are those very large files you upload (GiB sizes) or many smaller/usual ones?

With RealVNC, a desktop environment is installed, if you didn't choose one explicitly, its LXDE, so the lightest option. However desktop and VNC do not play a role here since the FTP transfer and/or writes through USB to SSD ext4 fs is the culprit.

Ah and did you try another USB port, respectively compared USB3.0 with USB2.0?

MichaIng on 16 Jul 2020

Screenshot_20200716-215007_Chrome
Now just update the pihole to v5.1 result like this , and I have been try to uninstall and install it

FusionPlmH on 16 Jul 2020

I had the same yesterday after doing the update on a normal 32bit image. Restart your system, close browser and clear cache.

Joulinar on 16 Jul 2020

Screenshot_20200717-020522_Chrome
Screenshot_20200717-020528_Chrome

Now i have been restall all the dietpi + pihole + unbound

i use unbound as my own primary dns server

now i face another issues like

after use pihole v5.1

i was not able to input my local ipv6 dns server ::1#5335 address at the pihole web admin page

here is my unbound config:
https://github.com/FusionPlmH/unbound/blob/master/pi-hole.conf

FusionPlmH on 16 Jul 2020

I don't think this is related to DietPi. Might be better to check on PiHole board.

Joulinar on 16 Jul 2020

I don't think this is related to DietPi. Might be better to check on PiHole board.

just checking on pihole board , the answer look like "No need for ipv6 loopback when ipv4 is available",seems this answer is acceptable for me .

FusionPlmH on 16 Jul 2020

Okay, I'm not sure how CPU intense FTP usually is (I use SFTP for everything), also of course it depends on transfer rate, as the SSD write speed very likely is not the limiting factor. Have you tried other file transfer methods, just to compare?

ext4 and RealVNC should be best options, although, are those very large files you upload (GiB sizes) or many smaller/usual ones?

With RealVNC, a desktop environment is installed, if you didn't choose one explicitly, its LXDE, so the lightest option. However desktop and VNC do not play a role here since the FTP transfer and/or writes through USB to SSD ext4 fs is the culprit.

Ah and did you try another USB port, respectively compared USB3.0 with USB2.0?

Oh my, this is embarassing....I think I figured out what was happening....

I was outside yesterday and pushed a movie file (30 gb) to the Pi over Wifi. Naturally, the connection wasn't the best. I think the whole sluggishness was caused due to the simple fact that I was maxing out the connection to the Pi with the upload and therefore ssh/vnc appeared sluggish because there was not enough bandwith left.

I just tried both downloading and uploading big files to and from the Pi via both Samba and FTP over Gigabit Ethernet and didn't encounter any issues.

Consider this issue irrelevant for now. I'll give it another try with my laptop over wifi in the house just to make sure my theory is correct...

Pillendreher on 16 Jul 2020

😄1 👍1

No worries, great that you found the root 😃.

MichaIng on 16 Jul 2020

Hello... I am having issues with wifi. I have found that a headless install does not seem to work by just entering in the details before first boot as I could not ssh or find the pi 4 on the network.

So I reinstall and change nothing:
On first boot, I set up wifi and it then "updates" dietpi, but I think it downloads and installs 32 bit stuff (downloads and replaces a lot of stuff in /boot). I setup installing only proftpd and it reboots me. I then cannot connect to wifi, with it being "not found" in the dietpi-config network menu. I think there is an issue with the detecting an update system, does it need to be pointing to a 64bit download place instead?

Edit I just tried with the 32bit image and I have the same issue... Ill open a new issue

CactiChameleon9 on 20 Jul 2020

I guess related to #3685 and seems to be fixed

Joulinar on 20 Jul 2020

👍1

Image has been updated: https://dietpi.com/downloads/images/testing/DietPi_RPi-ARMv8-Buster.7z

Based now on DietPi master/stable branch
Based on now released stable RPi Linux kernel 5.4

I'd call it beta phase now since there are still feature missing on "Raspberry Pi OS (64-bit)" in general and its the first official Linux 5.4 release.

MichaIng on 21 Jul 2020

🎉2

That's great news. I assume I'll have to start fresh to install. Ill do that as soon as libreoffice online compiles for my nextcloud.

CactiChameleon9 on 21 Jul 2020

Image has been updated: https://dietpi.com/downloads/images/testing/DietPi_RPi-ARMv8-Buster.7z
* Based now on DietPi master/stable branch

* Based on now released stable RPi Linux kernel 5.4
I'd call it beta phase now since there are still feature missing on "Raspberry Pi OS (64-bit)" in general and its the first official Linux 5.4 release.

Thank you! Any chance to update without having to do a complete re-install?

Pillendreher on 21 Jul 2020

No need to start fresh, simply do:

G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=master' /boot/dietpi.txt

to switch to master branch. This is effective with next DietPi release.

apt update
apt full-upgrade

to upgrade kernel packages.

MichaIng on 21 Jul 2020

👍1

No need to start fresh, simply do:
G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=master' /boot/dietpi.txt
to switch to master branch. This is effective with next DietPi release.
apt update
apt full-upgrade
to upgrade kernel packages.

To clarify: does this allow users of the 32-bit version to upgrade to the 64-bit version in-place, or does this only apply for users of the previous 64-bit image?

csolisr on 21 Jul 2020

This applies for 64bit image only.

Joulinar on 21 Jul 2020

You in fact cannot upgrade/switch from 32-bit to 64-bit. Raspbian (Raspberry Pi OS 32-bit) and the new Raspberry Pi OS 64-bit are fundamentally different, the whole system is build up on two different major repositories (Raspbian armhf vs Debian arm64).

The underlying OS is btw independent from DietPi version/branch vise-versa. DietPi simply detects detects if Raspbian or Debian and acts accordingly (since DietPi v6.31).

MichaIng on 21 Jul 2020

apt full-upgrade

No need to start fresh, simply do:
G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=master' /boot/dietpi.txt
to switch to master branch. This is effective with next DietPi release.
apt update
apt full-upgrade
to upgrade kernel packages.

root@DietPi:~# G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=master' /boot/dietpi.txt
[  OK  ] G_CONFIG_INJECT | Setting in /boot/dietpi.txt adjusted: DEV_GITBRANCH=master
root@DietPi:~# apt update
Hit:1 https://deb.debian.org/debian buster InRelease
Get:2 https://deb.debian.org/debian buster-updates InRelease [51.9 kB]
Hit:3 https://download.mono-project.com/repo/debian buster InRelease
Get:4 https://deb.debian.org/debian-security buster/updates InRelease [65.4 kB]
Hit:5 https://archive.raspberrypi.org/debian buster InRelease
Get:6 https://deb.debian.org/debian buster-backports InRelease [46.7 kB]
Get:7 https://deb.debian.org/debian buster-backports/main arm64 Packages.diff/Index [27.8 kB]
Get:8 https://deb.debian.org/debian buster-backports/main armhf Packages.diff/Index [27.8 kB]
Get:9 https://deb.debian.org/debian buster-backports/main arm64 Packages 2020-07-21-0801.04.pdiff [596 B]
Get:10 https://deb.debian.org/debian buster-backports/main arm64 Packages 2020-07-21-1404.14.pdiff [174 B]
Get:10 https://deb.debian.org/debian buster-backports/main arm64 Packages 2020-07-21-1404.14.pdiff [174 B]
Get:11 https://deb.debian.org/debian buster-backports/main armhf Packages 2020-07-21-0801.04.pdiff [588 B]
Get:12 https://deb.debian.org/debian buster-backports/main armhf Packages 2020-07-21-1404.14.pdiff [174 B]
Get:12 https://deb.debian.org/debian buster-backports/main armhf Packages 2020-07-21-1404.14.pdiff [174 B]
Fetched 221 kB in 2s (117 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
root@DietPi:~# apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@DietPi:~#

Did I do something wrong?

EDIT:

root@DietPi:~# uname -r
5.4.51-v8+

Pillendreher on 21 Jul 2020

Nope everything fine then. The firmware/kernel packages were released already yesterday, so depending on when you booted the image the first time this has been upgraded automatically. I just recognised today 😄.

MichaIng on 21 Jul 2020

👍1

Nope everything fine then. The firmware/kernel packages were released already yesterday, so depending on when you booted the image the first time this has been upgraded automatically. I just recognised today 😄.

Oh, that's it then - my Raspberry Pi 4 was shutd down since yesterday afternoon and the first boot today was me trying to update the image.

Pillendreher on 21 Jul 2020

apt full-upgrade

No need to start fresh, simply do:
G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=master' /boot/dietpi.txt
to switch to master branch. This is effective with next DietPi release.
apt update
apt full-upgrade
to upgrade kernel packages.

root@DietPi:~# G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=master' /boot/dietpi.txt
[  OK  ] G_CONFIG_INJECT | Setting in /boot/dietpi.txt adjusted: DEV_GITBRANCH=master
root@DietPi:~# apt update
Hit:1 https://deb.debian.org/debian buster InRelease
Get:2 https://deb.debian.org/debian buster-updates InRelease [51.9 kB]
Hit:3 https://download.mono-project.com/repo/debian buster InRelease
Get:4 https://deb.debian.org/debian-security buster/updates InRelease [65.4 kB]
Hit:5 https://archive.raspberrypi.org/debian buster InRelease
Get:6 https://deb.debian.org/debian buster-backports InRelease [46.7 kB]
Get:7 https://deb.debian.org/debian buster-backports/main arm64 Packages.diff/Index [27.8 kB]
Get:8 https://deb.debian.org/debian buster-backports/main armhf Packages.diff/Index [27.8 kB]
Get:9 https://deb.debian.org/debian buster-backports/main arm64 Packages 2020-07-21-0801.04.pdiff [596 B]
Get:10 https://deb.debian.org/debian buster-backports/main arm64 Packages 2020-07-21-1404.14.pdiff [174 B]
Get:10 https://deb.debian.org/debian buster-backports/main arm64 Packages 2020-07-21-1404.14.pdiff [174 B]
Get:11 https://deb.debian.org/debian buster-backports/main armhf Packages 2020-07-21-0801.04.pdiff [588 B]
Get:12 https://deb.debian.org/debian buster-backports/main armhf Packages 2020-07-21-1404.14.pdiff [174 B]
Get:12 https://deb.debian.org/debian buster-backports/main armhf Packages 2020-07-21-1404.14.pdiff [174 B]
Fetched 221 kB in 2s (117 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
root@DietPi:~# apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@DietPi:~#

Did I do something wrong?

EDIT:

root@DietPi:~# uname -r
5.4.51-v8+

Lol did the same here. Was trying to update the pi. But it was already updated . Saw it with uname -r too

MattL0 on 23 Jul 2020

😄1

Hey team, Thank you for your passion! Just a small feedback. I have installed 64bit image on my PRI4 4GB, to USB-flash drive(a little bit new way). I had got first setup error 'cause of USB-install (I guess). Throught dietpi-drive_manager, I resized usb-flash and all is working on succesfully.

codeandmedia on 23 Jul 2020

I'm sorry I haven't been able to really test the image recently...my laptop has started acting up (losing its connection to its SSD) and I've spent the last week swapping SSDs and flashdrives back and forth between the Pi4, my laptop and my desktop PC just to figure out what was causing the issue...I've never done so much imaging, cloning and restoring in my whole life 😄

Anything in particular that needs testing with the current image? The only issue I've noticed recently is that for the first boot after shutting the Pi4 down with "shutdown -h now", something always seems to get "stuck" (I don't know what exactly; my router tells me that the Pi is not part of my home network even though the ethernet cable is attached as always) and the Pi doesn't seem to boot. A "reset" (unplugging it and plugging it back in) leads to a flawless boot though...I don't know if that's a side effect of the mass storage boot I'm using though.

Pillendreher on 25 Jul 2020

😄1

@codeandmedia
You mean the USB drive you flashed DietPi on was not expended on first boot automatically? Could you please paste the output of the following command:

cat /var/tmp/dietpi/logs/fs_partition_resize.log

@Pillendreher
Are you able to attach a screen to check the system messages on shutdown? Else you could investigate by enabling boot persistent system logs. I'd recommend to do this via persistent systemd-journal (instead of rsyslog):

Uninstall DietPi-RAMlog via dietpi-software
reboot
mkdir /var/log/journal
shutdown -h now or shorter: poweroff 😉
After reset journalctl should show you the systemd logs from shutdown phase.

To revert:

rm -R /var/log/journal
Install DietPi-RAMlog via dietpi-software

MichaIng on 25 Jul 2020

@MichaIng yes, I'm using simple USB-flash drive instead of SDcard, and first boot was getting issue with install, but after manually resizing all is ok, and working on correctly.

root@Pi:~# cat /var/tmp/dietpi/logs/fs_partition_resize.log
Removed /etc/systemd/system/local-fs.target.wants/dietpi-fs_partition_resize.service.
Disk /dev/sda: 28.9 GiB, 31029460992 bytes, 60604416 sectors
Disk model: DataTraveler 3.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x99cc74d8

Old situation:

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1         8192   532479   524288  256M  c W95 FAT32 (LBA)
/dev/sda2       532480 60604415 60071936 28.7G 83 Linux

/dev/sda2:
New situation:
Disklabel type: dos
Disk identifier: 0x99cc74d8

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1         8192   532479   524288  256M  c W95 FAT32 (LBA)
/dev/sda2       532480 60604415 60071936 28.7G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
Syncing disks.
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/sda2 is now 7508992 (4k) blocks long.

codeandmedia on 25 Jul 2020

Ah since you resized through dietpi-drive_manager, it used the same service, overwriting the initial log file. From what we see, the partition got resized successfully before (old and new situation are the same) but the resize2fs seems to have failed for some reason as it would otherwise show some "nothing to do!" in its output. I'll keep that in mind in case facing some other similar reports. Probably when using external USB drives, we need to add a second sleep between partition resize and file system resize. I'll also compare with raspi-config method, if they have some workaround or different method to cover such cases.

EDIT: Interesting, their script expends the partition only, but not the file system, even that the output states it differently: https://github.com/RPi-Distro/raspi-config/blob/master/usr/lib/raspi-config/init_resize.sh
Ah, dedicated service, so code comments are a bid misleading: https://github.com/RPi-Distro/pi-gen/blob/master/stage2/01-sys-tweaks/files/resize2fs_once
So there is even a reboot between partition resize and file system resize, nothing that can be compared with out simple generic machine script.

MichaIng on 25 Jul 2020

👍1

@Pillendreher
Are you able to attach a screen to check the system messages on shutdown? Else you could investigate by enabling boot persistent system logs. I'd recommend to do this via persistent systemd-journal (instead of rsyslog):
1. Uninstall `DietPi-RAMlog` via `dietpi-software`

2. `reboot`

3. `mkdir /var/log/journal`

4. `shutdown -h now` or shorter: `poweroff` 😉

5. After reset `journalctl` should show you the systemd logs from shutdown phase.
To revert:
1. `rm -R /var/log/journal`

2. Install `DietPi-RAMlog` via `dietpi-software`

Well, isn't this just great - now all of a sudden the very first boot after a shutdown works. Come to think of it though, if I remember correctly, the initial boot always failed after I copied the currently used drive to another drive. Maybe that's the way it's supposed to be if you switch boot devices?

Pillendreher on 25 Jul 2020

the initial boot always failed after I copied the currently used drive to another drive. Maybe that's the way it's supposed to be if you switch boot devices?

You mean you moved to a different SSD/drive to boot from? How did you do it? Cloning or copying files over only (which should not work)? Not sure how it might affect the next shutdown/boot process, but I would not expect the shutdown to hang either. However I'm glad that its working now 😄.

MichaIng on 26 Jul 2020

the initial boot always failed after I copied the currently used drive to another drive. Maybe that's the way it's supposed to be if you switch boot devices?

You mean you moved to a different SSD/drive to boot from? How did you do it? Cloning or copying files over only (which should not work)? Not sure how it might affect the next shutdown/boot process, but I would not expect the shutdown to hang either. However I'm glad that its working now 😄.

I cloned the initial boot drive with ddrescue.

Once my laptop is fixed, I can move the SSD I had in mind for the Pi back to the Pi and I'll get back to you - I'll clone my current Pi flashdrive to the SSD then, which will give me an opportunity to test my hunch.

Pillendreher on 26 Jul 2020

👍1

Unfortunately WireGuard installation cancels with error:

Setting up wireguard-dkms (1.0.20200712-1~bpo10+1) ...
Loading new wireguard-1.0.20200712 DKMS files...
It is likely that 5.4.51-v8+ belongs to a chroot's host
Building for 5.4.51+, 5.4.51-v7+, 5.4.51-v7l+ and 5.4.51-v8+
Building initial module for 5.4.51+
Error! Bad return status for module build on kernel: 5.4.51+ (aarch64)
Consult /var/lib/dkms/wireguard/1.0.20200712/build/make.log for more information.
dpkg: error processing package wireguard-dkms (--configure):
installed wireguard-dkms package post-installation script subprocess returned error exit status 10
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
wireguard-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)

DKMS make.log for wireguard-1.0.20200712 for kernel 5.4.51+ (aarch64)
Mon Jul 27 17:54:17 BST 2020
make: Entering directory '/usr/src/linux-headers-5.4.51+'
AR /var/lib/dkms/wireguard/1.0.20200712/build/built-in.a
CC [M] /var/lib/dkms/wireguard/1.0.20200712/build/main.o
CC [M] /var/lib/dkms/wireguard/1.0.20200712/build/noise.o
CC [M] /var/lib/dkms/wireguard/1.0.20200712/build/device.o
CC [M] /var/lib/dkms/wireguard/1.0.20200712/build/peer.o
In file included from ./include/linux/types.h:6,
from /var/lib/dkms/wireguard/1.0.20200712/build/compat/compat.h:11,
from :
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
#include
^~~~~
In file included from ./include/linux/types.h:6,
from /var/lib/dkms/wireguard/1.0.20200712/build/compat/compat.h:11,
from :
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
#include
^~~~~
compilation terminated.
compilation terminated.
make[1]: * [scripts/Makefile.build:266: /var/lib/dkms/wireguard/1.0.20200712/build/main.o] Error 1
make[1]: Waiting for unfinished jobs....
make[1]: [scripts/Makefile.build:266: /var/lib/dkms/wireguard/1.0.20200712/build/noise.o] Error 1
In file included from ./include/linux/types.h:6,
from /var/lib/dkms/wireguard/1.0.20200712/build/compat/compat.h:11,
from :
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
#include
^~~~~
compilation terminated.
make[1]: [scripts/Makefile.build:266: /var/lib/dkms/wireguard/1.0.20200712/build/device.o] Error 1
In file included from ./include/linux/types.h:6,
from /var/lib/dkms/wireguard/1.0.20200712/build/compat/compat.h:11,
from :
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
#include
^~~~~
compilation terminated.
make[1]: [scripts/Makefile.build:266: /var/lib/dkms/wireguard/1.0.20200712/build/peer.o] Error 1
make: * [Makefile:1709: /var/lib/dkms/wireguard/1.0.20200712/build] Error 2
make: Leaving directory '/usr/src/linux-headers-5.4.51+'

HomeWire-Admin on 27 Jul 2020

❤1

Hmm, I'm afraid at the current state this is not easily possible. There is not yet a headers package for the the 64-bit kernel 😞: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/?C=M;O=D

In theory the source is here: https://github.com/raspberrypi/linux/releases
But compared to the ~50 MiB sources each kernel build in the headers package this ~1 GiB in size, I think because it contains each and every Linux source file instead of only the ones used by the RPi. Not sure how to get the required files from this 🤔.

However the error you face is during armv6l kernel module compilation. I checked the package and it contains /usr/src/linux-headers-5.4.51+/include/uapi/asm-generic/types.h but not asm/types.h, not sure if this is resolved internally somehow. I'll run some test.

MichaIng on 27 Jul 2020

👍2 ❤1

Tested the image on a RPi4, 8 GB. The 8 GB RAM was shown in htop:
grafik

Positive Tests:

Activating WiFi and connecting to the WLAN
Overclocking to 1750 MHz / 500 MHz
Using Apache2 instead of lightppd and OpenSSH instead of Dropbear
phpsysinfo
Mopidy
Node-RED
Nextcloud
WordPress
xfce X11 interface

StephanStS on 31 Jul 2020

👍3 ❤1

Many thanks for testing, as well the overclocking preset, which I totally forgot. Good to know it works stable with Linux 5.4 as well!

MichaIng on 31 Jul 2020

Is wireguard working now :p ?

MattL0 on 2 Aug 2020

I don't think the Raspberry Foundation provided the missing header package in meantime.

Joulinar on 2 Aug 2020

@MichaIng: Do you have a _wishlist_ of issues that should be tested with the image?

StephanStS on 2 Aug 2020

@MattL0
For WireGuard, check: https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/?C=M;O=D
As long as you don't see raspberrypi-kernel-headers_<version>_arm64.deb there, matching the newest version/date, one would need to find and install the 64-bit kernel headers manually for WireGuard to work. I didn't found a good source that avoids downloading the whole raw RPi Linux repo so far.

@StephanStS
I think from DietPi-side the implementation is stable. Now its about the kernel and firmware/userland support that needs to be refined. There are still things missing (like kernel headers) and the 5.4 kernel suffers some issues like #3690. I'll update and add the 64-bit to our download page to hopefully get more attention, testers and in case report issues to RPi devs.

MichaIng on 2 Aug 2020

~When trying to mount a Samba drive via dietpi-drive_manager on the 64-bit beta I get the following error:~

mount error: cifs filesystem not supported by the system
mount error(19): No such device
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

~Thought I'd report it here while I keep digging, in case I'm not alone~

~Edit: For clarity, I do have smbclient and cifs-utils installed~

Edit again: Reinstalling beta seems to have fixed the problem.

MattAKAFred on 3 Aug 2020

just for the records. The missing kernel headers package discussion on Pi OS GitHub. Doesn't looks it will be fixed in near future

https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/4

There are as well some solutions how to build the missing package by it's own

Joulinar on 3 Aug 2020

😕1 👍1

@Joulinar
Thanks for sharing this thread. It is really a problem as this limits testing the kernel dramatically. How is one supposed to create a kernel module without headers and this is a very common task. I have not much idea about kernel building but I thought it basically collecting the used source files and put them into a package. One user shares a script that seems to do that: https://gist.github.com/satmandu/a507c59d84737f6d29ff353395819d51
All the implementation magic is included as well, I guess moreless copy&paste from the armhf headers package, to trigger dkms, update symlinks at /lib/modules and such. Not something we can implement into our scripts but if someone requires WireGuard (or anything else that requires a kernel module build) on the 64-bit image, this seems to be the way to go currently.

MichaIng on 3 Aug 2020

Yeah I will test it once my RPi3 is not needed for another support case. I definitely need more device's 😆

Joulinar on 3 Aug 2020

❤1

Here the best summary so far: https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/4#issuecomment-667670023

MichaIng on 3 Aug 2020

soooo I was able to get WireGuard working. This is quite hacky. But the result counts 😆

root@DietPi3:~# uname -a
Linux DietPi3 5.4.51-v8+ #1327 SMP PREEMPT Thu Jul 23 11:11:34 BST 2020 aarch64 GNU/Linux
root@DietPi3:~#

root@DietPi3:~# systemctl status wg-quick@wg0
● [email protected] - WireGuard via wg-quick(8) for wg0
   Loaded: loaded (/lib/systemd/system/[email protected]; enabled; vendor preset: enabled)
   Active: active (exited) since Tue 2020-08-04 23:31:54 CEST; 59s ago
     Docs: man:wg-quick(8)
           man:wg(8)
           https://www.wireguard.com/
           https://www.wireguard.com/quickstart/
           https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
           https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
  Process: 650 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
 Main PID: 650 (code=exited, status=0/SUCCESS)

Aug 04 23:31:54 DietPi3 wg-quick[650]: [#] sysctl net.ipv6.conf.wg0.forwarding=1 net.ipv6.conf.$(sed -n 3p /run/dietpi/.network).forwarding=1
Aug 04 23:31:54 DietPi3 wg-quick[650]: net.ipv6.conf.wg0.forwarding = 1
Aug 04 23:31:54 DietPi3 wg-quick[650]: net.ipv6.conf.eth0.forwarding = 1
Aug 04 23:31:54 DietPi3 wg-quick[650]: [#] sysctl net.ipv6.conf.$(sed -n 3p /run/dietpi/.network).accept_ra=2
Aug 04 23:31:54 DietPi3 wg-quick[650]: net.ipv6.conf.eth0.accept_ra = 2
Aug 04 23:31:54 DietPi3 wg-quick[650]: [#] sysctl net.ipv4.conf.wg0.forwarding=1 net.ipv4.conf.$(sed -n 3p /run/dietpi/.network).forwarding=1
Aug 04 23:31:54 DietPi3 wg-quick[650]: net.ipv4.conf.wg0.forwarding = 1
Aug 04 23:31:54 DietPi3 wg-quick[650]: net.ipv4.conf.eth0.forwarding = 1
Aug 04 23:31:54 DietPi3 wg-quick[650]: [#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o $(sed -n 3p /run/dietpi/.network) -j MASQUERADE
Aug 04 23:31:54 DietPi3 systemd[1]: Started WireGuard via wg-quick(8) for wg0.
root@DietPi3:~#

root@DietPi3:~# wg
interface: wg0
  public key: xxx
  private key: (hidden)
  listening port: 51820

peer: xxx
  endpoint: x.x.x.x:21460
  allowed ips: 10.9.0.2/32
  latest handshake: 28 seconds ago
  transfer: 46.00 KiB received, 67.27 KiB sent
root@DietPi3:~#

Joulinar on 4 Aug 2020

🚀1 ❤1 🎉1 👍1

Nice!! Would you mind sending the procedure ? :)

MattL0 on 5 Aug 2020

Did you use the script https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/4#issuecomment-667670023

MattL0 on 5 Aug 2020

@MattL0
basically yes, but it was needed to install *.deb files twice before it get working. As well, I'm not happy about all the error messages that occur during *.deb files installation. Quite some effort and time consuming to recreate the headers package every time a new kernel is released. And you are not able to use dietpi-software to install WireGuard. Whole installations and setup would need to be done manually. 🙄

Joulinar on 5 Aug 2020

jour

@codeandmedia
You mean the USB drive you flashed DietPi on was not expended on first boot automatically? Could you please paste the output of the following command:
cat /var/tmp/dietpi/logs/fs_partition_resize.log
@Pillendreher
Are you able to attach a screen to check the system messages on shutdown? Else you could investigate by enabling boot persistent system logs. I'd recommend to do this via persistent systemd-journal (instead of rsyslog):
1. Uninstall `DietPi-RAMlog` via `dietpi-software`

2. `reboot`

3. `mkdir /var/log/journal`

4. `shutdown -h now` or shorter: `poweroff` 😉

5. After reset `journalctl` should show you the systemd logs from shutdown phase.
To revert:
1. `rm -R /var/log/journal`

2. Install `DietPi-RAMlog` via `dietpi-software`

Just to do a followup: My laptop is fixed and I moved the SSD back to the Pi. The initial boot as the new boot device worked flawlessly. Maybe it was fixed with the latest update? Anyway, no complaints here. 😄

Pillendreher on 5 Aug 2020

Guys, I discovered a 2nd way how to get kernel headers setup.

I build my own kernel
https://www.raspberrypi.org/documentation/linux/kernel/building.md

and extract needed header packages following this guide.
https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/4#issuecomment-663921708

WireGuard setup according this guide (skipped the first step apt install raspberrypi-kernel-headers)
https://github.com/notasausage/pi-hole-unbound-wireguard#setting-up-a-vpn-with-wireguard

WireGuard config files I copied from my existing 32bit system

But it took a couple of hours compiling 🤣

Joulinar on 5 Aug 2020

👍3 😄1

@Pillendreher
Great to hear. There has not been any recent update from our side, only APT package-wise probably.

@Joulinar
That sounds indeed cleaner and allows to tweak kernel features as desired (move required features from module to builtin, disable or move non-required features to module) 👍.

MichaIng on 5 Aug 2020

@MichaIng
yap it feels way cleaner to create an own kernel and extract the headers themselves. I hope there will be an official headers package soon. But hey, it's still beta 🤣

Joulinar on 7 Aug 2020

just discovered that Kodi 18.7 doesn't work on the 64bit image. Maybe someone could have a look and verify it. reason seems to be switching to Debian Repro, which just contains 17.6. This will lead to some mix-up on dependency's

kodi : Depends: kodi-bin (>= 2:18.7-1~buster) but 2:17.6+dfsg1-4+b1 is to be installed

Anyway I force installation kodi=2:17.6+dfsg1-4+b1 (thx @MichaIng for the error handle) but I was not able to start it at the end. Some issues in getting the display attached 🤔

Joulinar on 9 Aug 2020

While the 64 bit Image has been working flawlessly, I guess I encountered some collateral damage today: Unknown to me, I was trying to run a 32 bit executable. I guess at this stage, there's no "workaround" for that, is there?

Pillendreher on 11 Aug 2020

I guess this has nothing to do with DietPi, more with the underlying Raspberry OS. Probably your executable requires some libraries that are not available on a 64bit system?

Joulinar on 11 Aug 2020

Probably your executable requires some libraries that are not available on a 64bit system?

This is what "file" tells me for said executable:

ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, Go BuildID=LXIpfG9kc2U3IwtpQomu/536JNyKQVvwi80UE4unE/N17YdC7rHrSc0-mhzMD2/_jHIiLrq_OshRfvrDID2, BuildID[sha1]=0443cef52873772dacd8d6e8d82c9463fef6fa96, not stripped

Pillendreher on 11 Aug 2020

just checked RealVNC and it's working well.

Joulinar on 12 Aug 2020

@Pillendreher

interpreter /lib/ld-linux.so.3

That will be the issue. On the 32-bit image it's:

/lib/ld-linux.so.3 -> /lib/ld-linux-armhf.so.3

On the 64-bit image it's:

/lib/ld-linux-aarch64.so.1

and the symlink should not even exist. So the 32-bit libc6 for your executable is missing.

@Joulinar
Indeed there is not yet a 64-bit build for the RPi Kodi: http://archive.raspberrypi.org/debian/pool/main/k/kodi/
The meta package kodi is marked for all architectures (since it does not contain any executable) but on 64-bit system it then needs kodi-bin arm64 build which does not exist. The Debian repo Kodi would be a low-performance workaround but it requires the Xserver to be installed. Kodi on RPi is build to use its graphic card/driver directly to print the image, hence it does not require an Xserver. Kodi from Debian cannot do that with the RPi GPU and the executable scripts are AFAIK by default calling Kodi via xinit. So that will work somehow, but not great.

So what do we have: No Kodi + no WireGuard, did anyone try Docker?

MichaIng on 13 Aug 2020

Cuberite as well I guess? Would need some testing.

Joulinar on 13 Aug 2020

@Pillendreher

interpreter /lib/ld-linux.so.3

That will be the issue. On the 32-bit image it's:
/lib/ld-linux.so.3 -> /lib/ld-linux-armhf.so.3
On the 64-bit image it's:
/lib/ld-linux-aarch64.so.1
and the symlink should not even exist. So the 32-bit libc6 for your executable is missing.

Ah, got ya. I just went ahead and build a 64 bit binary. I simply thought maybe there was an easy way to run 32 bit stuff like this which could be an addition do dietpi.

So what do we have: No Kodi + no WireGuard, did anyone try Docker?

Apart from said 32 bit binary, I personally have not encountered a non-functioning app. As an addition to my list I posted here a couple of weeks ago, the following software works as well:

-Python3
-Smartmontools
-Grafana
-Telegraf
-Influxdb

Pillendreher on 13 Aug 2020

👍1

Ah, the following would have been possible as well: apt install libc6:armhf
armhf arch is available (else dpkg --add-architecture armhf) since the RPi VC firmware packages are not yet available for arm64.
But running a 64-bit binary on a 64-but OS is of course the preferred way.

MichaIng on 13 Aug 2020

LXDE in this 64-bit version seems to install without an applications menu icon, all attempts to get it working with a different icon file etc doesn't seem to work. Other DietPi images I have used install LXDE with the menu just fine. I can still click where the menu button should be and get the menu, so it appears to be purely graphical in nature. But I can see how a new Pi4 user could get confused if this was their first experience with DietPi 64-bit

goney3 on 18 Aug 2020

well same behaviour on 32bit image. Not sure if this is related to 64bit only

IMG_20200818_132910

Joulinar on 18 Aug 2020

👍1

Many thanks for reporting. Strange, probably the lxpanel package from RPi repo lacks the icon or is configured to use a different one that is not present from RPi standard desktop.

Probably installing lxpanel from Debian repo (respectively Raspbian repo) solves it: apt install --reinstall lxpanel=0.10.0-2
Not sure if this works since the RPi repo version string is the same just with +rpt12 suffix.

I checked the lxpanel-data package but the content matches 100% and as well while it contains a lot of icons, the LXDE start icon seems to come from a different package.

MichaIng on 18 Aug 2020

👍1

I too don't have the icon. Trying to reinstall with your command leads to the following:

root@DietPi:~# apt install --reinstall lxpanel=0.10.0-2
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 lxpanel : Depends: lxpanel-data (= 0.10.0-2) but 0.10.0-2+rpt12 is to be installed
E: Unable to correct problems, you have held broken packages.

That's what you were talking about with regard to "+rpt12", isn't it?

Pillendreher on 18 Aug 2020

Ah yes, so both packages need to be installed explicitly from Debian then:

apt install --reinstall lxpanel-data=0.10.0-2 lxpanel=0.10.0-2

Let's hope there is no greater dependency loop, but a quick walk through https://packages.debian.org/buster/lxde doesn't reveal any more explicite lxpanel version requirements, let's see.

MichaIng on 18 Aug 2020

👍3

root@DietPi:~# apt install --reinstall lxpanel-data=0.10.0-2 lxpanel=0.10.0-2
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  menu
Recommended packages:
  pavucontrol | gnome-alsamixer libnotify-bin notification-daemon
The following packages will be DOWNGRADED:
  lxpanel lxpanel-data
0 upgraded, 0 newly installed, 2 downgraded, 0 to remove and 3 not upgraded.
Need to get 1269 kB of archives.
After this operation, 15.4 kB disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 https://deb.debian.org/debian buster/main arm64 lxpanel arm64 0.10.0-2 [203 kB]
Get:2 https://deb.debian.org/debian buster/main arm64 lxpanel-data all 0.10.0-2 [1066 kB]
Fetched 1269 kB in 0s (3608 kB/s)
dpkg: warning: downgrading lxpanel from 0.10.0-2+rpt12 to 0.10.0-2
(Reading database ... 72507 files and directories currently installed.)
Preparing to unpack .../lxpanel_0.10.0-2_arm64.deb ...
Unpacking lxpanel (0.10.0-2) over (0.10.0-2+rpt12) ...
dpkg: warning: downgrading lxpanel-data from 0.10.0-2+rpt12 to 0.10.0-2
Preparing to unpack .../lxpanel-data_0.10.0-2_all.deb ...
Unpacking lxpanel-data (0.10.0-2) over (0.10.0-2+rpt12) ...
Setting up lxpanel-data (0.10.0-2) ...
Setting up lxpanel (0.10.0-2) ...
Processing triggers for mime-support (3.62) ...
root@DietPi:~#

And after a reboot, the icon appears:

grafik

Pillendreher on 18 Aug 2020

❤2

I hope that means the file manager icons are fixed as well, I'll have to give this a shot later, thank you guys so much for figuring out a hot fix for it!

goney3 on 18 Aug 2020

Nice!

I hope that means the file manager icons are fixed as well, I'll have to give this a shot later, thank you guys so much for figuring out a hot fix for it!

Ah, pcmanfm icons are hence still "broken" on RPi Buster? I always wanted to test this, always forgot to do so. For this reason we installed (and still do) the Debian package on Raspbian Stretch systems. On Buster, currently fix would be:

apt install --reinstall pcmanfm=1.3.1-1

It looks like we should simply block those packages from archive.raspberrypi.org via APT pins in /etc/apt/preferences.d/.

MichaIng on 18 Aug 2020

😕1

apt install --reinstall lxpanel-data=0.10.0-2 lxpanel=0.10.0-2

I can confirm, this is fixing the missing icon on 32bit as well

Joulinar on 18 Aug 2020

👍1

Upon first boot I cannot pass DNS testing, as Pi says it cannot ping the preloaded DNS servers.

motaboy on 19 Aug 2020

@motaboy
Looks more like some local connection issues. What is the DNS server used? Do you have IPv6 enabled? If yes, can it be disabled? can you pls share the exact error message?

Joulinar on 19 Aug 2020

apt install --reinstall pcmanfm=1.3.1-1

Hmm, when trying to load pcmanfm now it just blinks on the screen and then is gone 😭

goney3 on 21 Aug 2020

Okay that is strange. Did you try to run it from console to track error output?

MichaIng on 21 Aug 2020

@MichaIng
looks like this https://github.com/MichaIng/DietPi/issues/3601#issuecomment-643700699 is hitting us as well on the 64bit image. At least I was not able to connect to WiFi as the interface was soft-blocked. Same solution was enabling the interface.

journalctl contains this 😞

Jun 23 23:56:08 DietPi wpa_supplicant[867]: Successfully initialized wpa_supplicant
Jun 23 23:56:08 DietPi wpa_supplicant[867]: rfkill: WLAN soft blocked
Jun 23 23:56:09 DietPi wpa_supplicant[867]: rfkill: WLAN soft blocked

don't get confused on the data/time, timesync did not succeed until now 😉

Joulinar on 24 Aug 2020

👍1

Overdue to remove all blocks on DietPi-PREP: https://github.com/MichaIng/DietPi/commit/8db261a8256b3307821fe05ef137d65f92383bc9
The package is now removed as well, we anyway never use it, only to unblock as a failsafe step but never to block anything. If required, it can be easily installed manually.

MichaIng on 24 Aug 2020

I updated the image: https://dietpi.com/downloads/images/testing/DietPi_RPi-ARMv8-Buster.7z

MichaIng on 24 Aug 2020

I was one day too early, as now there is a Lite image available: https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_arm64-2020-08-24/

MichaIng on 25 Aug 2020

👀2

ok right in time. I'm expecting some new SD cards arriving today. This will allow me to be more flexible in switching between images on my RPi devices 😄 . More easier to support if I don't need to re-image that often anymore 🤣

Joulinar on 25 Aug 2020

The new images contain a VC firmware package with new library and binary locations outside of /opt: https://github.com/MichaIng/DietPi/issues/3743#issuecomment-682203084

MichaIng on 27 Aug 2020

I did a "apt full-upgrade" this morning and it seems it broke vncserver:

│ Aug 30 15:06:56 DietPi systemd[1]: Started Manage VNC Server (DietPi).
│ Aug 30 15:06:56 DietPi systemd[24232]: pam_unix(login:session): session
│ opened for user root by (uid=0)
│ Aug 30 15:06:56 DietPi vncserver[24232]: /usr/bin/vncserver-virtual: error
│ while loading shared libraries: libmmal.so.0: cannot open shared object
│ file: No such file or directory
│ Aug 30 15:06:56 DietPi systemd[1]: vncserver.service: Main process exited,
│ code=exited, status=1/FAILURE
│ Aug 30 15:06:56 DietPi systemd[1]: vncserver.service: Failed with result

Any chance I can check whether said library was affected by said upgrade command?

EDIT: Re-installing vncserver via dietpi-software didn't solve the issue either.

Meanwhile I found this:

https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/3

I have been using realvncserver successfully with the 64 bit image for weeks though. What changed?

EDIT2: TigerVNC still works.

Pillendreher on 30 Aug 2020

Yes the reason is a change of RPi VC library location, same broke Jellyfin hardware acceleration: https://github.com/MichaIng/DietPi/issues/3743#issuecomment-682195489
The RealVNC package needs to be updated first to use the new location and additionally the 64-bit VC firmware package needs to be updated to contain the library at all. Go get it running, you need to downgrade the firmware or use the 32-bit image until the 64-bit image become settled and stable from RPi foundation side.
To downgrade firmware:

cd /tmp
wget http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi0_1.20200819-1_armhf.deb
wget http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi-bin_1.20200819-1_armhf.deb
apt install ./libraspberrypi0_1.20200819-1_armhf.deb ./libraspberrypi-bin_1.20200819-1_armhf.deb
rm ./libraspberrypi0_1.20200819-1_armhf.deb ./libraspberrypi-bin_1.20200819-1_armhf.deb

But it might introduce issues with the as well newer kernel.

MichaIng on 30 Aug 2020

@MichaIng
Probably we would need to make a clear statement, that the image is not recommended for productive usage as the base image is still under heavy development by the RPi foundation.

Joulinar on 30 Aug 2020

On the other hand, exactly such testing is required to make Jellyfin and RealVNC maintainers aware of this change before is becomes stable. I is marked as beta, that should actually make clear that the one of the other compatibility issue may arise.

However, report to those guys is still outstanding. I'll do that now, if now yet done by someone else.

MichaIng on 31 Aug 2020

RealVNC issue reported already: https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/86

So the reason is not the location but that libmmal is currently not supported/build for 64-bit firmware at all.

Here another issue which lead to those libraries being not build for 64-bit firmware: https://github.com/raspberrypi/userland/issues/630

MichaIng on 31 Aug 2020

lxpanel menu icon issue will be tracked further here: #1558
I'm not happy with manual package downgrades, we never know when this breaks other installs, also applying apt preferences pins of "-1" (block) to a package which is installed already breaks any apt install/reinstall of it, while downgrade is only done when manually adding the version string. So we'd need to detect if any of those packages is installed and only if not apply the PINs, so we end up not knowing who uses which package... Better report to RPi devs and hope they can fix it: https://github.com/raspberrypi-ui/
Verified that PCManFM cannot be fixed on Buster without installing and applying one of the RPi icon themes. But those additional icons (there are no missing icon images, the RPi package just adds additional buttons that Debian does not know, hence has no icon images for) can simply be disabled: https://github.com/MichaIng/DietPi/issues/1558#issuecomment-540697960
On Debian they indeed simply do not exist.

MichaIng on 31 Aug 2020

I was just looking through some random bug report uploads and it revealed that Chromium is not yet available on Raspberry Pi OS 64-bit as well, indeed the package is missing: http://archive.raspberrypi.org/debian/pool/main/c/chromium-browser/

MichaIng on 18 Sep 2020

Realvnc has a new working release for arm64 for RPI OS 64

svenger87 on 23 Sep 2020

👍2

Awesome, many thanks for informing us.

MichaIng on 23 Sep 2020

Hi, some light at the end of the missing headers package tunnel https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/4#issuecomment-702364298

Can someone test who has 64Bit beta running? Unfortunately I'm away from home atm, and not able to change SD cards on my boards 😆

Joulinar on 1 Oct 2020

👍1

Hi dietpi-update to v6.34.-1 issue on version update infinite loop
Now version = Current version : v6.443537.0
See (truncated) log file
dietpi-update.log
An way for solving this ?
Thank's

magloui on 19 Oct 2020

I guess you are on dev branch because actual version ist 6.33.3

I guess @MichaIng would need to have a look how it could happen to end up on v6.443537. Even on dev this should not happen

Joulinar on 19 Oct 2020

Jep I faced the same 😄. Already fixed but the version needs to be reduced manually one time:

nano /boot/dietpi/.version

Replace line two with 32
Optionally (recommended) migrate to stable branch:

G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=master' /boot/dietpi.txt

then:

dietpi-update 1

MichaIng on 19 Oct 2020

👍1

How to enable Wifi ?

francisp2 on 24 Oct 2020

@francisp2

Did you tried dietpi-config > 7 : Network Options: Adapters > Onboard WiFi : [On]
It might be needed to reboot your system afterwards to activate settings

Joulinar on 24 Oct 2020

So, found this while searching for what features are missing from 64-bit version of DietPi on Pi4. Currently running RaspOS arm64 Lite from 8-24-2020

sunjam on 25 Oct 2020

small update regarding Wireguard. Today I was playing around and tested next upstream LTS (Long Term Support) kernel 5.10 on a RPi64bit image running DietPi v6.34.-1 (dev).

@MichaIng not sure it it is already intend but dietpi-sotware did not detect the Wireguard kernel module and tried to install raspberrypi-kernel, raspberrypi-kernel-headers, raspberrypi-bootloader and wireguard-dkms still. It was needed to tweak dietpi-sotware and set WIREGUARD_BUILTIN=1. Afterwards installation finished successfully 😃

root@DietPi3:~# uname -a
Linux DietPi3 5.10.0-rc4-v8+ #1372 SMP PREEMPT Tue Nov 17 14:30:39 GMT 2020 aarch64 GNU/Linux
root@DietPi3:~#
root@DietPi3:~# wg
interface: wg0
  public key: xxx
  private key: (hidden)
  listening port: 51821

peer: xxx
  endpoint: xxx:20338
  allowed ips: 10.9.0.2/32
  latest handshake: 58 seconds ago
  transfer: 16.80 KiB received, 15.95 KiB sent
root@DietPi3:~#

Joulinar on 18 Nov 2020

@Joulinar
This should have been fixed with https://github.com/MichaIng/DietPi/commit/8ee591baa826860aad0454225418a03497fa2a96, isn't it?

MichaIng on 19 Nov 2020

nope it's not gonna work

the module is there

root@DietPi3:~# ls -la /lib/modules/*/kernel{,/drivers}/net/wireguard/
ls: cannot access '/lib/modules/*/kernel/net/wireguard/': No such file or directory
/lib/modules/5.10.0-rc4-v8+/kernel/drivers/net/wireguard/:
total 136
drwxr-xr-x  2 root root   4096 Nov 19 10:42 .
drwxr-xr-x 15 root root   4096 Nov 19 10:42 ..
-rw-r--r--  1 root root 129568 Nov 19 10:42 wireguard.ko
root@DietPi3:~#

however going to be irgnored

[ SUB1 ] DietPi-Software > Installing WireGuard: an extremely simple yet fast and modern VPN
[ INFO ] DietPi-Software | APT install for: raspberrypi-kernel raspberrypi-kernel-headers raspberrypi-bootloader, please wait...

I debugged it a little bit and found the issue. The module is going to be detected correctly, however following line is preventing the variable WIREGUARD_BUILTIN=1 to be set.
https://github.com/MichaIng/DietPi/blob/a0ea9775458e8e109fd40a9fe9da56ff9652100b/dietpi/dietpi-software#L1830

If I hash # the line, installation is working as expected

[ SUB1 ] DietPi-Software > Installing WireGuard: an extremely simple yet fast and modern VPN
[ INFO ] DietPi-Software | APT install for: wireguard-tools iptables qrencode, please wait...

Joulinar on 19 Nov 2020

and one more observation related to new LTS kernel 5.10. CPU temp is not detected correctly. Not sure if this is still a missing feature inside the testing kernel or if they changed anything.

root@DietPi3:~# cpu

 ─────────────────────────────────────────────────────
 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 ─────────────────────────────────────────────────────
 Architecture |     aarch64
 Temperature  |     N/A
 Governor     |     ondemand
 Throttle up  |     50% CPU usage

                 Current Freq    Min Freq   Max Freq
 CPU0         |      1400 MHz      600 MHz    1400 MHz
 CPU1         |      1400 MHz      600 MHz    1400 MHz
 CPU2         |      1400 MHz      600 MHz    1400 MHz
 CPU3         |      1400 MHz      600 MHz    1400 MHz

[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.

root@DietPi3:~#

Joulinar on 19 Nov 2020

Ahh you installed the kernel via rpi-update not as a DEB package, while the check explicitly is about checking for a kernel package built-in module. Otherwise it could have been created by wireguard-dkms or manual source build which requires the headers.

Hmm another alternative check we could add is looking for the WireGuard module flag in kernel configs. But those are not always available at a generic location, as this requires the "config" module builtin or loaded. I'll have a look.

If CPU temperature is not found at all, this must have been moved to a very strange location or missing, as we check quite some more. We could use vcgencmd, but it's a very slow command and can theoretically be uninstalled.

MichaIng on 19 Nov 2020

Ahh you installed the kernel via rpi-update not as a DEB package

yes, I'm not aware on another way to move to testing kernel 😄

If CPU temperature is not found at all, this must have been moved to a very strange location or missing, as we check quite some more. We could use vcgencmd, but it's a very slow command and can theoretically be uninstalled.

Yeah it was just an observation, probably will be fixed/added on a later stage. Time will tell...

Joulinar on 19 Nov 2020

yes, I'm not aware on another way to move to testing kernel 😄

Makes sense, I was not thinking about this issue in the first place.

Yeah it was just an observation, probably will be fixed/added on a later stage. Time will tell...

Actually there must be some CPU temperature available somewhere. Could you check:

for i in /sys/class/thermal/thermal_zone[0-9]/temp /sys/class/hwmon/hwmon[0-9]/temp[0-9]_input /sys/devices/platform/coretemp.[0-9]/hwmon/hwmon[0-9]/temp[0-9]_input
do
[[ -e $i ]] && echo "$i : $(<$i)"
done

MichaIng on 19 Nov 2020

probably not working yet

root@DietPi3:~# for i in /sys/class/thermal/thermal_zone[0-9]/temp /sys/class/hwmon/hwmon[0-9]/temp[0-9]_input /sys/devices/platform/coretemp.[0-9]/hwmon/hwmon[0-9]/temp[0-9]_input
> do
> [[ -e $i ]] && echo "$i : $(<$i)"
> done
/sys/class/thermal/thermal_zone0/temp :
root@DietPi3:~#

Joulinar on 19 Nov 2020

Oh wow, a single match without any content 🤣. Jep okay, either I missed a fundamental change in Linux 5.20 thermal sensor API or there is still much to do.

MichaIng on 19 Nov 2020

32-bit RPi will also get the WireGuard module with next LTS kernel release: https://github.com/raspberrypi/linux/pull/3967

MichaIng on 23 Nov 2020

Kernel headers are now available for RPi 64-bit as well: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel-headers_1.20201022-1_arm64.deb
Strangely even for x86 🤣.

So Kodi is the last important missing software title.
EDIT: Kodi is available via Debian repo but that is not hardware-accelerated on RPi.

MichaIng on 28 Nov 2020

👍2

I checked Wireguard using v6.33.3 and kernel 5.4.79+ (aarch64). It's still failing to build

root@DietPi4:~# cat /var/lib/dkms/wireguard/1.0.20201112/build/make.log
DKMS make.log for wireguard-1.0.20201112 for kernel 5.4.79+ (aarch64)
Mon Dec  7 00:26:52 CET 2020
make: Entering directory '/usr/src/linux-headers-5.4.79+'
  AR      /var/lib/dkms/wireguard/1.0.20201112/build/built-in.a
  CC [M]  /var/lib/dkms/wireguard/1.0.20201112/build/main.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20201112/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20201112/build/device.o
In file included from ./include/linux/types.h:6,
                 from /var/lib/dkms/wireguard/1.0.20201112/build/compat/compat.h:11,
                 from <command-line>:
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
 #include <asm/types.h>
          ^~~~~~~~~~~~~
compilation terminated.
  CC [M]  /var/lib/dkms/wireguard/1.0.20201112/build/peer.o
In file included from ./include/linux/types.h:6,
                 from /var/lib/dkms/wireguard/1.0.20201112/build/compat/compat.h:11,
                 from <command-line>:
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
 #include <asm/types.h>
          ^~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.build:266: /var/lib/dkms/wireguard/1.0.20201112/build/main.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [scripts/Makefile.build:266: /var/lib/dkms/wireguard/1.0.20201112/build/noise.o] Error 1
In file included from ./include/linux/types.h:6,
                 from /var/lib/dkms/wireguard/1.0.20201112/build/compat/compat.h:11,
                 from <command-line>:
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
 #include <asm/types.h>
          ^~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.build:266: /var/lib/dkms/wireguard/1.0.20201112/build/device.o] Error 1
In file included from ./include/linux/types.h:6,
                 from /var/lib/dkms/wireguard/1.0.20201112/build/compat/compat.h:11,
                 from <command-line>:
./include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory
 #include <asm/types.h>
          ^~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.build:266: /var/lib/dkms/wireguard/1.0.20201112/build/peer.o] Error 1
make: *** [Makefile:1732: /var/lib/dkms/wireguard/1.0.20201112/build] Error 2
make: Leaving directory '/usr/src/linux-headers-5.4.79+'
root@DietPi4:~#

Joulinar on 7 Dec 2020

It has nothing to do with the fact the it is building the module for ARMv6 currently btw, all four headers only have asm-generic in that directory, not asm.
Not sure if this should be better reported to Raspberry Pi devs or WireGuard (I guess the first).

But just to rule it out. Could you try:

apt install linux-libc-dev
# WireGuard DKMS should reattempt to build the module
# If it still fails
apt install libc6-dev

Ah and btw, this is for sure the arm64 version of the package, isn't it?

apt show raspberrypi-kernel-headers
# shows
APT-Sources: https://archive.raspberrypi.org/debian buster/main arm64 Packages

MichaIng on 7 Dec 2020

nope it doesn't change anything

root@DietPi4:# apt show raspberrypi-kernel-headers
Package: raspberrypi-kernel-headers
Version: 1.20201201-1
Priority: optional
Section: kernel
Source: raspberrypi-firmware
Maintainer: Serge Schneider <[email protected]>
Installed-Size: 229 MB
Provides: linux-headers
Homepage: https://github.com/raspberrypi/firmware
Download-Size: 35.0 MB
APT-Manual-Installed: yes
APT-Sources: https://archive.raspberrypi.org/debian buster/main arm64 Packages
Description: Header files for the Raspberry Pi Linux kernel
 This package provides the architecture-specific kernel header files for
 the Raspberry Pi Linux kernel, generally used for building out-of-tree
 kernel modules.

Joulinar on 7 Dec 2020

I forwarded it to a fitting issue: https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/4

MichaIng on 7 Dec 2020

👍1

ahh indeed removing unnecessary kernel + header is doing the trick

root@DietPi4:/lib/modules# rm -r 5.4.79+ 5.4.79-v7+ 5.4.79-v7l+
root@DietPi4:/usr/src# rm -r linux-headers-5.4.79+ linux-headers-5.4.79-v7+ linux-headers-5.4.79-v7l+

Setting up wireguard-dkms (1.0.20201112-1~bpo10+1) ...
Removing old wireguard-1.0.20201112 DKMS files...

------------------------------
Deleting module version: 1.0.20201112
completely from the DKMS tree.
------------------------------
Done.
Loading new wireguard-1.0.20201112 DKMS files...
It is likely that 5.4.79-v8+ belongs to a chroot's host
Building for 5.4.79-v8+
Building initial module for 5.4.79-v8+
Done.

wireguard.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/5.4.79-v8+/kernel/net/

depmod....

DKMS: install completed.
root@DietPi4:/#

root@DietPi4:~# uname -a
Linux DietPi4 5.4.79-v8+ #1373 SMP PREEMPT Mon Nov 23 13:32:41 GMT 2020 aarch64 GNU/Linux
root@DietPi4:~# wg
interface: wg0
  public key: xxx
  private key: (hidden)
  listening port: 51820

peer: xxx
  allowed ips: 10.9.0.2/32
root@DietPi4:~#

Joulinar on 7 Dec 2020

👍1

Ah great. Okay not sure if this is expected then. I mean it's clear that a 32-but compiler cannot build modules for a 64-but kernel, but not sure about the other way round, and if so, if there are some options required, e.g. ARCH=arm, to make aware of the cross-compiling that is done. However, I think the headers packages should be packaged a way that DKMS works OOTB, so that this is a problem with the headers package.

MichaIng on 7 Dec 2020

@MichaIng
Not sure if it's me but I have issues to install chromium-browser. looks like it's going to install 32bit version.

root@DietPi4:~# apt install chromium-browser
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 chromium-browser:armhf : Depends: chromium-codecs-ffmpeg-extra:armhf (= 84.0.4147.105-rpt3) but it is not going to be installed or
                                   chromium-codecs-ffmpeg:armhf (= 84.0.4147.105-rpt3) but it is not going to be installed
                          Depends: libraspberrypi0:armhf but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root@DietPi4:~

root@DietPi4:~# apt show chromium-browser
Package: chromium-browser:armhf
Version: 84.0.4147.105-rpt3

Joulinar on 8 Dec 2020

Are you running a 64-bit OS?

$ dpkg --print-architecture

On Tue, Dec 8, 2020, 12:35 PM Joulinar notifications@github.com wrote:

@MichaIng https://github.com/MichaIng
Not sure if it's me but I have issues to install chromium-browser. looks
like it's going to install 32bit version.

root@DietPi4:~# apt install chromium-browser
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
chromium-browser:armhf : Depends: chromium-codecs-ffmpeg-extra:armhf (= 84.0.4147.105-rpt3) but it is not going to be installed or
chromium-codecs-ffmpeg:armhf (= 84.0.4147.105-rpt3) but it is not going to be installed
Depends: libraspberrypi0:armhf but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root@DietPi4:~

root@DietPi4:~# apt show chromium-browser
Package: chromium-browser:armhf
Version: 84.0.4147.105-rpt3

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MichaIng/DietPi/issues/3570#issuecomment-740989780,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANUKZQYASWZCWWDSLEEMEDST2EZXANCNFSM4NNFNIEA
.

sunjam on 8 Dec 2020

sure 😉

root@DietPi4:~# uname -a
Linux DietPi4 5.4.79-v8+ #1373 SMP PREEMPT Mon Nov 23 13:32:41 GMT 2020 aarch64 GNU/Linux
root@DietPi4:~#

Joulinar on 8 Dec 2020

Ah yes, good find, forgot about that one. So it's two still broken software titles due to missing RPi-build packages:

Of course in both cases the packages from Debian repository could be installed, but those are not (or badly) hardware-accelerated on RPi.

MichaIng on 8 Dec 2020

Wondering,

Is Wireguard working from the kernel with the last dietpi update/release on aarch64 ?

So, I would be able to switch from Ubuntu :p

MattL0 on 17 Dec 2020

Yes it works, however in case of @Joulinar it was necessary to remove the non-aarch64 kernels and headers (https://github.com/MichaIng/DietPi/issues/3570#issuecomment-739878417 > https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/4#issuecomment-739909279) while in other cases (reported on Raspberry Pi GitHub repo) it seems to have worked OOTB.

MichaIng on 17 Dec 2020

@MattL0

This is not a problem of DietPi. This is fully related to Raspberry OS 64bit and the availability of kernel headers. In meantime they are provided.

Joulinar on 17 Dec 2020

thanks ! I'll play with that today. Thanks to both of you

MattL0 on 17 Dec 2020

Trying to determine if there's is an issue with piVPN install scripts or am I missing headers? I was able to install wireguard-tools, qrencode and wireguard-dkms separately but I'm getting the missing headers error when trying to install piVPN

Additional logs:

:::
::: You are root.
::: Hostname length OK
::: Verifying free disk space...
:::
::: Checking apt-get for upgraded packages.... done!
:::
::: Your system is up to date! Continuing with PiVPN installation...
:::    Checking for git... already installed!
:::    Checking for tar... already installed!
:::    Checking for wget... already installed!
:::    Checking for curl... already installed!
:::    Checking for grep... already installed!
:::    Checking for dnsutils... already installed!
:::    Checking for whiptail... already installed!
:::    Checking for net-tools... already installed!
:::    Checking for bsdmainutils... already installed!
:::    Checking for iptables-persistent... already installed!
::: Using User: dietpi
:::
::: Checking for existing base files...
:::    Checking /usr/local/src/pivpn is a repo... OK!
:::     Updating repo in /usr/local/src/pivpn... done!
::: Using VPN: WireGuard
::: Installing WireGuard from Debian package...
:::    Checking for wireguard-tools... already installed!
:::    Checking for qrencode... already installed!
:::    Checking for linux-headers-amd64... not installed!
:::    Checking for wireguard-dkms... already installed!
:::    Failed to install linux-headers-amd64!
Reading package lists...
Building dependency tree...
Reading state information...
Package linux-headers-amd64 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'linux-headers-amd64' has no installation candidate

uname output

dietpi@mydietpiserver:~$ uname -ar
Linux 5.4.79-v8+ #1373 SMP PREEMPT Mon Nov 23 13:32:41 GMT 2020 aarch64 GNU/Linux

/usr/src

dietpi@mydietpiserver:~$ ls /usr/src/
linux-headers-5.10.1-v8+  linux-headers-5.4.79-v8+  wireguard-1.0.20201112

lcranf on 19 Dec 2020

The bug was reported at https://github.com/MichaIng/DietPi/issues/3910 and https://github.com/pivpn/pivpn/issues/1180 (on Debian though, not Raspberry Pi OS), and @MichaIng fixed it with https://github.com/pivpn/pivpn/pull/1201, though that fix is still in the development branch.

ravenclaw900 on 19 Dec 2020

👍2

Yap indeed an issue of PiVPN themselves

Joulinar on 19 Dec 2020

It makes sense that it occurs the same way on Raspberry Pi OS 64-bit, since it is practically Debian (/etc/os-release) while only "Raspbian" was not affected by the bug.

Ayy, this means that Raspberry Pi OS 64-bit won't be supported by PiVPN with WireGuard currently, as they detect RPi via Raspbian. To support Raspberry Pi OS 64-bit, the RPi detection needs to be done differently, e.g. by detecting if "raspberrypi-kernel" package is installed, which anyway is the only reliable method to know that "raspberrypi-kernel-headers" will work with that kernel. E.g. rpi-updated RPi's do currently fails as headers do not match kernel then.

EDIT: Ah not an issue. Linux 5.10 with builtin WireGuard will be next official RPi kernel release anyway. A waste of time to start implementing kernel module build for Debian on RPi now: https://github.com/raspberrypi/firmware

MichaIng on 19 Dec 2020

Thanks @MichaIng and @Joulinar! Let me switch over to the dev branch of piVPN or I'll try curl -L https://test.pivpn.io | TESTING= bash

lcranf on 19 Dec 2020

Yes 5.10 is upcoming LTS kernel for RPi OS. Question is how long it will take to release 😆

Joulinar on 19 Dec 2020

👍2

There are untested 64-bit only 5.10 kernel + headers packages available now: https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/4#issuecomment-754558008
Since it's 5.10, WireGuard is builtin, but for other DKMS builds, it's great.

Not sure if it's final, but the idea is to generally split kernel packages by architecture, which would allow to reduce the overhead for DKMS builds, download size, disk space etc. At least for a 64-bit image (userspace/OS), practically any non-64 bit kernel can't be used anyway, but the headers only for compiling binaries for other RPi models e.g. On a 32-bit Raspbian OS, due to backwards compatibility, in theory a 64-bit kernel can be used (if the CPU supports it), but it causes issues when installers try to detect the binary architecture via uname -m, which then does not match the DPkg architecture of installed binaries and libraries.

If kernel/firmware packages will be split like that in general, we'll:

Ship the 64-bit image with 64-bit kernel only.
Ship the 32-bit image with the three 32-bit kernel versions to support all RPi models, but add an option to remove those which are not required for the running RPi model, via dietpi-config and via dietpi.txt setting to apply on first boot.

MichaIng on 5 Jan 2021

👍1

looks like LTS Beta Kernel 5.10 is now shipped together with RPI OS 64bit Beta. On PRi3 this leads to issues detecting CPU temp correctly atm

Joulinar on 14 Jan 2021

I'm running 5.10.5-v7+ #1392 32-bit and CPU temperature is detected successfully. Does one of the known sysfs files work?

for i in /sys/class/thermal/thermal_zone[0-9]/temp /sys/class/hwmon/hwmon[0-9]/temp[0-9]_input /sys/devices/platform/coretemp.[0-9]/hwmon/hwmon[0-9]/temp[0-9]_input
do
[[ -e $i ]] && echo "$i : $(<$i)"
done

MichaIng on 14 Jan 2021

the file is not readable on RPi3B. I switched SD cards back and force between RPi3B+ and RPi4B. Same SD is working fine on RPi4B while temp collection is failing on RPi3B+

cat /sys/class/thermal/thermal_zone*/temp
cat: /sys/class/thermal/thermal_zone0/temp: Invalid argument

seems temp is not filled correctly

Fighting with corrupted SD now. I guess I did too many restores and kernel updated today 😆

EDIT
that's the source https://dietpi.com/phpbb/viewtopic.php?f=9&t=8524

Joulinar on 14 Jan 2021

Arrrg 😄. Probably with the 64-bit kernel something has been tailored too much towards RPi 4. We'll to report it to RPi devs then.

But the following works on RPi 3 as well, right?

vcgencmd measure_temp

MichaIng on 14 Jan 2021

But the following works on RPi 3 as well, right?
vcgencmd measure_temp

Jup this is working. will test 5.10.6 but first need to get my test system back

EDIT:
While I'm waiting on my test system installation, I would vote for an option to restore a backup during initial setup instead of running the entire installation 😄

Joulinar on 14 Jan 2021

👍2

same behaviour on 5.10.6-v8+ #1393

root@DietPi3:~# cat /sys/class/thermal/thermal_zone0/temp
cat: /sys/class/thermal/thermal_zone0/temp: Invalid argument
root@DietPi3:~#

Joulinar on 15 Jan 2021

In my case, the following two files exist with identical content:

/sys/class/thermal/thermal_zone0/temp : 34166
/sys/class/hwmon/hwmon0/temp1_input : 34166

MichaIng on 15 Jan 2021

@MichaIng
do you think something to report?

Joulinar on 15 Jan 2021

Interesting, found https://github.com/raspberrypi/linux/issues/3524 which sounds exactly like our issue but has been fixed: https://github.com/raspberrypi/linux/commit/aad3538108e83e15cd1dfca23df406ddf82f7362
Ah let's see if that RPi 4 driver is enabled on RPi 3 as well, probably something got mixed up.
EDIT: No, there it is correct, as long as that config is also used for the build: https://github.com/raspberrypi/linux/blob/rpi-5.10.y/arch/arm64/configs/bcmrpi3_defconfig#L695

MichaIng on 15 Jan 2021

I guess issue is showing up on RPi3 now, as kernel 5.10 is shipped as MASTER on RPi OS64 nowadays. Probably less people tried LTS Beta Kernel before. And who is checking CPU temp? On plain RPi OS it is not display by default. 😉

Joulinar on 15 Jan 2021

On the other hand, there are quite some who build their kernel from sources, other distros might at least. Could you fill a report at the kernel repository, to fill in board and version details? https://github.com/raspberrypi/linux/issues/new?template=bug_report.md

MichaIng on 15 Jan 2021

should I open the report or will you do and just need the Board data?

Joulinar on 15 Jan 2021

As you like, you see the mandatory outputs near the end of the issue template.

MichaIng on 15 Jan 2021

done https://github.com/raspberrypi/linux/issues/4077

Joulinar on 15 Jan 2021

👍2

Dietpi: Image | Raspberry Pi OS (64-bit)

ADMIN EDIT

Beta Image ready for testing: https://dietpi.com/downloads/images/testing/DietPi_RPi-ARMv8-Buster.7z

Most helpful comment

All 173 comments

A note to all testers:

All RPi models from RPi2 v1.2 and up (excluding RPi Zero) are supported, hence all which have an ARMv8-capable CPU: https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications

Unfortunately WireGuard installation cancels with error:

Additional logs:

Related issues