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

[Joulinar]

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

[FusionPlmH]

So we may start to have some work on it

[MichaIng]

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]

I've started working on this: #3617

1. 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.
2. 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.
3. 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 😅.

[Joulinar]

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

[MichaIng]

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

[MichaIng]

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

[Joulinar]

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

[MichaIng]

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.

[Joulinar]

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

[MichaIng]

Here we go: https://dietpi.com/downloads/images/

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

[Joulinar]

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

[MichaIng]

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: 3f4cc7b

Image repacked with removed "pi" autologin.

[Joulinar]

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

[MichaIng]

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): 66f937a

[MichaIng]

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

[Joulinar]

done raspberrypi/linux#4077

[kevinelliott]

Is there anyway to upgrade an existing v7 dietpi to be v8?

[Joulinar]

Is there anyway to upgrade an existing v7 dietpi to be v8?

Question is not about DietPi. More if you could upgrade Raspberry Pi OS 32bit to a Raspberry Pi OS 64bit.
Simple answer: nope, 2 totally different OS

• Raspberry Pi ARMHF Operating System May 2020 onwards is based of Raspbian.
• Raspberry Pi ARM64 Beta Operating System is based of Debian Buster.

[MichaIng]

@Joulinar
You mentioned you got Linux 5.10. with the 64-bit image? The only one I can find is still the very first one from last year, shipping 5.4 and upgrading to 5.4 as well: https://downloads.raspberrypi.org/raspios_lite_arm64/images/
Was this the one you downloaded?

[MichaIng]

All RPi images have been updated, including the 64-bit image.

[Joulinar]

yes I used that image. Did it not update you to 5.10? It was shipped with 5.4 but updated strait to 5.10 running apt update && apt upgrade. Today I'm to lazy to go upstairs to switch SD card. Will have a look tomorrow again. 🤔

[MichaIng]

I see this package: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20210111.master-1_arm64.deb
Strange, it was not installed during DietPi-PREP, no idea why 🤔. I'll re-check an re-update it.

[Joulinar]

ok did one more test on Raspberry OS Lite 64bit

Kernel right after first boot

root@raspberrypi:~# uname -a
Linux raspberrypi 5.4.51-v8+ #1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020 aarch64 GNU/Linux

Kernel package that can be updated

root@raspberrypi:~# apt list --upgradable
raspberrypi-bootloader/testing 1.20210111.master-1 arm64 [upgradable from: 1.20200819-1]
raspberrypi-kernel/testing 1.20210111.master-1 arm64 [upgradable from: 1.20200819-1]

Kernel once updated finished and system rebooted

root@raspberrypi:~# uname -a
Linux raspberrypi 5.10.5-v8+ #1392 SMP PREEMPT Sat Jan 9 18:56:30 GMT 2021 aarch64 GNU/Linux

---

BTW something doesn't seems to be fitting on the new image. It seems to be to small. An the download page it is stating 122M while FireFox as well as Egde telling me 91M to be downloaded, leading to a not working archive. See picture

[MichaIng]

?? Also the file name is wrong, note the trailing -1. Probably an issue with the cache, although Cloudflare cache at least is cleared one new images are uploaded.

I tested it here, and the correct file with correct size is downloaded 🤔.

And ähm, ah lol correct kernel version 5.10.5 as well. Strange, probably I misinterpreted the APT install output which shows this long list of added/removed diversions for the kernel files, probably those 5.4 files were the ones removed, not the ones installed, and then on image review probably I downloaded the old cached image as well 😄.

So please retry now.

---

Looks like I have to get clarification about a few things of Cloudflare cache. I ordered cache clearing for this file last night and it should be removed from the cache within 30 seconds. And even if it didn't get (fully) loaded into the their cache yet, Cloudflare must never serve an incomplete file, of course...

[Joulinar]

I guess I'm still getting the old file looking to the date of the image inside the archive

[MichaIng]

Indeed, strange. Looks like even in Germany there are multiple Cloudflare Edge cache servers, some still serving the old file...

Lol, I just checked the cache clear history and I accidentally cleared https://dietpi.com/downloads/images/DietPi_RPi-ARMv8-Buster.7z instead of https://dietpi.com/downloads/images/testing/DietPi_RPi-ARMv8-Buster.7z (forgot testing subdir). Whoopsie. So now also your Edge cache should serve the correct file. Now it's also clear why I got the old image yesterday 😄.

[Joulinar]

way better now. And kernel is already 5.10.5-v8+ #1392 right from the beginning

[MichaIng]

Great, mystery solved. And the -1 in the file name was because that file existed already at your download folder, right? In Opera, (1) is appended, so that didn't occur to me 😄.

[Joulinar]

I guess so. 😄

[Joulinar]

btw with that image, Wireguard installations is working flawless. 😄
Kernel module is detected correctly and wireguard-tools will be installed only.

 DietPi-Software
─────────────────────────────────────────────────────
 Mode: Installing WireGuard: an extremely simple yet fast and modern VPN

[ INFO ] DietPi-Software | APT install for: wireguard-tools iptables qrencode, please wait...

[MichaIng]

So the last known non-functional dietpi-software installs are Chromium and Kodi, both since we ship the packages from the Raspberry Pi repository with RPi-optimised GPU-accelerated binaries which have not yet been build for arm64. I'll add this info OP, probably to the download page as well.

[Joulinar]

New LTS kernel 5.10.11 has been released by RPi Foundation for 32bit as well as 64bit officially

[MichaIng]

Full native easy WireGuard for every RPi user, that is awesome news! Let's hope it comes with less stability issues compared to early 5.4 releases, but I'm running it for quite a while + all 64-bit users do.

[mrbluecoat]

Looks like March got an updated image: https://downloads.raspberrypi.org/raspios_arm64/images/raspios_arm64-2021-04-09/

[MichaIng]

Also the Lite version: https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_arm64-2021-04-09/
Not sure if it means something regarding general stability/release state of Raspberry Pi OS 64-bit, but good to see that there is some progress.

[MichaIng]

Workarounds for Kodi and Chromium have been applied. In both cases, the Debian package is installed now instead of the RPi repo package, until it ships 64-bit builds.

Once DietPi v7.1 has been released, I move the 64-bit RPi image to stable downloads, likely along with a fresh image based on the new Raspberry Pi OS 64-bit build linked above.

[MichaIng]

I mark this issue as closed. For any other RPi 64-bit related problem, please open a new dedicated issue, as usual 🙂.