Image | Raspberry Pi 5: Testing and firmware migration script

TDuffinNTU commented 1 year ago

ADMIN EDIT

First Raspberry Pi 5 testing images are available now on our download page: https://dietpi.com/#download You can also find images with the new kernel/firmware package set for other RPi models here: https://dietpi.com/downloads/images/testing/ The ones with the new firmware have "RPi1", "RPi2" and "RPi234" (64-bit) in their names. To migrate an existing system, use the migration script:

bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration')

WARNING: This is currently a one-way ticket. dietpi-backup cannot be used to restore the old system, since the boot partition mount point has changed. If you want to be able to revert, create an image of the whole SD card/drive. dietpi-imager can be used from another DietPi (or Debian/Ubuntu) system, to minimise partition and filesystem automatically, to have a small compressed backup image.

Device name | Raspberry Pi 5
Official product URL | https://www.raspberrypi.com/products/raspberry-pi-5/
GitHub resource URL (if available) | https://github.com/raspberrypi
Image download URL |https://www.raspberrypi.com/software/

Is the SBC officially supported by the Debian installer?

Yes(?) Looks like the board is inter-compatible with the same distro images as the 4B. That's pure speculation, mind you, but I did see a video of a reviewer transferring a Raspbian installation from a Pi4B to a Pi5 with no configuration necessary.

Notes

Not sure if this needs any specific developer legwork as the previous Pis seem to be inter-compatible with OS images for the most part (though I'm sure testing and drivers will be necessary!). Thought I'd make this issue now since it might be good to mark the Pi5 as provisionally supported on the website if it at least works out of the box.

MichaIng commented 1 year ago

Okay this requires more work, sadly. With Bookworm and hence for RPi 5, the packages as well as the filesystem layout have changed dramatically:

For RPi 4 and earlier, the package is called linux-image-rpi-v8, which is a meta package and current pulls linux-image-6.1.0-rpi4-rpi-v8.
For RPi 5, the package is called linux-image-rpi-2712, which is a meta package and current pulls linux-image-6.1.0-rpi4-rpi-2712.

These packages are more streamlined with mainline Linux packages, installing kernel image, config, map, device trees and overlays like common Debian Linux packages:

/boot/System.map-6.1.0-rpi4-rpi-2712
/boot/config-6.1.0-rpi4-rpi-2712
/boot/vmlinuz-6.1.0-rpi4-rpi-2712
...
/usr/lib/linux-image-6.1.0-rpi4-rpi-2712/broadcom/bcm2712-rpi-5-b.dtb
...
/usr/lib/linux-image-6.1.0-rpi4-rpi-2712/overlays/README

For the bootloader, there is now a raspi-firmware package, which installs the files as well more streamlined into /usr/lib/raspi-firmware/.
libraspberrypi0, libraspberrypi-bin and raspberrypi-sys-mods remain the same.
The RPi ROM bootloader stage still requires bootloader, config and kernel on a partition 1 with FAT filesystem, which was mounted to /boot. This cause the issue that, since dpkg does not support FAT, this rpikernelhack back and forth copying of all files in /boot was required, to bypass the need to dpkg to replace a file (which would fail). This procedure has now been replaced with another, IMO not less ugly workaround: The FAT filesystem of partition 1 is now mounted to /boot/firmware. The raspi-firmware package strictly requires this directory to be a mount point (now allowing a dir within a mount point) and then copies all kernel, dtb and bootloader files from /boot and /usr/lib/linux-image- over to /boot/firmware, applying the known naming schemes. So a copy back and forth of all those files has been replaced with a single copy, but files remaining permanently on both partitions. And of course, for the 64-bit kernel, it is now actually two kernel images and all related modules, hence disk space requirements have increased.
Furthermore, the raspi-firmware package does now strictly require an initramfs. I have to check whether this means that the kernel has essential modules no builtin anymore, or whether it is actually not required, but just installed and handled for in case. As far as I can see, there is a config flag to disable this copy to /boot/firmware stuff, which then would need to be done manually. So we could write our own script to do this, skipping the initramfs. But at least at the beginning, I am not keen to maintain such, as it will likely change a lot within the next months. Probably a tiny-initramfs is possible, like the moreless dummy one we do now use for Sparky SBC, one which does not include any kernel module, hence servers nearly no purpose (aside of supporting UUIDs on top of PARTUUIDs) aside of satisfying bootloader and/or package script expectations.
Same for the 32-bit image, with the same kernel packages names and suffixes: v6, v7, v7l and v8. But one quirk is that the linux-image-rpi-v8 packages are not contained within the armhf package list, only in the arm64 ones, which is not enabled by default on 32-bit userland.

Joulinar commented 1 year ago

uhh does not sounds like a quick win. 🙄

onurcoskun14 commented 1 year ago

Any updates?

axxis-creator commented 1 year ago

Same Question. :-) I buy a RPI-5 and want to install DietPi for LoxBerry. When can we expect a version?

gaurishhs commented 1 year ago

any updates on this?

MichaIng commented 1 year ago

We will post any updates here when we have some. I was looking further into it. The migration of the partition and installation of the new kernel packages is not too hard. But there is another big problem: Our scripts, and probably RPi's own scripts/programs expect config.txt and cmdline.txt in /boot, while for booting, both must be located in /boot/firmware (with the new package set). This is solved in RPi OS via symlinks. The problem is now that sed -i naturally replaces symlinks with actual files, and we use it a lot to edit their contents. Hence we must replace every occurrence across our whole code with sed -i --follow-symlinks to avoid this. Not understandable why this is not the default since ages, since I cannot imagine any circumstance where one would want to have a symlink replaced with its target file, when using sed on a symlink. However, I can do this quickly with a single command for the whole repo with the use of ... sed 😃. But this needs to be carefully reviewed, since there are variances like sed -Ei and probably some cases or code comments where the replacement must not be applied.

Another problem or better question is what we do with /boot/dietpi and /boot/dietpi.txt. The first, I think is fine to stay on the ext4 partition in the first place, resp. being moved there as part of the migration. The dietpi.txt is however nice to be on the FAT partition, at least before first boot, so one can apply automation and pre-configure the image from Windows and macOS easily. We just added a trailing FAT partition to all other images to make it as easy there as on RPi, so it would be horrible if we now removed this possibility for RPi. Theoretically we could do it on RPi the same way we do on other SBCs: As part of the first boot rootfs expansion script, mount the FAT partition and copy over dietpi.txt, dietpi-wifi.txt and all other optional pre-config files to the rootfs, then unmount it again. This must of course only happen on those RPi images which have the FAT partition mounted to /boot/firmware already.

Btw, does someone of you guys have an RPi 5 already and can tell me the revision code? That way we can add support to our hardware detection script already and provide RPi 5 compatible images between releases, if I am not able to finish this until this Saturday (v8.24 release):

mawk '/^Revision/{print $3;exit}' /proc/cpuinfo

The 3rd and 2nd last characters define the model. "14" was CM4, so it is probably "15" or "16".

jboots07 commented 1 year ago

C04170

adrianog91 commented 1 year ago

Hi, i will receive the Raspberry next week. It is already shipped. I will update you when i receive it.

Very thanks for your amazing work!

Da: jboots07 @.> Inviato: Thursday, November 16, 2023 1:38:24 AM A: MichaIng/DietPi @.> Cc: adrianog91 @.>; Manual @.> Oggetto: Re: [MichaIng/DietPi] Image | Raspberry Pi 5 (Issue #6676)

C04170

— Reply to this email directly, view it on GitHubhttps://github.com/MichaIng/DietPi/issues/6676#issuecomment-1813520469, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADGPFYUSGCNXV4TTNFY4UYDYEVOABAVCNFSM6AAAAAA5ZNEQLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJTGUZDANBWHE. You are receiving this because you are subscribed to this thread.Message ID: @.***>

MichaIng commented 1 year ago

Thanks. Found it now here as well: https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#new-style-revision-codes

So "15" is the CM4S, which is a special industry customer variant, not publicly sold, and "16" for "internal use". Let's see whether "16" is a surprise, not announced yet 🙂.

MichaIng commented 1 year ago

First step: https://github.com/MichaIng/DietPi/commit/6e848a1

jboots07 commented 1 year ago

Thanks for your hard work and update! Let me know if I can help in any way, I have a pi 5.

sorriso93 commented 1 year ago

I just received my PI5 and can't wait to install on it Dietpi to replace my PI4 :-)

BugDave commented 1 year ago

I just received mine too and am excited to put dietpi on it :-)

m0jek commented 1 year ago

@MichaIng when you are ready for testing in the wild on RaspberryPi 5, I am happy to test.

FabioEight commented 1 year ago

Available for testing on Pi 5 as well! Thanks for your efforts!

elisenlebkuch commented 1 year ago

Where can I get it?

gaurishhs commented 1 year ago

I don't think so there has been any image supporting Pi 5, You'll have to wait

elisenlebkuch commented 1 year ago

Oh... This one won´t work? https://dietpi.com/downloads/images/testing/DietPi_Star64-RISC-V-Sid.img.xz

gaurishhs commented 1 year ago

I think that one is for Risc-V https://github.com/MichaIng/DietPi/issues/6212

LittleFreak commented 1 year ago

Is it possible to add the dietpi later on a running raspbian? I'll plan to docker all my programs anyway, so the host will stay pretty much raspbian lite until then.

If so, I'd just give my raspbian a diet later, when its compatible with raspi 5.

MichaIng commented 1 year ago

Is it possible to add the dietpi later on a running raspbian?

You mean on a Raspberry Pi OS? Currently does not work as dietpi-installer installs the old kernel/bootloader/firmware packages and our scripts use sed in various places a way that the /boot/config.txt => /boot/firmware/config.txt (same with cmdline.txt) symlinks are replaced with the actual files, so that the intended changes will not actually apply. See my longer comment above about this issue. Once we added compatibility, dietpi-installer can run on a new RPi OS image, but it will remove all installed software, including Docker in your case. What you could do is backup your /var/lib/docker. Then once dietpi-installer ran through and you boot DietPi, do not install Docker at first, but restore /var/lib/docker to /mnt/dietpi_userdata/docker-data, then install Docker via dietpi-software.

cgmcfall commented 12 months ago

Have a Pi5, happy to test :)

alfredoanton82 commented 12 months ago

Also have a RPI5, happy to help testing.

sergio-ingrao commented 12 months ago

Here, I have another one ready to test.

elisenlebkuch commented 12 months ago

Me too.

Net0o commented 11 months ago

I'm also available for testing.

bwims commented 11 months ago

Just to clarify....

"MichaIng linked a pull request 2 days ago that will close this issue"

Is that Github speak, or does it mean that the latest Dietpi image will work on a Pi 5?

(Sorry if that is a stupid question!)

B.

Joulinar commented 11 months ago

does it mean that the latest Dietpi image will work on a Pi 5

No

We are taking the first steps to adapt to the new firmware. For us, this means intensive testing, as we are making some significant code changes to our scripts. As a first step, we will provide a dedicated image for the RPi5 as soon as it is ready.

bwims commented 11 months ago

Thanks for that. I guess the standard Github dialogues are a bit misleading in that respect! 😃

On Sat, 9 Dec 2023 at 18:24, Joulinar @.***> wrote:

does it mean that the latest Dietpi image will work on a Pi 5

No

We are taking the first steps to adapt to the new firmware. For us, this means intensive testing, as we are making some significant code changes to our scripts. As a first step, we will provide a dedicated image for the RPi5 as soon as it is ready.

— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/6676#issuecomment-1848606657, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENIQ2M74FWOJLCU57CBTPTYISUFBAVCNFSM6AAAAAA5ZNEQLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGYYDMNRVG4 . You are receiving this because you commented.Message ID: @.***>

matttttttttttttt commented 11 months ago

does it mean that the latest Dietpi image will work on a Pi 5

No

We are taking the first steps to adapt to the new firmware. For us, this means intensive testing, as we are making some significant code changes to our scripts. As a first step, we will provide a dedicated image for the RPi5 as soon as it is ready.

Do you have any potential timeline that you could share with us? Your work is greatly appreciated!

LittleFreak commented 11 months ago

does it mean that the latest Dietpi image will work on a Pi 5

No

We are taking the first steps to adapt to the new firmware. For us, this means intensive testing, as we are making some significant code changes to our scripts. As a first step, we will provide a dedicated image for the RPi5 as soon as it is ready.

Do you have any potential timeline that you could share with us? Your work is greatly appreciated!

As stated above Soon™

MichaIng commented 11 months ago

I created a first beta version of a firmware migration script. Would be great if you guys could test it on your RPi systems. With this done, it should also support the RPi 5, i.e. you should be able to swap the SD card (or whichever boot media you use) to the RPi 5 and boot it.

Apply the script like that:

bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration')

It worked well on RPi Zero. Will migrate my RPi 2 now.

Joulinar commented 11 months ago

Means you guys need another RPi where you can prepare the image to be able to run in RPi5. Correct @MichaIng ?

MichaIng commented 11 months ago

For now yes. This was the first step, which I found more important than fresh RPi 5 compatible images: It allows testing our scripts with the new boot mountpoint and new kernel/firmware packages in general. This is also important for older RPi models, since their kernel did not receive an upgrade for too long, with at least one known bug open (Allo Boss2 device tree overlay) and a bunch of kernel vulnerabilities unfixed.

But I am working on fresh images as well.

Looking for your all opinion on something:

The kernel packages are now split by SoC, i.e. one can install e.g. the RPi 1/Zero kernel only, skipping the others, which saves a lot of downloads, processing, disk writes/space etc, especially since now the kernel image is installed on the rootfs as well as additionally on the bootfs. And also an initramfs is now additionally generated for each kernel image (I want to check back whether this is really required, but currently it is a strick package dependencvy).
I want to add a script which allows to select/deselect those kernel packages which are not required for the RPi model you are currently running.
But the question is how we do it with new images:
1. Install all kernel packages supported by the OS/userland architecture, so that the system card/drive can be swapped between RPi models like before.
2. Install only 1 kernel package per image, i.e. providing 5 dedicated 32-bit images and 2 64-bit images, where especially the 32-bit images support only RPi models with the same SoC. When aiming to swap the SD card, it would then be required to first install the new kernel package, which would then be a dietpi-config option.

Isildur981 commented 11 months ago

* But the question is how we do it with new images:

  1. Install all kernel packages supported by the OS/userland architecture, so that the system card/drive can be swapped between RPi models like before.
  2. Install only 1 kernel package per image, i.e. providing 5 dedicated 32-bit images and 2 64-bit images, where especially the 32-bit images support only RPi models with the same SoC. When aiming to swap the SD card, it would then be required to first install the new kernel package, which would then be a `dietpi-config` option.

I vote for SoC and 32/64 bit specific images. Most of the time people are either going to know ahead of time which RPi board they are going to be setting up, or have a computer/laptop with the different images on them and the correct one can then be written to a SD card.

If you feel that it is going to be too much work to produce so many different images for the various RPi boards, I'm not opposed to a single image with all of the kernel packages.

v4run75 commented 11 months ago

* But the question is how we do it with new images:

  1. Install all kernel packages supported by the OS/userland architecture, so that the system card/drive can be swapped between RPi models like before.
  2. Install only 1 kernel package per image, i.e. providing 5 dedicated 32-bit images and 2 64-bit images, where especially the 32-bit images support only RPi models with the same SoC. When aiming to swap the SD card, it would then be required to first install the new kernel package, which would then be a `dietpi-config` option.

As a user of dietpit as long as I can restore the backups from my previous Pi (Pi 4) and carry it on to another one, any of the two options seems great. I don't generally swap out SD cards among different raspberry pis but have predetermined dedicated SD cards for each as @Isildur981 said

(P.S. when I say backup, I mean the option to retain all installed applications & their configurations)

Trainax commented 11 months ago

But the question is how we do it with new images:

Install all kernel packages supported by the OS/userland architecture, so that the system card/drive can be swapped between RPi models like before.

Install only 1 kernel package per image, i.e. providing 5 dedicated 32-bit images and 2 64-bit images, where especially the 32-bit images support only RPi models with the same SoC. When aiming to swap the SD card, it would then be required to first install the new kernel package, which would then be a dietpi-config option.

As stated by other users I think it would be better to have separate images because many users tend to have a pre-determined SD card for each Pi so swapping the SD card between Pis is not something they (me included) do.

However if creating multiple images is difficult I'm also OK with a single image with all the kernel packages even if I imagine it would be bigger in size

btb23 commented 11 months ago

I would vote for option 1, keep the images as they are now. Being able to swap from one pi model to another, the ability to develop and move around is worth keeping.

adrianog91 commented 11 months ago

Same for me option 1, keep the images as they are now. In this way we can swap from one model to another model.

btb23 commented 11 months ago

I had a go at migrating headless zeroW over ssh and did this..

dietpi@DietPi70:~$ sudo bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration')
bash: /dev/fd/63: No such file or directory
dietpi@DietPi70:~$ curl: (23) Failed writing body

I wasn't sure if that was meant to run that way anyway via ssh command line, so then did this

dietpi@DietPi70:~$ wget 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration'     --2023-12-15 08:42:17--  https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.111.133, 185.199.109.133, 185.199.108.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.111.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2441 (2.4K) [text/plain]
Saving to: ‘dietpi-rpi-firmware-migration’

dietpi-rpi-firmware-migration 100%[=================================================>]   2.38K  --.-KB/s    in 0.003s

2023-12-15 08:42:18 (753 KB/s) - ‘dietpi-rpi-firmware-migration’ saved [2441/2441]

dietpi@DietPi70:~$ sudo bash dietpi-rpi-firmware-migration
[  OK  ] dietpi-rpi-firmware-migration | Free space check: path=/ | available=17876 MiB | required=200 MiB
[ INFO ] dietpi-rpi-firmware-migration | Updating DietPi to latest version
[ SUB1 ] DietPi-Update > Checking for available DietPi update
[  OK  ] DietPi-Update | Checking IPv4 network connectivity
[  OK  ] DietPi-Update | Checking DNS resolver
[ INFO ] DietPi-Update | Getting latest version from: https://raw.githubusercontent.com/MichaIng/DietPi/beta/.update/version
[  OK  ] DietPi-Update | Got valid latest version: 8.25.0
[  OK  ] DietPi-Update | No update required, your DietPi installation is already up to date:
[ INFO ] DietPi-Update | Current version : v8.25.0
[ INFO ] DietPi-Update | Latest version  : v8.25.0
[ INFO ] DietPi-Update | Checking for new available live patches
[ INFO ] DietPi-Update | APT update, please wait...
Hit:1 http://raspbian.raspberrypi.org/raspbian bookworm InRelease
Hit:2 https://archive.raspberrypi.org/debian bookworm InRelease
Reading package lists...
[  OK  ] DietPi-Update | APT update
[ INFO ] DietPi-Update | No APT upgrades were found, not creating file: /run/dietpi/.apt_updates
[  OK  ] dietpi-rpi-firmware-migration | mkdir -p rootfs
[  OK  ] dietpi-rpi-firmware-migration | mount /dev/mmcblk0p2 rootfs
[  OK  ] dietpi-rpi-firmware-migration | cp -a /boot/dietpi /boot/dietpi-LICENSE.txt /boot/dietpi-README.md /boot/dietpi.txt rootfs/boot/
[  OK  ] dietpi-rpi-firmware-migration | mkdir -p rootfs/boot/firmware
[  OK  ] dietpi-rpi-firmware-migration | sed -i s|[[:blank:]]/boot[[:blank:]]| /boot/firmware | /etc/fstab
[  OK  ] dietpi-rpi-firmware-migration | systemctl daemon-reload
[  OK  ] dietpi-rpi-firmware-migration | umount /boot
[  OK  ] dietpi-rpi-firmware-migration | mount /boot/firmware
[  OK  ] dietpi-rpi-firmware-migration | umount rootfs
[  OK  ] dietpi-rpi-firmware-migration | ln -s firmware/cmdline.txt /boot/cmdline.txt
[  OK  ] dietpi-rpi-firmware-migration | ln -s firmware/config.txt /boot/config.txt
[  OK  ] dietpi-rpi-firmware-migration | dpkg --add-architecture arm64
[ INFO ] dietpi-rpi-firmware-migration | APT update, please wait...
Hit:1 http://raspbian.raspberrypi.org/raspbian bookworm InRelease
Hit:2 https://archive.raspberrypi.org/debian bookworm InRelease
Get:3 https://archive.raspberrypi.org/debian bookworm/main arm64 Packages [352 kB]
Fetched 352 kB in 10s (34.2 kB/s)
Reading package lists...
[  OK  ] dietpi-rpi-firmware-migration | APT update
[ INFO ] dietpi-rpi-firmware-migration | APT install linux-image-rpi-v8 linux-image-rpi-2712 linux-image-rpi-v6 linux-image-rpi-v7 linux-image-rpi-v7l raspi-firmware, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  cpio initramfs-tools initramfs-tools-core klibc-utils libklibc linux-base
  linux-image-6.1.0-rpi7-rpi-2712:arm64 linux-image-6.1.0-rpi7-rpi-v6
  linux-image-6.1.0-rpi7-rpi-v7 linux-image-6.1.0-rpi7-rpi-v7l
  linux-image-6.1.0-rpi7-rpi-v8:arm64
Suggested packages:
  libarchive-dev linux-doc-6.1:arm64 debian-kernel-handbook:arm64
  linux-doc-6.1 debian-kernel-handbook bluez-firmware
Recommended packages:
  busybox | busybox-static zstd apparmor:arm64 apparmor
The following NEW packages will be installed:
  cpio initramfs-tools initramfs-tools-core klibc-utils libklibc linux-base
  linux-image-6.1.0-rpi7-rpi-2712:arm64 linux-image-6.1.0-rpi7-rpi-v6
  linux-image-6.1.0-rpi7-rpi-v7 linux-image-6.1.0-rpi7-rpi-v7l
  linux-image-6.1.0-rpi7-rpi-v8:arm64 linux-image-rpi-2712:arm64
  linux-image-rpi-v6 linux-image-rpi-v7 linux-image-rpi-v7l
  linux-image-rpi-v8:arm64 raspi-firmware
0 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.
Need to get 139 MB of archives.
After this operation, 175 MB of additional disk space will be used.
Get:5 https://archive.raspberrypi.org/debian bookworm/main armhf raspi-firmware all 1:1.20231024+ds-1+rpt2 [4551 kB]
Get:8 https://archive.raspberrypi.org/debian bookworm/main arm64 linux-image-6.1.0-rpi7-rpi-2712 arm64 1:6.1.63-1+rpt1 [28.1 MB]
Get:1 http://raspbian.raspberrypi.org/raspbian bookworm/main armhf cpio armhf 2.13+dfsg-7.1 [229 kB]
Get:2 http://raspbian.raspberrypi.org/raspbian bookworm/main armhf libklibc armhf 2.0.12-1+rpi1 [42.1 kB]
Get:3 http://raspbian.raspberrypi.org/raspbian bookworm/main armhf klibc-utils armhf 2.0.12-1+rpi1 [87.1 kB]
Get:4 http://mirror.infernocomms.net/raspbian/raspbian bookworm/main armhf initramfs-tools-core all 0.142 [105 kB]
Get:6 http://mirror.infernocomms.net/raspbian/raspbian bookworm/main armhf linux-base all 4.9 [31.8 kB]
Get:7 http://mirror.infernocomms.net/raspbian/raspbian bookworm/main armhf initramfs-tools all 0.142 [72.9 kB]
Get:9 https://archive.raspberrypi.org/debian bookworm/main armhf linux-image-6.1.0-rpi7-rpi-v6 armhf 1:6.1.63-1+rpt1 [25.2 MB]
Get:10 https://archive.raspberrypi.org/debian bookworm/main armhf linux-image-6.1.0-rpi7-rpi-v7 armhf 1:6.1.63-1+rpt1 [25.8 MB]
Get:11 https://archive.raspberrypi.org/debian bookworm/main armhf linux-image-6.1.0-rpi7-rpi-v7l armhf 1:6.1.63-1+rpt1 [26.4 MB]
Get:12 https://archive.raspberrypi.org/debian bookworm/main arm64 linux-image-6.1.0-rpi7-rpi-v8 arm64 1:6.1.63-1+rpt1 [28.1 MB]
Get:13 https://archive.raspberrypi.org/debian bookworm/main arm64 linux-image-rpi-2712 arm64 1:6.1.63-1+rpt1 [1424 B]
Get:14 https://archive.raspberrypi.org/debian bookworm/main armhf linux-image-rpi-v6 armhf 1:6.1.63-1+rpt1 [1424 B]
Get:15 https://archive.raspberrypi.org/debian bookworm/main armhf linux-image-rpi-v7 armhf 1:6.1.63-1+rpt1 [1424 B]
Get:16 https://archive.raspberrypi.org/debian bookworm/main armhf linux-image-rpi-v7l armhf 1:6.1.63-1+rpt1 [1428 B]
Get:17 https://archive.raspberrypi.org/debian bookworm/main arm64 linux-image-rpi-v8 arm64 1:6.1.63-1+rpt1 [1424 B]
Preconfiguring packages ...
Fetched 139 MB in 1min 26s (1606 kB/s)
                                      Selecting previously unselected package raspi-firmware.
(Reading database ... 57470 files and directories currently installed.)
Preparing to unpack .../00-raspi-firmware_1%3a1.20231024+ds-1+rpt2_all.deb ...
Unpacking raspi-firmware (1:1.20231024+ds-1+rpt2) ...
^ASelecting previously unselected package cpio.
Preparing to unpack .../01-cpio_2.13+dfsg-7.1_armhf.deb ...
Unpacking cpio (2.13+dfsg-7.1) ...
Selecting previously unselected package libklibc:armhf.
Preparing to unpack .../02-libklibc_2.0.12-1+rpi1_armhf.deb ...
Unpacking libklibc:armhf (2.0.12-1+rpi1) ...
Selecting previously unselected package klibc-utils.
Preparing to unpack .../03-klibc-utils_2.0.12-1+rpi1_armhf.deb ...
Unpacking klibc-utils (2.0.12-1+rpi1) ...
Selecting previously unselected package initramfs-tools-core.
Preparing to unpack .../04-initramfs-tools-core_0.142_all.deb ...
Unpacking initramfs-tools-core (0.142) ...
Selecting previously unselected package linux-base.
Preparing to unpack .../05-linux-base_4.9_all.deb ...
Unpacking linux-base (4.9) ...
Selecting previously unselected package initramfs-tools.
Preparing to unpack .../06-initramfs-tools_0.142_all.deb ...
Unpacking initramfs-tools (0.142) ...
Selecting previously unselected package linux-image-6.1.0-rpi7-rpi-2712:arm64.
Preparing to unpack .../07-linux-image-6.1.0-rpi7-rpi-2712_1%3a6.1.63-1+rpt1_arm64.deb ...
Unpacking linux-image-6.1.0-rpi7-rpi-2712:arm64 (1:6.1.63-1+rpt1) ...
Selecting previously unselected package linux-image-6.1.0-rpi7-rpi-v6.
Preparing to unpack .../08-linux-image-6.1.0-rpi7-rpi-v6_1%3a6.1.63-1+rpt1_armhf.deb ...
Unpacking linux-image-6.1.0-rpi7-rpi-v6 (1:6.1.63-1+rpt1) ...
Selecting previously unselected package linux-image-6.1.0-rpi7-rpi-v7.
Preparing to unpack .../09-linux-image-6.1.0-rpi7-rpi-v7_1%3a6.1.63-1+rpt1_armhf.deb ...
Unpacking linux-image-6.1.0-rpi7-rpi-v7 (1:6.1.63-1+rpt1) ...
Selecting previously unselected package linux-image-6.1.0-rpi7-rpi-v7l.
Preparing to unpack .../10-linux-image-6.1.0-rpi7-rpi-v7l_1%3a6.1.63-1+rpt1_armhf.deb ...
Unpacking linux-image-6.1.0-rpi7-rpi-v7l (1:6.1.63-1+rpt1) ...
Selecting previously unselected package linux-image-6.1.0-rpi7-rpi-v8:arm64.
Preparing to unpack .../11-linux-image-6.1.0-rpi7-rpi-v8_1%3a6.1.63-1+rpt1_arm64.deb ...
Unpacking linux-image-6.1.0-rpi7-rpi-v8:arm64 (1:6.1.63-1+rpt1) ...
Selecting previously unselected package linux-image-rpi-2712:arm64.
Preparing to unpack .../12-linux-image-rpi-2712_1%3a6.1.63-1+rpt1_arm64.deb ...
Unpacking linux-image-rpi-2712:arm64 (1:6.1.63-1+rpt1) ...
Selecting previously unselected package linux-image-rpi-v6.
Preparing to unpack .../13-linux-image-rpi-v6_1%3a6.1.63-1+rpt1_armhf.deb ...
Unpacking linux-image-rpi-v6 (1:6.1.63-1+rpt1) ...
Selecting previously unselected package linux-image-rpi-v7.
Preparing to unpack .../14-linux-image-rpi-v7_1%3a6.1.63-1+rpt1_armhf.deb ...
Unpacking linux-image-rpi-v7 (1:6.1.63-1+rpt1) ...
Selecting previously unselected package linux-image-rpi-v7l.
Preparing to unpack .../15-linux-image-rpi-v7l_1%3a6.1.63-1+rpt1_armhf.deb ...
Unpacking linux-image-rpi-v7l (1:6.1.63-1+rpt1) ...
Selecting previously unselected package linux-image-rpi-v8:arm64.
Preparing to unpack .../16-linux-image-rpi-v8_1%3a6.1.63-1+rpt1_arm64.deb ...
Unpacking linux-image-rpi-v8:arm64 (1:6.1.63-1+rpt1) ...
Setting up cpio (2.13+dfsg-7.1) ...
update-alternatives: using /bin/mt-gnu to provide /bin/mt (mt) in auto mode
Setting up linux-base (4.9) ...
Setting up libklibc:armhf (2.0.12-1+rpi1) ...
Setting up raspi-firmware (1:1.20231024+ds-1+rpt2) ...
Setting up klibc-utils (2.0.12-1+rpi1) ...
No diversion 'diversion of /usr/share/initramfs-tools/hooks/klibc to /usr/share/initramfs-tools/hooks/klibc^i-t by klibc-utils', none removed.
Setting up initramfs-tools-core (0.142) ...
Setting up initramfs-tools (0.142) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-image-6.1.0-rpi7-rpi-2712:arm64 (1:6.1.63-1+rpt1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-v8
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-2712
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-rpi7-rpi-2712
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-rpi7-rpi-2712
W: No zstd in /usr/bin:/sbin:/bin, using gzip
Setting up linux-image-6.1.0-rpi7-rpi-v8:arm64 (1:6.1.63-1+rpt1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-2712
I: /initrd.img.old is now a symlink to boot/initrd.img-6.1.0-rpi7-rpi-2712
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-v8
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-rpi7-rpi-v8
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-rpi7-rpi-v8
W: No zstd in /usr/bin:/sbin:/bin, using gzip
Setting up linux-image-6.1.0-rpi7-rpi-v7l (1:6.1.63-1+rpt1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-v8
I: /initrd.img.old is now a symlink to boot/initrd.img-6.1.0-rpi7-rpi-v8
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-v7l
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-rpi7-rpi-v7l
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-rpi7-rpi-v7l
W: No zstd in /usr/bin:/sbin:/bin, using gzip
Setting up linux-image-rpi-v7l (1:6.1.63-1+rpt1) ...
Setting up linux-image-rpi-2712:arm64 (1:6.1.63-1+rpt1) ...
Setting up linux-image-6.1.0-rpi7-rpi-v7 (1:6.1.63-1+rpt1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-v7l
I: /initrd.img.old is now a symlink to boot/initrd.img-6.1.0-rpi7-rpi-v7l
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-v7
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-rpi7-rpi-v7
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-rpi7-rpi-v7
W: No zstd in /usr/bin:/sbin:/bin, using gzip
Setting up linux-image-6.1.0-rpi7-rpi-v6 (1:6.1.63-1+rpt1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-v7
I: /initrd.img.old is now a symlink to boot/initrd.img-6.1.0-rpi7-rpi-v7
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-rpi7-rpi-v6
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-rpi7-rpi-v6
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-6.1.0-rpi7-rpi-v6
W: No zstd in /usr/bin:/sbin:/bin, using gzip
Setting up linux-image-rpi-v8:arm64 (1:6.1.63-1+rpt1) ...
Setting up linux-image-rpi-v6 (1:6.1.63-1+rpt1) ...
Setting up linux-image-rpi-v7 (1:6.1.63-1+rpt1) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.1.0-rpi7-rpi-v8
W: No zstd in /usr/bin:/sbin:/bin, using gzip
[  OK  ] dietpi-rpi-firmware-migration | APT install linux-image-rpi-v8 linux-image-rpi-2712 linux-image-rpi-v6 linux-image-rpi-v7 linux-image-rpi-v7l raspi-firmware
[ INFO ] dietpi-rpi-firmware-migration | APT purge raspberrypi-kernel raspberrypi-headers-kernel raspberrypi-bootloader, please wait...
Reading package lists...
Building dependency tree...
Reading state information...
The following packages will be REMOVED:
  raspberrypi-bootloader* raspberrypi-kernel*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
                                                              After this operation, 140 MB disk space will be freed.
                                                                                                                    (Rea(Reading database ... 70153 files and directories currently installed.)
Removing raspberrypi-bootloader (1:1.20230405-1) ...
Removing raspberrypi-kernel (1:1.20230405-1) ...
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 6.1.21+ /boot/kernel.img
run-parts: executing /etc/kernel/postrm.d/z50-raspi-firmware 6.1.21+ /boot/kernel.img
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 6.1.21-v7+ /boot/kernel7.img
run-parts: executing /etc/kernel/postrm.d/z50-raspi-firmware 6.1.21-v7+ /boot/kernel7.img
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 6.1.21-v7l+ /boot/kernel7l.img
run-parts: executing /etc/kernel/postrm.d/z50-raspi-firmware 6.1.21-v7l+ /boot/kernel7l.img
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 6.1.21-v8+ /boot/kernel8.img
run-parts: executing /etc/kernel/postrm.d/z50-raspi-firmware 6.1.21-v8+ /boot/kernel8.img
(Reading database ... 61365 files and directories currently installed.)
Purging configuration files for raspberrypi-kernel (1:1.20230405-1) ...
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 6.1.21+ /boot/kernel.img
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.21+
run-parts: executing /etc/kernel/postrm.d/z50-raspi-firmware 6.1.21+ /boot/kernel.img
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 6.1.21-v7+ /boot/kernel7.img
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.21-v7+
run-parts: executing /etc/kernel/postrm.d/z50-raspi-firmware 6.1.21-v7+ /boot/kernel7.img
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 6.1.21-v7l+ /boot/kernel7l.img
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.21-v7l+
run-parts: executing /etc/kernel/postrm.d/z50-raspi-firmware 6.1.21-v7l+ /boot/kernel7l.img
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 6.1.21-v8+ /boot/kernel8.img
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.21-v8+
run-parts: executing /etc/kernel/postrm.d/z50-raspi-firmware 6.1.21-v8+ /boot/kernel8.img
[  OK  ] dietpi-rpi-firmware-migration | APT purge raspberrypi-kernel raspberrypi-headers-kernel raspberrypi-bootloader
[  OK  ] dietpi-rpi-firmware-migration | rm -Rf /boot/firmware/dietpi /boot/firmware/dietpi-LICENSE.txt /boot/firmware/dietpi-README.md /boot/firmware/dietpi.txt /boot/firmware/COPYING.linux
dietpi@DietPi70:~$

That seemed to work as expected. I rebooted the zeroW and that was OK. Powered off and put the sd card into the pi5 but it doesn't boot. I just hear the pi5 fan spinning, it isn't booting.

I'm probably doing something wrong, but haven't investigated further thinking I should just report back.

EDIT: I don't know why there is the a line through all the code, it isn't in the code I pasted, but as you can still read it I'll leave it

Joulinar commented 11 months ago

Best is to use root user for such activities. Anyway. Did you moved to latest DietPi v8.25 Beta before? And the Zero W was running 32bit before? Right?

MichaIng commented 11 months ago

I think I know the problem. I was told that the 2712 kernel supports 64-bit userland only, while you run 32-bit userland. I guess the RPi 5 picks this kernel with priority, but then fails to load the 32-bit init system. The v8 kernel supports RPi 5 as well and 32-bit.

Hence, please attach the card to the RPi Zero again, then:

G_AGP linux-image-rpi-2712

Then try again to boot it on RPi 5.

matttttttttttttt commented 11 months ago

I created a first alpha version of a firmware migration script. Would be great if you guys could test it on your RPi systems. With this done, it should also support the RPi 5, i.e. you should be able to swap the SD card (or whichever boot media you use) to the RPi 5 and boot it.

But you must apply the current DietPi v8.25 beta first: #6801

Then apply the script like that:
bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration')
It worked well on RPi Zero. Will migrate my RPi 2 now.

This worked perfectly going from [aspberry Pi 4 Model B to Raspberry 5! Thank you so much :)

MichaIng commented 11 months ago

Do you use a 64-bit image? If so, can you check whether the 2712 kernel is used?

uname -a

matttttttttttttt commented 11 months ago

Do you use a 64-bit image? If so, can you check whether the 2712 kernel is used?
uname -a

Yes!

root@DietPi:~# uname -a
Linux DietPi 6.1.0-rpi7-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux

MichaIng commented 11 months ago

Great. Then I better understood this package split.

matttttttttttttt commented 11 months ago

Everything works out of the box. I think they are a few things that needs some adjustments, but I am so blown away that this already works flawless.

Danke Micha :)

bwims commented 11 months ago

Just a thought - will the power button be supported? From here

The Raspberry Pi 5 has a power button.

Once Pi OS has booted, in Linux it appears to the operating system as a normal key input providing KEY_POWER scan code.

/etc/systemctl/logind.conf can be used to define what happens when the button is pressed. On the Pi OS lite image it'll shut down by default. On the full desktop image the shutdown dialogue will be displayed, and if you press it again, it will shut down.

B.

jboots07 commented 11 months ago

I created a first alpha version of a firmware migration script. Would be great if you guys could test it on your RPi systems. With this done, it should also support the RPi 5, i.e. you should be able to swap the SD card (or whichever boot media you use) to the RPi 5 and boot it.

But you must apply the current DietPi v8.25 beta first: #6801

Then apply the script like that:
bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-rpi-firmware-migration')
It worked well on RPi Zero. Will migrate my RPi 2 now.
This worked perfectly going from [aspberry Pi 4 Model B to Raspberry 5! Thank you so much :)

Hmm I applied beta to an existing system, runs fine on 4 still, put into 5 and fan just stays on full speed and no boot.

LittleFreak commented 11 months ago

But the question is how we do it with new Images

Install all kernel packages supported by the OS/userland architecture, so that the system card/drive can be swapped between RPi models like before.

Install only 1 kernel package per image, i.e. providing 5 dedicated 32-bit images and 2 64-bit images, where especially the 32-bit images support only RPi models with the same SoC. When aiming to swap the SD card, it would then be required to first install the new kernel package, which would then be a dietpi-config option.

I assume there has to be a kernel present to boot, instead of waiting for a used input to download the selected kernel on the fly?

If so, why don't choose option

All kernel packages supported will be installed with the first boot, but will be replaced with its specific kernel packages (unnecessary one deleted) after it's complete setup, if the user says so via input (or 'dietpi-config' for headless setups). Non-headless would require an input from the user.

Why? It's the best of both worlds.

It would allow to install dietpi on an existing/running raspbian os => explained here=> @MichaIng in https://github.com/MichaIng/DietPi/issues/6676#issuecomment-1826815748
some users switch cards between different raspi Gen (as backup f. I.)
others use docker for those backup purposes and only need 1 kernel
unity would eliminate the need of multiple images and ease the download for consumer (but might also increase server traffic)

Feel free to correct me, if I'm completely wrong

MichaIng / DietPi