Image | Radxa ZERO 3

[SelfhostedPro]

Creating an image request

Formal device information

• Device name | Radxa Zero 3 W
• Official product URL | https://radxa.com/products/zeros/zero3w
• GitHub resource URL | https://github.com/radxa
• Image download URL | https://github.com/radxa-build/radxa-zero3/releases/tag/b6

Is the SBC officially supported by the Debian installer?

• It appears to but with some caviats described in the image download url

If not, is a reliable 3rd party Debian image available for this SBC?

• ...

If not, are there install instructions for Debian available?

Here are the official instructions for installing an OS: https://docs.radxa.com/en/zero/zero3/getting-started/install-os

[SelfhostedPro]

Also, I am happy to get a board for whoever needs it to test. Just reach out to me on discord or email and ping me here. @selfhostedpro on discord and my email is on my profile.

[SelfhostedPro]

I've been working on building this myself but have been running into the following issue and am not fully sure why/how to resolve it:

[  OK  ] DietPi-Imager | Creating minified image from:
- Image: build/output/images/Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
- Root device: /dev/loop3p2
- Via dd to DietPi_RadxaZero3-server-bookworm-vendor.img
- With intermediate mounting turned Off
[ INFO ] DietPi-Imager | GPT partition table detected, moving GPT backup partition table to end of drive...
[ INFO ] DietPi-Imager | Checking for required APT packages: gdisk
[ INFO ] DietPi-Imager | sgdisk -e /dev/loop3, please wait...

Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.
[FAILED] DietPi-Imager | sgdisk -e /dev/loop3

https://github.com/SelfhostedPro/radxa-zero3w/actions/runs/8768056685/job/24062001873#step:10:37

I'm building out some actions to clone/build armbian as well as diet pi. I also run into this same issue trying to build with imager on my pi5.

[MichaIng]

Seems the image was cut after the partition table was generated, so that the secondary/backup partition table was cut off. A little unclean, but it is a backup partition table only. We assure it is present and at the right position since it otherwise throws warnings whenever touching the partition table. But probably those can be ignored, as we do the same after everything has been done, so the final image will have the backup partition table present and correctly located in any case.

Can you try this version of the script: https://raw.githubusercontent.com/MichaIng/DietPi/imager/.build/images/dietpi-imager Would be interesting to know whether you see additional warnings by some of the commands, especially sfdisk.

[SelfhostedPro]

I believe that's the version I'm using here: https://github.com/SelfhostedPro/radxa-zero3w/blob/98020929a55d62b304dc053b6a40d72ca6a1ce6f/.github/workflows/armbian_custom.yml#L153 (unless you meant to recommend one other than what's in the master branch of your repo)

I'm also going to try to have armbian use mbr for the partition table and see if that helps. edit: armbian seems to ignore me passing through the IMAGE_PARTITION_TABLE variable so I guess I won't.

Here is the action if you're curious of the context: https://github.com/SelfhostedPro/radxa-zero3w/blob/98020929a55d62b304dc053b6a40d72ca6a1ce6f/.github/workflows/armbian_custom.yml

The dietpi side of things is currently here: https://github.com/SelfhostedPro/radxa-zero3w/blob/98020929a55d62b304dc053b6a40d72ca6a1ce6f/.github/workflows/armbian_custom.yml#L142-L153

[SelfhostedPro]

Ah, latest one got much further but runs into the same error: https://github.com/SelfhostedPro/radxa-zero3w/actions/runs/8768856129/job/24063717270#step:11:192

[SelfhostedPro]

I've tried a few variations of options but am still running into similar errors.

https://github.com/SelfhostedPro/radxa-zero3w/actions/workflows/armbian_custom.yml

These are the actions. Arabian builds fine but still having the same issue with the diet-pi imager.

Would you be opposed to me rewriting it in python? Feel like it has enough functionality that it would be beneficial to have the debugging features and readability.

[MichaIng]

Ah, I didn't know that workflow. Please try to replace master with imager branch here: https://github.com/SelfhostedPro/radxa-zero3w/blob/98020929a55d62b304dc053b6a40d72ca6a1ce6f/.github/workflows/armbian_custom.yml#L153

An alternative would be indeed to use MBR instead of GPT partition table, but there are bootloader builds which do not support MBR, so it might then fail to boot. A matter of testing.

[SelfhostedPro]

Hey, sorry. I have tried that in my latest runs and it got further than with master but still fails:

https://github.com/SelfhostedPro/radxa-zero3w/blob/main/.github/workflows/armbian_custom.yml

https://github.com/SelfhostedPro/radxa-zero3w/actions/runs/8770310869/job/24066758618#step:11:169

(Also tried messing around the dos partition variables).

[MichaIng]

Ah I see, this is on the final sgdisk call now, which we definitely want to keep:

Warning! Disk size is smaller than the main header indicates!
...
Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.

I wonder whether the partition table is (much!) larger than the 34 sectors we expect. This is the default, covering 128 partition entries: https://en.wikipedia.org/wiki/GUID_Partition_Table The last line however seems to indicate that the table covers more than 8056 entries. Each entry has 128 bytes. Hence this would be 8056*128=1031168 bytes, which is exactly 1031168/512=2014 sectors, surely meant by "blocks" in the second last line. This partition table hence is sized to cover 8184 entries, for whatever reason. Since the error message with the original dietpi-imager was the same, where sfdisk did not touch the partition table yet, the Armbian image itself comes with this GPT size, and sfdisk does not change it but keeps what is given (reasonably).

I see no evidence in the Armbian scripts that a non-default partition table size is used: https://github.com/armbian/build/blob/main/lib/functions/image/partitioning.sh Do you add any customisations which could lead to this?

I wonder whether there is a way to read the GPT size (number of possible entries). gdisk at least has a command s to resize it, also indicated in the error message, but I cannot find such for sgdisk, sfdisk or parted, hence it is not nice (but possible) to script this: https://manpages.debian.org/bookworm/gdisk/gdisk.8.en.html#s~2

[SelfhostedPro]

This is the commit that added board support to Armbian:

https://github.com/armbian/build/blob/main/config/boards/radxa-zero3.wip

This is the command I'm using for the build: https://github.com/SelfhostedPro/radxa-zero3w/blob/acd31e2c4b010296a3ccf5e3af4819a6eca6dd36/.github/workflows/armbian_custom.yml#L108

I don't think anything would modify the partition tables from standard from looking though.

[MichaIng]

Looks all good, nothing which should affect the partition table size generated on the fresh loop device for image generation. It is too late for today here, but I'll add the gdisk command to our script tomorrow, to resize the GPT to 128 entries, right before moving the backup partition table. I hope I also find a way to print that size instead, so we could also keep it and adjust the image size accordingly. Though, reading through the sgdisk man page, which supports 128 entries only, any other size can cause issues with other programs as well, so it might have some benefit to enforce 128.

Makes sense to test a recent official Armbian image as well, whether it has the same GPT size.

[SelfhostedPro]

Sounds good. Have a good night and I appreciate your help with this!

[MichaIng]

I played with this image, too curious:

root@dietpi:/tmp# sgdisk -p Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
Disk Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img: 5185536 sectors, 2.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 8FE29520-29EE-AB4D-B92F-A6C93E1B2D6F
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 5185502
Partitions will be aligned on 2048-sector boundaries
Total free space is 30720 sectors (15.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1           32768          557055   256.0 MiB   EA00  bootfs
   2          557056         5185502   2.2 GiB     8300  rootfs
root@dietpi:/tmp# sgdisk -e Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img

Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.
root@dietpi:/tmp# ls -l Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
-rw-r--r-- 1 root root 2654994432 Apr 21 23:05 Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
2024-04-22 00:43:41 root@dietpi:/tmp# gdisk Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img
GPT fdisk (gdisk) version 1.0.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): x

Expert command (? for help): s
Current partition table size is 128.
Enter new size (4 up, default 128): 128

Expert command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
root@dietpi:/tmp# sgdisk -e Armbian-unofficial_24.5.0-trunk.434_Radxa-zero3_bookworm_vendor_6.1.43.img

Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.
root@dietpi:/tmp#

This is so weird: The GPT table has the expected 128 entries size. With the end of the last partition, the required image size is hence 2.654.994.432 bytes, which is exactly (to the exact byte) the size of the image file. So it is exactly as we expect, the last partition is expanded (by Armbian script auto-sizing of last partition) exactly to leave the last 34 sectors free for the backup partition table. And still, even after resetting the size and rewriting the table, it still shows this weird error about the overlap. I do not wonder whether this is a bug in sgdisk, since neither sfdisk, fdisk, gdisk or parted show any error when printing or writing the partition table. However, I did just generated another new image successfully today, which is sized the exact same way, and above sgdisk version is 1.0.10 while Ubuntu Jammy (GitHub Actions runner) is 1.0.8, hence this would not be a recent bug and it would still affect specific images only.

One thing to check is whether the bootloader is probably flashed a way that it is interpreted by sgdisk as part of the GPT. That ~1 MiB size is at least within the range of U-Boot images/binaries.

[SelfhostedPro]

Would there be an alternative command to sgdisk that we could utilize? Or something I could run in the armbian customization process to enable another command to use if it is an error? I’ll be able to mess with the image file some tomorrow to see if I can find a workaround.

How would I go about checking that the bootloader is flashed that way?

[SelfhostedPro]

Also, just wanting to link the pr in armbian that added support: https://github.com/armbian/build/pull/6420

[disablewong]

em.... it seems there is a problem with the image creation script, I am not sure if it is similar to my previous case with Orangepi 3B. The problem gone after I switched to different base image with newer kernel version with different partition table structure.

https://dietpi.com/forum/t/failure-in-creating-image-through-imager-script/18035

[SelfhostedPro]

It looks like someone had success using the official radxa image here: https://forum.radxa.com/t/share-of-unofficial-dietpi-image-for-radxa-zero-3w/20430/5

[MichaIng]

Interesting, @disablewong I did not remember your identical report from last year. I just tested the community maintained Orange Pi 3B image, and it is the same: https://github.com/armbian/community/releases/download/24.5.0-trunk.433/Armbian_community_24.5.0-trunk.433_Orangepi3b_bookworm_vendor_6.1.43_minimal.img.xz

root@dietpi:/tmp# sgdisk -e Armbian_community_24.5.0-trunk.433_Orangepi3b_bookworm_vendor_6.1.43_minimal.img

Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.

Same with officially supported Orange Pi 5 image, so all Armbian images with GPT partition table are affected. I am just not sure why, since our own GPT images go through it fine, and the partition table definitely has the default 128 entries and GPT overall 34 sectors size. The Armbian scripts seem to do something on their partitioning which makes sgdisk think it would be 2048 sectors or 1 MiB. Strangely, when using the tool to print the partition table, it as well says 34 sectors:

root@dietpi:/tmp# sgdisk -p Armbian_24.2.1_Orangepi5_jammy_legacy_5.10.160_minimal.img
Disk Armbian_24.2.1_Orangepi5_jammy_legacy_5.10.160_minimal.img: 3203072 sectors, 1.5 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 1718C59C-EE29-C949-AA5C-4CC4048AC17C
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 3203038
Partitions will be aligned on 2048-sector boundaries
Total free space is 30720 sectors (15.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1           32768          557055   256.0 MiB   EA00  bootfs
   2          557056         3203038   1.3 GiB     8300  rootfs

This caught my eyes:

First usable sector is 2048, last usable sector is 3203038
Partitions will be aligned on 2048-sector boundaries

Let's compare with our image:

root@dietpi:/tmp# sgdisk -p DietPi_OrangePi5-ARMv8-Bookworm.img
Disk DietPi_OrangePi5-ARMv8-Bookworm.img: 2097185 sectors, 1024.0 MiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 75DABD45-859D-4B22-BC6C-615235F05849
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 2097151
Partitions will be aligned on 2048-sector boundaries
Total free space is 32734 sectors (16.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1           32768         2095103   1007.0 MiB  8300  root
   2         2095104         2097151   1024.0 KiB  0700

The partitions in our case are 2048 sectors aligned as well, but in case of Armbian, this seems to apply for the GPT as well. And there it is: https://manpages.debian.org/bookworm/fdisk/sfdisk.8.en.html#Header_lines

first-lba

Specify the first usable sector for GPT partitions.

And fdisk/sfdisk use 2048 by default:

root@dietpi:/tmp# fdisk DietPi_OrangePi5-ARMv8-Bookworm.img
Command (m for help): g
Created a new GPT disklabel (GUID: 1D1C8CDB-7107-4CED-9993-337EB5552081).
Command (m for help): w
The partition table has been altered.
Syncing disks.
root@dietpi:/tmp# sgdisk -p DietPi_OrangePi5-ARMv8-Bookworm.img
Disk DietPi_OrangePi5-ARMv8-Bookworm.img: 2097185 sectors, 1024.0 MiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 1D1C8CDB-7107-4CED-9993-337EB5552081
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 2097151
Partitions will be aligned on 2048-sector boundaries
Total free space is 2095104 sectors (1023.0 MiB)
root@dietpi:/tmp# sfdisk DietPi_OrangePi5-ARMv8-Bookworm.img -N1 <<< ',+'
root@dietpi:/tmp# truncate -s $(( (2095103+34) * 512 )) DietPi_OrangePi5-ARMv8-Bookworm.img
root@dietpi:/tmp# sgdisk -e DietPi_OrangePi5-ARMv8-Bookworm.img
...
Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.

So this is how to obtain the value:

root@dietpi:/tmp# sgdisk -p DietPi_OrangePi5-ARMv8-Bookworm.img 2>&1 | mawk -F[\ ,] '/^First usable sector/{print $5}'
2048

[MichaIng]

I updated dietpi-imager on the imager branch. @SelfhostedPro can you just rerun your workflow?

Glad to have finally found the underlying reason. Though sgdisk shows a pretty misleading error, suggesting to reduce the number of GPT entries, while the actual reason is the first LBA, which is not necessarily related to the number of entries, definitely not for partition tables generated with fdisk.

For reference: https://sourceforge.net/p/gptfdisk/discussion/939590/thread/da2435b5a8/

[SelfhostedPro]

Hmmm. Still failing:

https://github.com/SelfhostedPro/radxa-zero3w/actions/runs/8788644194/job/24116948518#step:11:188

Is this using the correct branch and whatnot?

https://github.com/SelfhostedPro/radxa-zero3w/blob/acd31e2c4b010296a3ccf5e3af4819a6eca6dd36/.github/workflows/armbian_custom.yml#L151-L160

[MichaIng]

Ah my fault, copy&paste error. Now it should work.

[MichaIng]

Seems it was successful now 🙂: https://github.com/SelfhostedPro/radxa-zero3w/actions/runs/8790829053/job/24123741616

[SelfhostedPro]

Yeah! It went through! I'll go ahead and test it out on my zero 3 w once this next run finishes (provided it uploads the artifacts correctly).

[MichaIng]

Okay, I merged it into dev branch, which you can now use in the workflow instead. Once DietPi v9.4 has been released (planned for Mai 10th), you can switch back to master.

[SelfhostedPro]

Hey, as a note. For at least the imager branch I'm using it doesn't create a separate boot partition with config files in it even with ADD_DOS_PART: 1 and CONFIGS_TO_BOOT: 1 set. Is there a good way to go about doing that?

I'll go ahead and change to dev in the meantime, thanks! Got to mess with it a bit today and it boots which is cool.

[MichaIng]

I am about to add native support for this device: #7042

Here a first image to test: https://dietpi.com/downloads/images/testing/DietPi_RadxaZERO3-ARMv8-Bookworm.img.xz Since is uses stable DietPi code instead of dev, it is detected as "Generic device" (e.g. in login banner), so this is just to see whether it generally boots and hardware features are available as intended.

So instead of converting an Armbian image, you could then also use our build script: https://github.com/MichaIng/DietPi/blob/newimages/.build/images/dietpi-build

Please use only ADD_DOS_PART. CONFIGS_TO_BOOT overrides the first and is only required for those new RPi images, where a FAT boot partition already exists, but is not mounted to /boot, but /boot/firmware.

Ah, and the script actually sets those to 0 and only enables them internally when passing the related CLI argument --add-dos-part resp. --configs-to-boot. At some point I wanted to move to explicit CLI args only, since env vars can overlap and be theoretically present without knowledge. However, I see the benefit of using env vars in GitHub workflows, easier to manage there than CLI args. So I can change the script to accept those env vars.

[SelfhostedPro]

Hmmm, no luck booting from the image you linked. No video out but light turns on (solid green light). I'll see if I can find info on debugging the boot process. Will try those flags, thanks!

[SelfhostedPro]

Also, when booting from the converted armbian image there was no video out either. I did see this issue so I'm trying trixie too: https://github.com/radxa-build/rock-3c/issues/5#issuecomment-1873584909

[SelfhostedPro]

I was able to boot and get video from my trixie image but it still sits at the armbian setup for some reason:

[SelfhostedPro]

The weird part too is that it made the second partition but doesn't have any diet-pi utilities and didn't pick up the config.

[disablewong]

I am about to add native support for this device: #7042

Here a first image to test: https://dietpi.com/downloads/images/testing/DietPi_RadxaZERO3-ARMv8-Bookworm.img.xz Since is uses stable DietPi code instead of dev, it is detected as "Generic device" (e.g. in login banner), so this is just to see whether it generally boots and hardware features are available as intended.

So instead of converting an Armbian image, you could then also use our build script: https://github.com/MichaIng/DietPi/blob/newimages/.build/images/dietpi-build

Please use only ADD_DOS_PART. CONFIGS_TO_BOOT overrides the first and is only required for those new RPi images, where a FAT boot partition already exists, but is not mounted to /boot, but /boot/firmware.

OK thanks so much for Michalng to including this SBC to dietpi! I left the board at home so I probably need to return home for testing this image. By the way, May I ask if the dietpi-imager script support multi-thread?

[MichaIng]

May I ask if the dietpi-imager script support multi-thread?

It is a shell script, so not sure what exactly you mean by that. It depends on the external command calls. I just recognised that xz uses a single thread only by default (other than 7zip, which used 1 thread per core), so I just changed it to use all CPU cores/threads.

For all other external command calls, I don't know, but it also does not matter since they are not time intense each anyway.

[SelfhostedPro]

Do I need to have the repo cloned in order for the script to run correctly? None of the configs are copied into /boot and it doesn't look like any of the diet-pi stuff is there (motd/scripts/etc).

This line doesn't error but I wonder if it actually ran: https://github.com/SelfhostedPro/radxa-zero3w/actions/runs/8844089683/job/24285368374#step:11:181

[MichaIng]

The partition was created, but the issue was that the boot partition as not mounted, which contains those files, so nothing was copied. What purpose does the trailing FAT partition have, if you have a boot FAT partition already, which natively contains those files? 😄

This config partition really only has any purpose, if the image does not have a boot FAT partition, so that you cannot edit the files from Windows or macOS hosts easily. But if it has one, all those files are there and you can edit them just fine, so another tailing FAT partition is needless.

[SelfhostedPro]

Oh, I thought that the --add-dos-part was needed for the fat partition with configs in it. You're saying that's for a second one? With armbian on this board, there's no way to mount /boot from the host (at least macos doesn't recognize it as readable).

[SelfhostedPro]

This is what I get when inspecting the final image:

dietpi@DietPi5:~$ sudo fdisk -l DietPi_radxa-zero3-server-trixie-vendor.img 
Disk DietPi_radxa-zero3-server-trixie-vendor.img: 2.51 GiB, 2699013632 bytes, 5271511 sectors
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: gpt
Disk identifier: DE7D7265-5320-5B42-869E-A64925B2B07A

Device                                         Start     End Sectors  Size Type
DietPi_radxa-zero3-server-trixie-vendor.img1   32768  557055  524288  256M Linux extended boot
DietPi_radxa-zero3-server-trixie-vendor.img2  557056 5267415 4710360  2.2G Linux filesystem
DietPi_radxa-zero3-server-trixie-vendor.img3 5267416 5269463    2048    1M Microsoft basic dat

[MichaIng]

Hmm, this should be a FAT partition: https://github.com/armbian/build/blob/main/config/boards/radxa-zero3.wip#L12C1-L12C18

fack also indicates it:

fsck.fat 4.2 (2021-01-31)

And from the Armbian log:

  [🐳|🌱] Creating partitions [ /boot: fat root: ext4 ]

So that partition should be mountable from macOS, and the 3rd (empty) one as well.

Our image btw has no boot FAT partition. Probably this particular bootloader requires it, which would be a good reason why it did not boot for you. @disablewong would be still great if you could test it, just in case. If it does not boot for you either, I'll add a boot FAT partition.

But another thing. You just pipe the Armbian image into the dietpi-imager, without running the dietpi-installer on it. The imager only shrinks and packs the image, but does not install DietPi on it. That is of course another good reason why none of the DietPi config files were copied.

See our build script: https://github.com/MichaIng/DietPi/blob/master/.build/images/dietpi-build It creates the partitions and filesystems, installs a basic Debian via debootstrap, boots it as container via systemd-container/systemd-nspawn and runs the dietpi-installer, then packs it with the dietpi-imager.

It is probably easier to use dietpi-build instead of converting the Armbian image. As you can see from the code, it is a little complex, and especially with Debian Trixie/testing, there are by times issues requiring changes due to the way the systemd container reacts, especially when using QEMU emulation for ARM and RISC-V images. DietPi was originally only moreless manually installed on existing images, hence the dietpi-installer. At some point, I wanted clean debootstraped images. But to keep the possibilities of dietpi-installer and avoid doubled code, we made dietpi-build a wrapper for it, instead of installing DietPi directly into a directory, without the hassle of booting it.

[SelfhostedPro]

Hmmm, if it is fat then it's corrupted or something but that's an issue on the armbian side of things. I'll try out build instead then. Should I use the dev branch for that one too?

[MichaIng]

If you want to test a Radxa ZERO 3 build, you need to use the newimages branch. Otherwise at best dev, as I did some updates/fixes.

Regarding the --no-dos-part flag there: It creates a trailing config partition automatically in all cases where it makes sense (no boot FAT partition). So this flag only needs to be passed if such partition is not wanted in any case. Also some other inputs are optional, or overwritten based on the hardware model. Usually one needs to pass the model index only, and distro version index when it shall not be Bookworm/stable: dietpi-build -m 90 -d 8 for Radxa ZERO 3 Trixie.

[SelfhostedPro]

So, image built with dietpi-build, light turns on and no video out. Any recommendations on debugging?

[MichaIng]

@SelfhostedPro Do you have a UART adapter to check serial console output?

I'll however generate an image with FAT partition now.

[MichaIng]

And the new image with dedicated boot FAT partition is ready: https://dietpi.com/downloads/images/testing/

[SelfhostedPro]

I can't find mine so I went ahead and ordered one.

[SelfhostedPro]

I think I remember their display driver had issues on bookworm, are you able to make one based on trixie?

[MichaIng]

The Debian version should generally not have any impact on kernel drivers, only on userspace libraries, e.g. impacting desktops and X/GUI applications. Also Trixie images are currently difficult to build, due to ongoing Debian 64-bit time_t transition, which causes a lot of APT dependency conflicts. When I run "apt full-upgrade" on my Trixie servers, a lot of essential packages would be purged due to this. So currently not possible, as this needs to be sorted first by Debian maintainers.

[MichaIng]

@SelfhostedPro does the Armbian Linux 6.1 image have HDMI output for you? @StephanStS had no output with it either. Since Radxa itself also does not provide a Linux 6.1 image, and Armbian just moreless copy&pasted the Linux 5.10 device tree, I guess that one would require some changes. Hence I am building an image with Linux 5.10 now: https://github.com/MichaIng/DietPi/actions/runs/8837991769

Available here once the build has finished: https://dietpi.com/downloads/images/testing/

[SelfhostedPro]

The Armbian Trixie Vendor image did have output.

Here is the error I was getting: https://pastebin.com/iH4gxQVq

[SelfhostedPro]

Here's the one with the new image: https://pastebin.com/NcMUWCA7

Think this is the key part:

** Booting bootflow 'mmc@fe2b0000.bootdev.part_1' with script
326 bytes read in 4 ms (79.1 KiB/s)
35041792 bytes read in 2908 ms (11.5 MiB/s)
6882309 bytes read in 575 ms (11.4 MiB/s)
Failed to load '/boot/dtb/rockchip/rk3566-radxa-zero-3w-aic8800ds2.dtb'
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Moving Image from 0x2080000 to 0x2200000, end=4410000
## Loading init Ramdisk from Legacy Image at 0a200000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    6882245 Bytes = 6.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
Boot failed (err=-14)

[MichaIng]

Failed to load '/boot/dtb/rockchip/rk3566-radxa-zero-3w-aic8800ds2.dtb'

That is a good reason. Why the hack is it trying to load such weird device tree 😄. If you have access to the ext4 partition, please try to add fdtfile=rockchip/rk3566-radxa-zero3.dtb to /boot/dietpiEnv.txt. Else, try to reflash the image and add that to dietpiEnv.txt on the setup FAT partition before booting. I'll also rebuild this image with this device tree hardcoded.

[StephanStS]

This version boots my Radxa ZERO 3E. First time boot takes a bit longer time, but finally it runs at first sight.