Image | Raspberry Pi OS (64-bit)

[FusionPlmH]

ADMIN EDIT

Beta Image ready for testing: https://dietpi.com/downloads/images/

Known missing/broken software installs, until the RPi repository ships arm64 packages:

• Kodi: http://archive.raspberrypi.org/debian/pool/main/k/kodi/
• Chromium: http://archive.raspberrypi.org/debian/pool/main/c/chromium-browser/

  ---

  Due to the newest new, Raspberry Pi has been started the offical 64bits image on beta .

Raspberry Pi OS (64 bit) beta test forum thread: https://www.raspberrypi.org/forums/viewtopic.php?t=275370

Downloads: https://downloads.raspberrypi.org/raspios_lite_arm64/images/

I wanna know Does dietpi want to follow offical , to make up a 64bits OS ? @MichaIng

[Pillendreher]

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+

[MichaIng]

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 😄.

[Pillendreher]

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.

[MattL0]

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

[codeandmedia]

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.

[Pillendreher]

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.

[MichaIng]

@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

[codeandmedia]

@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.

[MichaIng]

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.

[Pillendreher]

@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?

[MichaIng]

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 😄.

[Pillendreher]

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.

[HomeWire-Admin]

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 <asm/types.h>

^~~~~ 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 <asm/types.h>

^~~~~ 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 <asm/types.h>

^~~~~ 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 <asm/types.h>

^~~~~ 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+'

[MichaIng]

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.

[StephanStS]

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

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

[MichaIng]

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!

[MattL0]

Is wireguard working now :p ?

[Joulinar]

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

[StephanStS]

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

[MichaIng]

@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.

[MattAKAFred]

~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.

[Joulinar]

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

[MichaIng]

@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.

[Joulinar]

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

[MichaIng]

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

[Joulinar]

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
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
   Loaded: loaded (/lib/systemd/system/wg-quick@.service; 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:~#

[MattL0]

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

[MattL0]

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

[Joulinar]

@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. 🙄

[Pillendreher]

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. 😄

[Joulinar]

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 🤣

[MichaIng]

@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) 👍.

[Joulinar]

@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]

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 🤔

[Pillendreher]

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?

[Joulinar]

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?

[Pillendreher]

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

[Joulinar]

just checked RealVNC and it's working well.

[MichaIng]

@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?

[Joulinar]

Cuberite as well I guess? Would need some testing.

[Pillendreher]

@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

[MichaIng]

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.

[goney3]

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

[Joulinar]

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

[MichaIng]

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.

[Pillendreher]

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?

[MichaIng]

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.

[Pillendreher]

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:

[goney3]

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!

[MichaIng]

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/.