Thanks for the master snapshots tip! I wasn't aware of it!
And talking about master snapshots, the current available now on https://asu.aparcar.org/ is a master snapshot. I always make custom images there because I use a LTE dongle on the R4S to have internet access. I just copy and paste my recipe on 'customize' and I don't even need to restore a backup after the upgrade.
And on this last custom build I'm trying '-firewall4 firewall' to avoid bug/issues - I understood here it's a safe move, or it isn't recommended?
Moments ago on the mailing list: http://lists.openwrt.org/pipermail/openwrt-devel/2022-March/038170.html
Final "RTM" version might no come in april or may but RC will. Thats what i meant
Nice link, looking forward to Linux kernel 5.15 since it has the new ntfs driver (called NTFS3), similar to exFAT driver added in 5.10. I have one ntfs formatted external ssd drive on a Win11 box, this will be great to eventually have faster/stable ntfs support on OpenWrt.
I read this changelog of 21.02.2 and so i thought that they add new devices also to minor releases - so i just hoped that nanopi r4s could be on the list ...of ... probably ... 21.02.3 It is an awesome device for openwrt!
Device support
Support for the following devices was added:
Xiaomi AIoT Router AC2350
Linksys EA6300 & EA9200
Netgear RAXE500
TP-Link TL-WA1201 v2
Not sure if this kind of information is helpful for someone: 2022-03-04 snapshot with kernel 5.10.102 is running stable so far (uptime ~2 hours)
Does this snapshot in the link you provided work with the R4S 1gb version? I wish I would have gotten the 4gb but it was out of stock and the 1gb was a bit cheaper.
Any clue why sysfixtime doesn't seem to work (at least on snapshot)?
It works fine on RPi4, but on my 4GB R4S, the time at boot is always in the year 2013, and using https_dns_proxy means I'm in a catch-22 where I can't resolve a NTP provider to fix it.
I tested the maxtime() function in sysfixtime and confirmed that it is indeed using the newest timestamp in /etc, so it should self-correct to within a few minutes/hours/days of current even without the ability to do NTP, but it doesn't seem to be happening...ever.
I've worked around it for now by hardcoding an upstream NTP server and using ntpdate in rc.local to force it to skew, but I can't understand at all why sysfixtime isn't doing the right thing at boot.
Anyone else looked into this?
EDIT: OK, I figured out why...sort of. On RPi4, /dev/rtc0 doesn't exist, so the start function fails and falls through to setting the clock via /etc. On R4S, /dev/rtc0 does exist...but probably shouldn't, having no CMOS battery. Not sure what to recommend here. I'm now working around it by doing the same thing sysfixtime does in rc.local, but it's still hacky.
FYI... the info below might be helpful for those wanting to use the extra space on their microSD card. I don't think this is documented in the wiki:
I was curious about using the extra space on my microSD card for Docker stuff rather than having to use an external USB drive. I am using a 128GB microSD with my squashfs build that has a 512MB root partition. The wiki talks about expanding the squashfs partition which is not a simple task. Also if you do that, you will not be able to flash a new sysupgrade image because the partition layout will not match. So I wondered if I could simply create an additional partition at the end of the microSD card after all the OpenWrt partitions. I wasn't sure if a sysupgrade would still work after doing that, or if a sysupgrade would delete my extra partition. So I did a test run on a NanoPi R2C. I flashed a squashfs image with dd, and then used gparted to fill the rest of the unallocated space with an ext4 partition. I then created some dummy files on the ext4 partition and booted up the R2C. Then I flashed a new squashfs sysupgrade image from luci. It did not complain about anything and flashed the new image successfully. After rebooting to the new image, I checked on my extra partition and it was still there with the dummy files on it.
So it turns out you can get the benefits of a squashfs image and still use the rest of the space on the card without having to resize the squashfs partition. As long as you flash a sysupgrade image that has the same root size, it seems the sysupgrade does not delete or touch any other partitions beyond OpenWRT. Knowning that, I was able to remove my external USB drive that I was using for Docker and put those files onto an ext4 partition on the microSD card.
TLDR: the wiki suggests resizing the OpenWrt partitions to make full use of your SD card. However if you need the space for Docker, media files, etc, I believe it's better to create your own partitions using the unallocated space after OpenWrt. You get to use the rest of the SD card as persistent storage across sysupgrades without having to modify the OpenWrt image.
might have to be careful how you use the card however. Programs like balana Etcher etc usually tend to wipe the card and then dump the image to it.
However "inplace" upgrades as you said would leave your additional partition alone. Certainly worth a thought and maybe even adding to the wiki.
Correct... if you pull the card out of the R4S and flash a new img file from a PC, you will lose the extra partition. But as long as you keep doing in place upgrades and the new images have the same partition size / layout, any extra partitions should be left alone.
Just wanted to say thanks to everyone on this thread for all the useful information, including the example posted above!
I'm new to OpenWrt (and networking and CLI usage!), got my R4S set up on the above snapshot with adblock and sqm packages, replaced my ISP router a few hours ago and seems to be running smoothly so far!
Thank you again everyone for all the great input, very much appreciated!
I just tried a snapshot and it wouldn't boot. I have ImmortalWRT fork running on it no problem but I would rather use a base image and build on it myself.
Can you link me to where you found that snapshot? Do you have the 4gb or 1gb? I have the 1gb and can't seem to get any build to work other than the fork mentioned above.
Is this still a problem? I have the 1GB version and I can't get any snapshot to work. The only image that works correctly is one I found from immortalwrt. I've tried unplugging it and plugging back in with still no success. All I get is the red LED and status lights on the WAN port only.
Official snapshots from openwrt are for the 4Gb model only :
As you can see in the firmware selector.
If you want a clean build for the 1GB model, you can either use this = https://github.com/anaelorlinski/OpenWrt-NanoPi-R2S-R4S-Builds or you can build friendlywrt yourself, so you can remove all those drivers and packages that it comes with it by default.
Thanks for the response!
As soon as I finished my last comment I tried anaelorlinski's build and it worked perfectly. I was afraid that was the case but in the main description it said both were available so I was hoping lol.
Do you think this will be something they add in the future to the main branch? I should have gotten the 4gb version.
That comment line is only letting ppl know that there are 2 versions of the R4S, one with 1GB and one with 4GB, hence the "versions are available" instead of "versions that are supported".
Someone needs to make a PR and add support to it just like ppl did with the 4GB model. If no one does it, openwrt devs wont do it by themselves.
welp, looks like I will be using snapshots for a while lol. I just picked up a WRT3200ACM for $30 locally that is practically brand new so I will start messing around with that then.
i vaguely recall that there was a proposed patch but it was rejected as the devs stated it should be pushed upstream into uboot where it rightly belongs.