Sysupgrade; Supported AND not supported device?

I'm using the image builder from here;
https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/

Everything seems to go fine, I see no errors what so ever and the end result is an image file that is gzip.

The thing is, when I uncompress it, I get a garbage error;

# gunzip openwrt-rockchip-armv8-friendlyarm_nanopi-r5c-squashfs-sysupgrade.img.gz

gzip: openwrt-rockchip-armv8-friendlyarm_nanopi-r5c-squashfs-sysupgrade.img.gz: decompression OK, trailing garbage ignored

I've checked the file using md5sum while compressed and uncompressed and get no errors.

I scp it to /tmp on the device and try to upgrade the device but first test it;

# sysupgrade -T nanopi-r5c-2024-02-03.bin.gz
Sun Feb  4 06:27:50 CST 2024 upgrade: Device friendlyelec,nanopi-r5c not supported by this image
Sun Feb  4 06:27:50 CST 2024 upgrade: Supported devices: friendlyarm,nanopi-r5c
Sun Feb  4 06:27:50 CST 2024 upgrade: Reading partition table from bootdisk...
Sun Feb  4 06:27:50 CST 2024 upgrade: Reading partition table from image...
Partition layout has changed. Full image will be written.
Image check failed.

Using 'make info' I see this is supported;

friendlyarm_nanopi-r5c:
    FriendlyARM NanoPi R5C
    Packages: kmod-r8169 kmod-rtw88-8822ce rtl8822ce-firmware wpad-basic-mbedtls iwinfo
    hasImageMetadata: 1
    SupportedDevices: friendlyarm,nanopi-r5c

Oddly, I'm using the correct profile, "friendlyarm_nanopi-r5c" so really not sure what is happening since the response is that the "friendlyelec,nanopi-r5c" is not supported but I'm not using that profile.

Does anyone know what's going on?

Scrub the card with whatever disk partition software you prefer.

Eject the card; mount it again and ensure there is no partition at all left on the card..
Not even a 16Kb partition. Do not format it.

Then try to flash the firmware. If you get anything like "partition size has changed" the card was not totally scrubbed.

Disclaimer: I have no experience with this particular device (or rockchip ones in general), but...

This is not an issue, but expected - the trailing garbage is what sysupgrade later complains about to be missing.

  • whenever you use sysupgrade, give it the compressed file as-is
  • whenever you use cat/ ddor similar tools to write the image yourself, unpack it first (ignore the hint about trailing garbage, that is the image metadata, it's o.k. and gets discarded)
5 Likes

I did also try the .gz but the same thing happens;

# sysupgrade -T nanopi-r5c-2024-02-03.bin.gz
Sun Feb  4 23:28:14 CST 2024 upgrade: Device friendlyelec,nanopi-r5c not supported by this image
Sun Feb  4 23:28:14 CST 2024 upgrade: Supported devices: friendlyarm,nanopi-r5c
Sun Feb  4 23:28:14 CST 2024 upgrade: Reading partition table from bootdisk...
Sun Feb  4 23:28:14 CST 2024 upgrade: Reading partition table from image...
Partition layout has changed. Full image will be written.

It's not using the card, the OS is running on eMMC.
I'm just trying to upgrade it with my own ImageBuilder build.

Does it mean my only options are to use the SDK or to wait until these devices are officially supported by OpenWrt?

Does it upgrade with an image from downloads.openwrt.org?

Hi,

Do you mean from this download?

https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-friendlyarm_nanopi-r5c-squashfs-sysupgrade.img.gz

Yes, I've upgraded it to the above a few times while trying to figure this out.

One other option I might have would be to run this version, then add all of the packages, configs, etc that I need then make an image of the running os IF that's possible?

I guess I could boot from SD card to make an image of the eMMC card. That could work. ImageBuilder would be SO much less complicated :).

I will not have any GUI stuff installed on this device.

So to be clear, the official image works. OK, thanks for clarifying.

Yes, thats an option. I surmise your self-built images are too large.

My builds;
-rw-r--r-- 1 root root 14M Feb 3 15:38 nanopi-r5c-2024-02-03.bin.gz

Uncompressed;
-rw-r--r-- 1 root root 168M Feb 3 15:38 ID58-nanopi-r5c-2024-02-03.bin

Builds for other devices are about 8M only.

However, when you say too large, what does that mean specifically? I mean, I have room in /tmp on the device to upload the image to but sysupgrade doesn't like the image so I cannot upgrade.

Also, sysupgrade at least isn't complaining about the size.

I could try mtd I guess.

I tried mtd and got a message I've never seen before.

# mtd -r write nanopi-r5c-2024-02-03.bin linux
Could not open mtd device: firmware
Can't open device for writing!

9215.9 KB

I mean your images are ~ 5 MB larger

/tmp is RAM (i.e. memory, not flash/disk/eMMC space). If you're counting this as available space for flashing, without detailed explanation, it suffices to say after noting it's RAM - that notion is incorrect.

Yes, I've always put an image I was going to use to upgrade in the /tmp which gets removed on bootup.

/tmp is RAM (i.e. memory, not flash/disk/eMMC space). If you're counting
this as available space for flashing, without detailed explanation, it suffices
to say after noting it's RAM - that notion is incorrect.

I don't count /tmp as available space. Not sure I'm following your last statement, sorry.

Yea, it seems you may not be. No worries.

In any case, the official images apparently work. So I suggest trying to reduce the image size (as already discussed); or just use the official image and install your desired packages.

I hope this helps.

1 Like

It might be the only option I have until ImageBuilder comes for this model.
I've got the official version running on it but removing all the packages I don't need while adding the ones I do need takes me into a deep rabbit hole.

I've tried a few times this morning but always end up with dependency issues, some really hard to solve.

BTW, the official download is 168M so my build should work as it's 168M also.
It's 9M in the repo but once decompressed, it's 168M

Because that is the file size of the *.img.gz file.

I'm not quite sure what number you're referring to. Nonetheless, without detailed explanation - it's impossible you added packages yet the file size remains the same. I now surmise there's some limitations the developers account for and your images are indeed oversized.

Yea, it's not possible you add packages yet they're the same.

I tried leaving it compressed and get the same errors with mtd.

I also tried sysupgrade on the compressed file'

# sysupgrade -n openwrt-rockchip-armv8-friendlyarm_nanopi-r5c-squashfs-sysupgrade.img.gz
Mon Feb  5 19:19:28 UTC 2024 upgrade: Reading partition table from bootdisk...
Mon Feb  5 19:19:28 UTC 2024 upgrade: Reading partition table from image...
Mon Feb  5 19:19:29 UTC 2024 upgrade: Commencing upgrade. Closing all shell sessions.
Command failed: Connection failed

Now it's in some kind of limbo again.

To be clear, stop trying to flash your [possibly corrupted and] oversized images.

I suggest:

You were already told to do this, so I don't understand this statement. Were you still uncompressing the image after being instructed not to do so?

It's solved.
You have to flash using the compressed version.
In this case, I copied my build over to /tmp on the device.
The mtd command would not work but sysupgrade did, even if it complained at the end.

The error message makes sense now, it's my shell that complained that connection was lost since the upgrade started.

Now my build is running on the device and I can use ImageBuilder.

1 Like