DietPi
DietPi copied to clipboard
MichaIng
Image | Radxa ZERO 3
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
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.
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.
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.
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
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
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.
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.
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).
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
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.
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.
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.
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?
Also, just wanting to link the pr in armbian that added support: https://github.com/armbian/build/pull/6420
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
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
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
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/
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
Seems it was successful now 🙂: https://github.com/SelfhostedPro/radxa-zero3w/actions/runs/8790829053/job/24123741616
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).
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.
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.
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.
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!
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
I was able to boot and get video from my trixie image but it still sits at the armbian setup for some reason:
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.