The Image for Radxa Rock 3A is corrupted and first Boot stop at few seconds

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | 9.8.0
  • Distro version | bookworm
  • Kernel version | uname --all
  • Architecture | arm64
  • SBC model | Radxa Rock 3A 2GB
  • Power supply used | (5V 2,4A custom)
  • SD card used | (SanDisk Ultra 64GB)

Additional Information (if applicable)

  • Software title | (Image: First Boot)
  • Was the software title installed freshly or updated/migrated?
  • Can this issue be replicated on a fresh installation of DietPi?
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

The following disk image is corrupted:
DietPi_ROCK3A-ARMv8-Bookworm.img.xz 2024-10-29 18:33 200M (DietPi 9.8.0)
First boot process aborts after a few seconds,
with the message Disk UUID=05XXXXX… is not found

Expected behaviour

First-Boot should be completed.

Actual behaviour

First boot process aborts after a few seconds.

Extra details

Luckily I still had an older image:
DietPi_ROCK3A-ARMv8-Bookworm.img.xz 204.7 MiB (214,605,268 bytes) (DietPi 9.7.1)
Downloaded on 2024-10-10
This older image only has one ext4 partition and works perfectly and an upgrade
to DietPi 9.8.0 is possible without any problems.

The new image DietPi_ROCK3A-ARMv8-Bookworm.img.xz 2024-10-29 18:33 200M (DietPi 9.8.0)
has one ext4 and one fat16 partition and does not work.
First boot process aborts after a few seconds, with the message Disk UUID=05XXXXX… is not found
Obviously the first boot install was changed here, which does not work on the Radxa Rock3A-2GB.

The best way to fix the problem for the Radxa Rock 3A is to upgrade the “old” image to 9.8.0.
After fixing the problem, the image in the download area would have to be replaced!

Note:
The Radxa Rock 3A 2GB has been “sold off” by the hundreds at various retailers in Germany in the last few weeks for €14.99. So many users could be affected

Images are created freshly by our build system. We don’t upgrade existing images.

@MichaIng can you have a look.

OK, I just wanted to report that the image
DietPi_ROCK3A-ARMv8-Bookworm.img.xz (200MB)
(Date 2024-10-29 18:33) is defective. A fresh installation is therefore impossible.

I noticed this when I wanted to freshly install my Radxa Rock 3A using the image. I still had the previous version on my HD with which I could freshly install and then upgrade.

do you have a serial adapter and can check the early boot process?

No, I don’t have a serial adapter.
I could record a short video clip of the boot process with the mobile phone.

No we would need to serial console output, as it might be different from what you see on screen

Are log files created on the SD card during the first boot that I could read?

I guess the system is not starting or mounting correctly. In this case no logs are written down. Using a serial console would allow to see boot messages during early boot process, even if the system is not starting.

244 / 5.000

Since I have no way of accessing the Rock3A serially, I took screenshots anyway (better than nothing) and extracted the text as ASCI text using Google Lens. Otherwise, I can’t get any further.
Here is the complete log file as text:

[ 4.751837] hub 6-0:1.0: USB hub found
[ 4.756504] hub 6-0:1.0: 1 port detected
[ 4.7380781 xhci-hcd xhci-hcd.10.auto: new USB bus registered, assigned bus number 8
[ 4.743656] xhci-hcd xhci-hcd.10.auto: Host supports USB 3.0 SuperSpeed
[ 4.749117] usb usb7: New USB device found, idVendor 1d6b, idProduct=0002, bcdDevice= 6.06
[ 4.754590] usb usb7: New USB device strings: Mfr 3, Product-2, SerialNumber=1
[ 4.760298] usb usb7: Product: EHCI Host Controller
[ 4.765445] usb usb7: Manufacturer: Linux 6.6.56-current-rockchip64 xhci-hcd
[ 4.770612] usb usb7: SerialNumber: xhci-hcd.10.auto
[ 4.776937] hub 7-0:1.0: USB hub found
[ 4.781850] hub 7-0:1.0: 1 port detected
[ 4.787626] usb usb8: We don't know the algorithms for LPM for this host, disabling LPM.
[ 4.793567] usb usb8: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.06
[ 4.798872] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4.803988] usb usb8: Product: XHCI Host Controller
[ 4.809569] usb usb8: Manufacturer: Linux 6.6.56-current-rockchip64 xhci-hcd
[ 4.814992] usb usb8: SerialNumber: xhci-hcd.10.auto
[ 4.821411] hub 8-0:1.0: USB hub found
[ 4.826795] hub 8-0:1.0: 1 port detected
[ 4.8329161 WCN: marlin_init entry!
[ 4.839143] of_cfs_init
[ 4.8440021 of_cfs_init: OK
[ 4.848825] clk: Disabling unused clocks
[ 4.858736] Freeing unused kernel memory: 4736K
[ 4.863792] Run /init as init process
Loading, please wait...
[ 4.914732] usb 1-1: new high-speed USB device number 2 using ehci-platform
Starting systemd-udeud version 252.30-1 deb12u2
[ 5.075416] usb 7-1: New USB device found, idVendor 1a40, idProduct=0101, bcdDevice= 1.11
[ 5.080648] usb 7-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 5.085675] usb 7-1: Product: USB 2.0 Hub
[ 5.0957081 hub 7-1:1.0: USB hub found
[ 5.101570] hub 7-1:1.0: 4 ports detected
[ 5.854323] rk_gmac-dumac fe010000.ethernet: IRQ eth_lpi not found
[ 5.875746] rk_gnac-dumac fe010000.ethernet: clock input or output? (input).
[ 5.8947341 rk_gmac-dumac fe010000.ethernet: Can not read property: tx_delay.
[ 5.9051871 rk_gmac-dumac fe010000.ethernet: set tx_delay to 0x30
[ 5.9101331] rk_gmac-dumac fe010000.ethernet: Can not read property: rx_delay.
[ 5.9152311] rk gmac-dumac fe010000.ethernet: set rx_delay to 0x10
[ 5.9205911] spi-nor sp14.0: mx25u12835f (16384 Kbytes)
[ 5.9262841] rk_gmac-dumac fe010000.ethernet: integrated PHY? (no),
[ 5.9311791] rk_gmac-dumac fe010000.ethernet: clock input from PHY
[ 5.9425541] rk gmac-dumac fe010000.ethernet: init for RGMII_ID
[ 5.947811]  rk gmac-dumac fe010000.ethernet: User ID: 0x30, Synopsys ID: 0x51
[ 5.9526151] rk_gmac-dumac fe010000.ethernet: DWMAC4/5
[ 5.9589951] rk gmac-dumac fe010000.ethernet: DMA HW capability register supported
[ 5.9642491] rk gmac-dumac fe010000.ethernet: RX Checksum Offload Engine supported
[ 5.969056]  rk gmac-dumac fe010000.ethernet: TX Checksum insertion supported
[ 5.9741471] rk gmac-dwmac fe010000.ethernet: Wake-Up On Lan supported
[ 5.9790291] rk gmac-dumac fe010000.ethernet: TSO supported
[ 5.9834261] rk_gmac-dumac fe010000.ethernet: Enable RX RX Mitigation via HW Watchdog Timer
[ 5.9881691] rk_gmac-dumac fe010000.ethernet: Enabled RFS Flow TC (entries=10)
[ 5.9928391] rk gmac-dumac fe010000.ethernet: TSO feature enabled
[ 5.9973041] rk gmac-dumac fe010000.ethernet: Using 32/32 bits DMA host/device width
Begin: Loading essential drivers... done. done.
Begin: Running/scripts/init-premount done.
Begin: Mounting root file system
Begin: Running/scripts/local-top ...done.
Begin: Running/scripts/local-premount...done.
Begin: Waiting for root file system
[7.322717] mmc_host mmc2: Bus speed (slot 0) = 375000 Hz (slot req 37500Hz, actual 37500Hz div = 0)
Begin: Running/scripts/local-block Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
[13.280863] mmc2: Failed to initialize a non-removable card
[17.542717] random: crng init done
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
Begin: Running/scripts/local-block..done.
[ 35.8072341] udd npu: disabling
Begin: Running/scripts/local-block done.
Begin: Running/scripts/local-block done.
done.
Gave up waiting for root file system device.  Common problems:
- Boot args (cat /proc/cmdline)
  - Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules: ls /dev)
ALERT! UUID=526da93e-a0a6-4bb7-b14e-48fb0a2e599b does not exist. Dropping to a shell!
(initramfs)

I think, that the Image is demaged.
Nobody, can install the Radxa Rock3A 2GB with this Image.

I had test this image, too:

https://dietpi.com/downloads/images/DietPi_ROCK3A-ARMv8-Trixie.img.xz

The same Errors like this image:
https://dietpi.com/downloads/images/DietPi_ROCK3A-ARMv8-Bookworm.img.xz

Later, I will gradually test the images from the download area on other hardware that is available to me (RPi1,RPi2,RP3B+,RPi4,RPi4,Native PC, and VMs)
I suspect and fear that the update of the images in the download area from 9.7.1 to 9.8.0 went wrong.
Upgrading from 9.7.1 to 9.8.0 of running systems seems
to be possible without any problems, but not a fresh install with the images from the download area.

again, we don’t update existing images. They are geratend from scratch, always.

These are completely different images and have no relation to the images from radxa-rock-3a. Also, the current images are almost a month old, and I would expect a lot more reports if they were all not working. But you are the only one reporting this. So it could be due to this particular SBC family respectively their dedicated image.

@Joulinar

Yes, the images are from 2024-10-29, when the update to DietPi 9.8.0 was
made. I downloaded the current (v.9.8.0) RPi5 images and flashed them onto my RPit5 B 8GB:
https://dietpi.com/downloads/images/testing/DietPi_RPi5-ARMv8-Bookworm.img.xz
https://dietpi.com/downloads/images/testing/DietPi_RPi5-ARMv8-Trixie.img.xz

My RPi5 doesn’t boot with either of them.

But if I flash an older xz image from my HD with Etcher, my RPI 5 boots.
So it doesn’t seem to be the SD card.

In addition to the images from the Radxa Roch3A, the images from the Raspberry Pi5 are also affected.

It’s best to test the images on the appropriate hardware.

I tested RPi 4 and 5. Both are working. Even Rpi5 is booting from NVMe directly

Btw why you are downloading images from testing and not from official download side?

I tested the images you linked without issue. Both are booting fine. Trixie updated around 120 packages during installation successfully.

I don’t know but might be your infrastructure seems to be special. Probably the download gets corrupted at your place? Otherwise I have no idea why very same image is working at my location.

The RPi 5 images also work fine here, and they are downloaded in high amounts daily, no chance they are generally damaged (also considering the fact that they match hash and signature we provide along with all images). Whatever it is, we’d need some more logs/serial console output or any such, to check what exactly is the problem in your particular case.

With the ROCK 3A image, it is different, WAY lower download amounts, and a recent kernel upgrade, broke something on the Orange Pi 3B, which uses the same SoC, though a different kernel build. However, I triggered new kernel and bootloader builds and a new image from it. Could you test that one, please: Index of /downloads/images/testing

Also, if you have a chance to check the UUID of the ext4 partition on another system, whether it actually is 526da93e-a0a6-4bb7-b14e-48fb0a2e599b, that would be great. I just checked the image, and there this UUID is correct.

1 Like

Hello MichaIng,
I downloaded the current RPi 5 and Rock3A images (date 2024-10-29, DietPi 9.8.0)
from the testing area on different systems (Fujitzu PC and Medion notebook,
both under MX-Linux 23.4) and flashed them with Etcher.
All of them were not bootable.

I had now helped myself by still having images of version 9.7.1 on my HD and
had then upgraded them.

By manipulating the .install_stage file and adding the fs_resize symlink, then
dd-dump and xz packing, I was able to build first-run install images with v9.8.0
again and use them if necessary, as long as the images in the download area do
not work (for me?). It is practically a reverse build, although the images are
a bit larger.

The UUID (526da93e-a0a6-4bb7-b14e-48fb0a2e599b) of the ext4 partition is
created when the data carrier is formatted and is always carried along
during imaging.

I will test the image for the Rock 3A later and then get back to you.

Yes, it seems to be dedicated to your network environment, ISP, firewall or other components that could be affecting the problem. No one else is currently reporting problems with our RPi5 image. We are also unable to reproduce the problem on RPI5. In our tests it started successfully.

I downloaded the image and tested it.

  1. Download and flash with mt etcher (on 64GB Sandisk ultra SD card)
    Result: Rock3A does not boot
  2. xz file tested with xz (ok) and unpacked as img.
  3. copied to SD card with dd.
    Result: Rock3A does not boot.
    I noticed that there is an additional FAT partition behind the ext4 here,
    in the working image of version 9.7.1 there is only one ext4 partition.

yes this has been introduced for ALL images to have a FAT partition to be able to preconfigure DietPi