I used that because I thought we needed a "full" installation, before the sysupgrade.
But now i know i can skip this first step. I just directly burned the latest 22.03 rc6 image below to microSD and it works fine. I was so confused but now its simple and working great
Even this description says 'to update a router that already runs OpenWrt' - but in my case it works fine with a blank microSD card
The name of the file/build could be whatever but the build you have linked is a normal ‘sysupgrade’ build, it’s only compiled by the GitHub user, as you can read from the changelog:
NanoPi R4S : r8168 driver for R4S (realtek) instead of kernel r8169 + r8169 firmwares package
The online builder has the same text for a router with internal flash storage, where you need the “factory” to switch to OpenWrt from OEM and the “upgrade”, and another x86/arm device that boot from an external card or it don’t runs any “router/modem firmware”.
It’s only a cosmetic issue, I’ve never read so carefully those texts, my fault
All good! Thanks for your patience. I'm certain there will another person with same confusion so this will help them I think
I am really liking R4S So quick and easy to setup.
Only thing I install is stubby for DNS over TLS.
I thought not having HDMI would be an issue (I'm used to doing initial setup with a keyboard and monitor) but now I can see its easy to do all via SSH.
I enabled SSH keys, disabled normal SSH login, disabled Luci because I won't need it again until I do next firmware update.
Such a great router. I hope it stays supported by OpenWrt for many years.
I made a donation to OpenWrt also.
I have a dual gigabit RPi Computer Module 4 also coming.
I will compare the ease of setup with R4S.
The easier one , I will give to my parents. I want them to have something that I can update easily remotely.
OpenWrt build appends some extra information as metadata at the end of the ".img.gz" image files. This metadata is used by the OpenWrt sysupgrade process to validate and verify the image before flashing.
This is why when expanding the R4S sysupgrade ".img.gz" images with 7-Zip we get the warning "There are some data after the end of the payload data" (this is the sysupgrade metadata).
Also, as others already explained, for regular routers the factory images are packaged in a special way (specific for each router manufacturer/model) so that they are accepted by the stock firmware in the first OpenWrt flash. For RaspberryPi and NanoPi there is no such thing as stock firmware since the initial flash is basically write the image to an empty SD card.
With that said, the RaspberryPi factory image is the same as the sysupgrade image except the fact that the factory image does not have the extra sysupgrade metadata. This was done just to prevent the warning messages when extracting the ".img.gz" image for the first SD writing. You can safely use the sysupgrade image also for the RaspberryPi the same way as for the NanoPi (just ignore the ".img.gz" unzip waring due to the sysupgrade metadata).
Short update. Over the weekend I tested a few builds:
22.03.0-rc6 ... works, did not find any issues
Latest master with kernel 5.15.60 (git as of yesterday morning) ... works, did not find any issues, now running it on my main router
I previously ran master with kernel 5.15.45 without any issues ... uptime about 1 month before I updated to 5.15.60
This is not meant to trigger yet another discussion which build one should use (release candidate vs. snapshot vs. custom build vs. FriendlyWrt), it merely states that those builds are working and I did not find any issues when it comes to my use cases.
I'll be honest, i don't think there was ever a discussion about which build is better to begin with...
What happened is that some people are still having reboot related issues with official openwrt, so others suggested that these people should try either friendlywrt or immortalwrt to see if the problem persists on those systems or not and if not, then clearly there is something wrong with official openwrt for the r4s and that maybe there is some code\patch from either friendlywrt or immortalwrt that should be ported to oficial openwrt.
But some decided that instead of doing a simple and fast test(which is to flash either friendlywrt or immmortalwrt and do some reboots), to just keep complaining like the problem will magically fix itself the more complaining one does
Also the kernel 5.15 PR for rockchip devices is still in limbo it seems
I compiled r20337 with the testing kernel 5.15.60 on my build environment.
Everything for 5.15.60 is already in git, the last missing piece is pr10123 which addresses issues with some kernel modules under kernel 5.15 (one might not need) … thus I‘d recommend adding this patch if you build yourself.