Yeah, that's why I asked. I was hoping that these patches had already been added to OpenWRT.
It looks like the resize can't be done while openwrt is booted?
root@meow:/# resize.f2fs /dev/mmcblk0p2
Error: In use by the system!
I did fdisk, deleted, created new partition and rebooted. Final step seems is where I am stuck.
I did try gparted on the ext4 image but I keep reading that squashfs is better to keep the life of the microsd? Anyhow any tips appreciated on resizing the SD on squashfs while booted.
1 Like
It needs to be unmounted. Probably easier to do it with a card reader on linux if you can. There's a section on that link which shows you how.
but
umount /dev/mmcblk0p2
then resize it.
Nice info on squashfs. Is it true? I'm thinking about resizing the partition so I can keep the collectd logs on reboot but I'm currently using ext4.
This is very good / easy to resize partition (instead of fdisk) but after resizing partition the filesystem needs to be expanded, no?
Followed @mercygroundabyss recommendation and unmmounted and tried but it still claims its mounted?
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 65536 147455 81920 40M 83 Linux
/dev/mmcblk0p2 196608 31116287 30919680 14.7G 83 Linux
root@meow:/# [ 31.702153] vbus_typec: disabling
^C
root@meow:/# umount /dev/mmcblk0p2
root@meow:/# resize.f2fs /dev/mmcblk0p2
Error: In use by the system!
root@meow:/# umount -f -l /dev/mmcblk0p2
umount: /dev/mmcblk0p2: not mounted.
root@meow:/# resize.f2fs /dev/mmcblk0p2
Error: In use by the system!
mtab
root@meow:/# cat /etc/mtab
proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
/dev/loop0 /overlay f2fs rw,lazytime,noatime,background_gc=on,discard,no_heap,us er_xattr,inline_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=ad aptive,active_logs=6,alloc_mode=reuse,fsync_mode=posix 0 0
overlayfs:/overlay / overlay rw,noatime,lowerdir=/,upperdir=/overlay/upper,workd ir=/overlay/work 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
cgroup /sys/fs/cgroup tmpfs rw,relatime,mode=755 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/cpu cgroup rw,relatime,cpu 0 0
cgroup /sys/fs/cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,relatime,blkio 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,relatime,net_cls 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/net_prio cgroup rw,relatime,net_prio 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,relatime,pids 0 0
cgroup /sys/fs/cgroup/rdma cgroup rw,relatime,rdma 0 0
debugfs /sys/kernel/debug debugfs rw,noatime 0 0
none /sys/fs/bpf bpf rw,nosuid,nodev,noexec,noatime,mode=700 0 0
overlayfs:/overlay /opt/docker overlay rw,noatime,lowerdir=/,upperdir=/overlay/u pper,workdir=/overlay/work 0 0
root@meow:/#
Tried also
root@meow:/# umount -f -l /
root@meow:/# df -h
Filesystem Size Used Available Use% Mounted on
df: /proc/mounts: No such file or directory
root@meow:/# fsck.f2fs -f /dev/mmcblk0p2
Info: Force to fix corruption
Error: Failed to get the device stat!
root@meow:/# resize.f2fs /dev/mmcblk0p2
Error: Failed to get the device stat!
I can't find the same thread but this one mentions it. squashfs cached in memory so its a bit more efficient and less writes to disk (because its memory cache primarily)
1 Like
do it on another system with a card reader. You cant do it while running FROM the sd card. kinda like trying to add a stretch section to a limo while you driving it 
2 Likes
So, I went on a quick research and I've found this: https://openwrt.org/docs/techref/filesystems
It turns out that squashfs has its own problems on NAND Flash too. JFFS2 looks better in terms of wear leveling and so on. I have to admit that by no means I'm a specialist on this matter. But I think the discussion is valid as this equipment uses mainly SD Card storage.
You can easily resize your root partition, use resize2fs and tune2fs on OpenWrt itself.
- Install the required tools
opkg update
opkg install parted tune2fs resize2fs
- Start the parted utility
# parted
(parted) print //note the root parition number
(parted) resizepart 2 11000 //this will set the 2nd partition(root) end to 11GB
(parted) print //verify new partition end and size
(parted) q //exit parted
- remount root as RO (if fails, reboot and remount as ro)
mount -o remount,ro /
- Remove reserved GDT blocks (workaround as online resizing of root partition fails)
tune2fs -O^resize_inode /dev/mmcblk0p2 #verify your root parition
fsck.ext4 /dev/mmcblk0p2 #answer y to all
- Reboot and
resize2fs /dev/mmcblk0p2
- Check new root partition size with:
df -h
7 Likes
There's no parted in RC4. Is there an alternative utility?
You can always install the ipk from snapshot.
1 Like
Using Armbian as the host OS will be fine in your case.
One thing to be aware of running an OpenWRT router as a container -- I did it for several years -- is that the host OS is responsible for the most of the tuning that can affect NIC performance and network throughput. In other words, OpenWRT's kernel and driver default settings have been continually optimized over the years to work well out of the box as a network appliance. As a container, OpenWRT has no control over these things. So expect to have to tune sysctl settings and other details in the host OS to get the same results out of it.
I am planning to buy the R4S. Can you please confirm that WAN is RTL8211E and LAN is PCIE RTL8211H (or is it RTL8111H?) as shown in this image https://www.friendlyarm.com/image/catalog/description/R4S_en_07.jpg and https://www.friendlyarm.com/image/catalog/description/R4S_en_05.jpg ?
So based on your post, RTL8211H is working fine with VLANs but RTL8211E has problems. Is that right?
Hi I can confirm the wan NIC doesn't see the VLAN tagged packets, unless you enable the promiscuous mode.
A possible workaround (I use at home) is to execute a script with a single command at boot time to enable promiscuous mode. But unsure if it has any impact on performance. A quick (unoptimized) benchmark reached >650Mb/s TCP with LAN to WAN routing + VLAN on WAN side + IPv4 encapsulated in IPv6).
Also, setting a custom MTU doesn't work too on WAN NIC.
1 Like
RTL8211E is a PHY transceiver chip connect to wan through usb bus. Lan is ethernet controller RTL8111H chip.
Yep, RTL8111H vlans work without issues, 8211E need enable promis mode.
1 Like
So as a last resort I tried writing the snapshot image to a different SD card. And boom, it worked perfectly. So annoying to discover it was a bad card that was keeping it from booting!
I'm sharing my build that I compiled today, after a lot of trial and error this has been stable for me and able to run ntopng in containerd. EXT4 with docker too.
To run ntopng as a virtualized container on my image follow the README.md in https://github.com/TheLinuxGuy/openwrt-ntopng
I haven't fix the github actions to auto-compile yet. I don't know when I will get to it.
Compiling raw openwrt using my .config was crashing when rebooting R4S; so ended up mixing some of anerlosky tweaks and patched immortalwrt code. This has made it stable and usable. It has NAT6 support built-in.
https://drive.google.com/file/d/18BM8WukT3MLf58VyxIPm1JhDKwp0IDs-/view?usp=sharing
I’m really split between this device or the raspberry pi 4b.
Has anyone confirmed if this can sqm with a 1 gig line?
Also can I build a solid master snapshot for this device yet?
I’d be using this for a pppoe connection 910 down and 110 up and shaping it through sqm before handing off to a switch.
Thanks all
1 Like
It's too near the theoretical limit of the interfaces but this little buddy is very powerful. There's some tests already done and posted here and they go a little bit further then 910Mbps without pppoe, I think. My guess is if both devices (R4S and RPi4b) have PCI-E backed interfaces (as R4S has), they may have similar performance.
If you need to get the maximum speed, maybe you'll have to look for a 2.5Gbps device...
Just trying to help thinking, maybe someone here has better insights.
2 Likes