rockpi image doesnt seem to boot

Hi everyone,

I’m having issues with the ‘DietPi_ROCKPi4-ARMv8-Buster’ image. Doesn’t seem to load at all. Can anyone confirm this image works on their RockPi 4?

I have tested a debian 9 image on the same RockPI and the board does work. The Debian 9 image has a partition structure as shown in the below link.
https://wiki.radxa.com/Rockpi4/partitions

The DietPi_ROCKPi4-ARMv8-Buster image only has one partition and it’s 16MiB off from the start of the media. Could the partition structure be a problem for the RockPi target?

Hi,

many thanks for your request. We have a couple of messages on the board about working RockPi 4 systems

https://dietpi.com/forum/t/dietpi-for-rockpi-4/3933/5

https://dietpi.com/forum/t/rockpi4b-issues/4300/1

If I’m correct trendy is using one??

I am using it without any issues since I installed the non-dev image. But I flashed it some time ago, not sure if the current image available is fine or broken.

Hi Joulinar and trendy. Thank you for developing Dietpi. it’s a great distro and have it on at least 2 other SBCs.

trendy, can you share your partition table on the working RockPi?

Here is the layout of the DietPi_ROCKPi4-ARMv8-Buster.img

$ sudo parted /dev/sdc print
Model: Generic STORAGE DEVICE (scsi)
Disk /dev/sdc: 31.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      16.8MB  531MB  515MB  primary  ext4

and here is the the official Rasbian 9 img layout (that works)

sudo parted /dev/sdc print
Model: Generic STORAGE DEVICE (scsi)
Disk /dev/sdc: 31.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name     Flags
 1      32.8kB  4129kB  4096kB               loader1  msftdata
 2      8389kB  12.6MB  4194kB               loader2  msftdata
 3      12.6MB  16.8MB  4194kB               trust    msftdata
 4      16.8MB  554MB   537MB   fat32        boot     boot, esp
 5      554MB   2000MB  1446MB  ext4         rootfs

I’m not exactly sure if the RockPi needs this structure but only working way i have seen yet is with the second way.

I can try shuffling the DietPi image around to look like the Rasbian 9, but figured I’d ask if someone can recognize an obvious problem.

I guess that’s fine. Raspbian 9 was based on Debian Stretch if I’m not mistaken. However the current DietPi image is based on Debian Buster.

I had a look to latest Armbian Buster (server) image. From structure (partition) point of view, this is looking same as DietPi image. If I’m not mistaken, DietPi is using Armbian as base image for RockPi SBC

DietPi


Armbian

Pls can you try downloading Armbian Server image. Just to check if it’s working. Rockpi 4 A / B / C – Armbian

If yes, you could transfer the Armbian system into DietPi by following this guide: PREP_SYSTEM_FOR_DIETPI.sh | Automate · Issue #1285 · MichaIng/DietPi · GitHub

I just bought a Rock Pi S 256mb (the 512mb version was not available…), burned your image on a card…no boot (HW rev. 1.3)…As the image was from Aug. 22, I guess it should work, no ? or is 256mb just not enough ?

Do you have serial console access? At least this would be needed to get an idea why it is not able to boot or where it stuck.

No…as it does not receive an IP-adress from the rooter…but only with your image.

When I use the official dbian image from here…no issues:

https://wiki.radxa.com/RockpiS/downloads

…but no dietpi…
there seem to be a new hardware revision: RockpiS/hardware/revisions - Radxa Wiki and they as well refer to hints on changed software requirement which are beyond my level of understnading…

when I try to use your script on the latest version of the debian published by the producer, I dont even come to the point of seein a menu:

rock@rockpis:~$ sudo bash -c "$(curl -sSfL 'https://raw.githubusercontent.com/MichaIng/DietPi/master/.build/images/dietpi-installer')"
[sudo] password for rock:
Get:1 http://apt.radxa.com/buster-stable buster InRelease [2363 B]
Get:2 http://httpredir.debian.org/debian buster InRelease [122 kB]
Get:3 http://httpredir.debian.org/debian buster-updates InRelease [56.6 kB]
Get:4 http://security.debian.org buster/updates InRelease [34.8 kB]
Get:5 http://httpredir.debian.org/debian buster-backports InRelease [51.4 kB]
Get:6 http://apt.radxa.com/buster-stable buster/main arm64 Packages [22.3 kB]
Get:7 http://httpredir.debian.org/debian buster/main arm64 Packages [7739 kB]
Get:8 http://security.debian.org buster/updates/main arm64 Packages [342 kB]
Get:9 http://httpredir.debian.org/debian buster/non-free arm64 Packages [53.9 kB]
Get:10 http://httpredir.debian.org/debian buster/contrib arm64 Packages [38.4 kB]
Get:11 http://httpredir.debian.org/debian buster-updates/main arm64 Packages [8780 B]
Get:12 http://httpredir.debian.org/debian buster-backports/contrib arm64 Packages [8532 B]
Get:13 http://httpredir.debian.org/debian buster-backports/main arm64 Packages [484 kB]
Get:14 http://httpredir.debian.org/debian buster-backports/non-free arm64 Packages [24.7 kB]
Fetched 8989 kB in 8s (1176 kB/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
FATAL -> Failed to fork.
[FAILED] Unable to install whiptail, please try to install it manually:
rock@rockpis:~$ sudo apt install whiptail
Reading package lists... Done
Building dependency tree
Reading state information... Done
FATAL -> Failed to fork.

OK, I understand that the failed to fork means low memory, so I tried to initiate you dietpi script on a Rock Pi E with 512mb…there I get menues etc…

BUT the same issue as with the BBG: The scripts identifies that I have buster installed, but later unter Diept-Pi-Prep it says:

"Currently installed: buster (ID:5) as a text, not selectable

but to be selected are only two other options:

6: Bullseye
7. Bookworm

As the code is:

# Distro selection
		DISTRO_LIST_ARRAY=(

			'6' ': Bullseye (current stable release, recommended)'
			'7' ': Bookworm (testing, if you want to live on bleeding edge)'
		)

LAter than there is again code for Buster…

So the question is: HAve you intentionally deleted the line

			'5 ': Buster

when you created the array of selectable distros ?

Can we have it back, please ? As this script is especially necessary for builds which you dont support…

It is expected, that only Bullseye and Bookworm are offered. We do not support fresh Buster images anymore. Choosing Bullseye, will do a distro upgrade.

The ROCK Pi S has an Ethernet cable attached or are you trying to use WiFi?

…Ethernet…and I would have loved your Rock Pi S image to work…but it did not.

And I guess it has to do with their changes desribed here:
https://wiki.radxa.com/RockpiS/hardware/revisions

" V1.3(2022)

Because of the supply chain challenge, Rockchip updated RK3308 version to RK3308BS. For ROCK Pi S V1.3 version manufactured in 2022 and later, we now use the new RK3308B-S version. The hardware difference of S version can be found here and software difference explanation can be found here.

The new ROCK Pi S images released in 2022 already supports both chip version, it’s backward compatible with all ROCK Pi S versions."

a serial console would be helpful to understood where the issue is.

We had a teammate who tested the image tonight and it was working. According to him, it was a V1.3 512 MB device

But with which chip see the changes above…

I can only say: the bigger latest debian.-image from their websites boots flawless and I can SSH etc.

Yours dont give me even a blue LED…dead. (ROCKPI S)

With the Rock PI E same…tried their image…boots, SSH etc…than run your 3328 script forcing me to upgrade to v11…tons of errors…complete dead end. The upgrade is messing everthing up:

Processing triggers for initramfs-tools (0.140) …
ln: failed to create hard link ‘/boot/initrd.img-4.4.194-17-rockchip-g07288d4ebac7.dpkg-bak’ => ‘/boot/initrd.img-4.4.194-17-rockchip-g07288d4ebac7’: Operation not permitted
update-initramfs: Generating /boot/initrd.img-4.4.194-17-rockchip-g07288d4ebac7
run-parts: /etc/initramfs/post-update.d//update-uenv exited with return code 1
dpkg: error processing package initramfs-tools (–configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

Hi @multiblitz, @Joulinar,
I have a Radxa ROCK Pi S (HW rev. 1.3 with 512 MB) and the ROCK Pi S image you get on the dietpi-download page works fine with my device. Just connect the LAN cable and the power and off it goes.

I flashed my SD card with Rufus 3.20.

Well, mine is 256MB…amd the 1.3 2022 version…which is different from the 1.3 before…so which hardware version is yours ?

Hi @multiblitz, the ROCK Pi S hardware homepage does not give any hints on different v1.3 models. Were did you read anything about different v1.3 versions?
How did you flash your SD card? Did you also test a different SD card?

I will try another sdcard as you suggest…

the info on the changes on the 1.3 going from a rk3308b to a rk3308b-s chip due to supply problem and the resulting necessary changes for the software: please read my posts above…the manufacturer has published them and changed their image to support all hardware revisions…see change log of their image

Aaah, I did not scroll so much upwards, my fault.
As far as I know, I generated the image about two months ago based on the downloadable Buster image from 2021-09-24 (update date 2021-11-23).
It was not so easy to switchover to Bullseye (like you also realized), I first had to update/upgrade the Debian Buster image fully, change it manually to Bullseye and then generate the DietPi image from this.

@StephanStS given the fact you already did the conversion once, could you try to create a new image using the new original RockPi S Buster image?

I followed your advise and burned the image to a high quality high endurance sd card with Balena…

This leads to a boot !

Unfortuately I got some error messages when initializing Apt-update/upgrade, seems to be a Armbian server availabilty issue, some indexed could not be generated etc. I will post the screen copies later…

So, I pressed re-try…and this time it went through…now i will try to install MPD…

The only thing which is very strange, would be cool if you can look this up in your system:

Under performance options there is nothing for governor nor frequency settings. No governor, no frequencies…that should not be the case…I would love userspace and min frequency as this sounded best in your C2 distro (which sounds great as a streamer for a High-end system)…

So, should I reburn and reinstall or is this intentionally ?

I guess @MichaIng might be best to answer this question