Sysupgrade; Supported AND not supported device?

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

Glad you "solved" the issue. Be sure to mark @slh's post as the solution if it best helped or describes the solution.

Yes, somehow I missed that part about providing the .gz version and that did the trick.

Thank you everyone for the help!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.