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.
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.
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)
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.
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.
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.
/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.
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.
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.
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
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.