Rpi4 < $(community_build)

[root@RPi-OpenWRT /]# sysupgrade -b /tmp/test.tar.gz
mount: /etc/backup: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error.
Cannot mount '/etc/backup' as tmpfs to avoid touching disk while saving the list of installed packages.
Wed Sep 29 01:30:46 CDT 2021 upgrade: AUTORESTORE [no]
Wed Sep 29 01:30:46 CDT 2021 upgrade: Saving config files...


 Failed to create the configuration backup.
[root@RPi-OpenWRT /]#

                       ls -lah /tmp/test.tar.gz
ls: /tmp/test.tar.gz: No such file or directory
[root@RPi-OpenWRT /]# mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
/dev/mmcblk0p2 on /opt/docker type ext4 (rw,noatime)
overlay on /opt/docker/overlay2/bc9dbd3fea71b29197f866b29293554129e445de93102735f37fa2f52bea92de/merged type overlay (rw,relatime,lowerdir=/opt/docker/overlay2/l/TSSTJVX7E3ZC7J7PEPGHNWIEAT:/opt/docker/overlay2/l/QPJBTCZH5BYJ5QNKJS27YTUMKI:/opt/docker/overlay2/l/MCI5O74YN44USSMYRDKGA2KLLD:/opt/docker/overlay2/l/M2ISQF734YWDYVY6GWNJLGIJFO:/opt/docker/overlay2/l/WIFP2NCUHSRQ6UAZ4H53VBOGTM:/opt/docker/overlay2/l/X2GOAMHZ4NTWQEFMOADRB6H4FB:/opt/docker/overlay2/l/LQEPIZKTV6UNTSR3PHP7VEEHVD:/opt/docker/overlay2/l/KWDMEGDJWWTVYURW3GX6S6TJAP:/opt/docker/overlay2/l/K6LFHEC57LR54EQLGWRINTQOJG:/opt/docker/overlay2/l/EAMXOZIEL5WJCEITNHMCRHTUSS,upperdir=/opt/docker/overlay2/bc9dbd3fea71b29197f866b29293554129e445de93102735f37fa2f52bea92de/diff,workdir=/opt/docker/overlay2/bc9dbd3fea71b29197f866b29293554129e445de93102735f37fa2f52bea92de/work)
overlay on /opt/docker/overlay2/90250b6b944339b66b55c26fcc2c81017877d2b260dd92c05b484ee0aec8dfb6/merged type overlay (rw,relatime,lowerdir=/opt/docker/overlay2/l/CRNLJ3DJ3CGDESP7F3J6RCNJXJ:/opt/docker/overlay2/l/YGDH2OKD245IBKKNLQ3GL2SJ22:/opt/docker/overlay2/l/MZ7B5DIVWNEX7QYT3XVJHNKR6T,upperdir=/opt/docker/overlay2/90250b6b944339b66b55c26fcc2c81017877d2b260dd92c05b484ee0aec8dfb6/diff,workdir=/opt/docker/overlay2/90250b6b944339b66b55c26fcc2c81017877d2b260dd92c05b484ee0aec8dfb6/work)
overlay on /opt/docker/overlay2/b8cecfc5ae47dd96a726432b2768a1ddc757bcc10d11323eea4d84dce109c742/merged type overlay (rw,relatime,lowerdir=/opt/docker/overlay2/l/WCHDB5WGISYVTT5JJMGZDWP2QF:/opt/docker/overlay2/l/RW4QEBVZ4IWTDVENFOC4J4HSJS:/opt/docker/overlay2/l/UT2YYWJVZDEQ53WC7UVRCEI2EL:/opt/docker/overlay2/l/UAUI5MDFSVOBR7T5LLZLRVP6TA:/opt/docker/overlay2/l/QLU3X56SQ7A4R5QYDX52N4OKY2:/opt/docker/overlay2/l/5KEK2JRR7HWI5QQVNRPOPHNLAT:/opt/docker/overlay2/l/Q7ZUR3SLQT2I6O6G5VQ5HKLQXZ:/opt/docker/overlay2/l/UXZQV6U2J2FI77RLSJRH5BODTY:/opt/docker/overlay2/l/L4GST2EZSOM4FQ7V3XCBWWXOWE,upperdir=/opt/docker/overlay2/b8cecfc5ae47dd96a726432b2768a1ddc757bcc10d11323eea4d84dce109c742/diff,workdir=/opt/docker/overlay2/b8cecfc5ae47dd96a726432b2768a1ddc757bcc10d11323eea4d84dce109c742/work)
overlay on /opt/docker/overlay2/cf23169914c71d632b598d1e83fbfb29c2786b9f27c2b8f90657044599d068cb/merged type overlay (rw,relatime,lowerdir=/opt/docker/overlay2/l/SDJVDU6ZW63ABXENDOUSTPMA4E:/opt/docker/overlay2/l/R67GORDFP2KH6ZYRQ4LQ2TUEKJ:/opt/docker/overlay2/l/3QKKEBR27MVJ2OGJHQ66NBUQ2L:/opt/docker/overlay2/l/VG6JVJY6HX25KNT7OSK4XWZTXD:/opt/docker/overlay2/l/3CODRHJL5HNVWMBWNPOJNXIC5J,upperdir=/opt/docker/overlay2/cf23169914c71d632b598d1e83fbfb29c2786b9f27c2b8f90657044599d068cb/diff,workdir=/opt/docker/overlay2/cf23169914c71d632b598d1e83fbfb29c2786b9f27c2b8f90657044599d068cb/work)
overlay on /opt/docker/overlay2/074283efecff7cc8393bde94cfcb3f806e1980c04d0ee4ac456a1e5dffa8db97/merged type overlay (rw,relatime,lowerdir=/opt/docker/overlay2/l/6AFQY5SGXRP2FHEP5KBWEC326H:/opt/docker/overlay2/l/C7VOX34DUEYKYY6ZKHA7I3OEBI:/opt/docker/overlay2/l/HIHJJ53O7QB2O3OL5M3QUUDTI4:/opt/docker/overlay2/l/BMMCTNIZTEVNTE5NJKUAUZKMUM:/opt/docker/overlay2/l/T6QUECKBP2IPI4IFWXUKPYDCR6:/opt/docker/overlay2/l/NXEL6EJKFAOV4ZT6CBA53EHUYS:/opt/docker/overlay2/l/PY2ECUSSBEJWH5GHNTSYBK7FJE:/opt/docker/overlay2/l/ZARUOBV3YMMZZLQSEMSBGNV2ZL:/opt/docker/overlay2/l/HVRDH4CTNGZUCG7O6TVSF3TBNQ:/opt/docker/overlay2/l/W7WSAZGEKFLIJOQPH4PZ7NPXGS,upperdir=/opt/docker/overlay2/074283efecff7cc8393bde94cfcb3f806e1980c04d0ee4ac456a1e5dffa8db97/diff,workdir=/opt/docker/overlay2/074283efecff7cc8393bde94cfcb3f806e1980c04d0ee4ac456a1e5dffa8db97/work)
overlay on /opt/docker/overlay2/16bc8951579f2808014d5f8e7588bc4da475a7cdbdb53a612620dcb403c53f15/merged type overlay (rw,relatime,lowerdir=/opt/docker/overlay2/l/LZXPIP4JGLA4JWBGJ6TQEKWRDD:/opt/docker/overlay2/l/I6ZXWCG5TXFS54T63SIW4ERDJT:/opt/docker/overlay2/l/3CC63GBEN6ILJC6HQFESBIAKLY:/opt/docker/overlay2/l/7IY3YAYKIGEBZOHVA2LKPMZIL4:/opt/docker/overlay2/l/3CODRHJL5HNVWMBWNPOJNXIC5J,upperdir=/opt/docker/overlay2/16bc8951579f2808014d5f8e7588bc4da475a7cdbdb53a612620dcb403c53f15/diff,workdir=/opt/docker/overlay2/16bc8951579f2808014d5f8e7588bc4da475a7cdbdb53a612620dcb403c53f15/work)
overlay on /opt/docker/overlay2/b1c8d831feafc49e420a49f987c03af7ba7d197fb4cdf68b0d6bfa976b917723/merged type overlay (rw,relatime,lowerdir=/opt/docker/overlay2/l/QSASWWYTDDN47KRKS2E2SERVY2:/opt/docker/overlay2/l/OQXTW2M4JZYTZNCV37TGQFLFP4:/opt/docker/overlay2/l/BMN6QK7HZ4R76OHZLLWBEM2B4N:/opt/docker/overlay2/l/H2XCWTOGNVJ3L4J7GMQ4EACZ2H:/opt/docker/overlay2/l/FCHN76ZFU2TQPK6WHCWRUDPMFX:/opt/docker/overlay2/l/VRBTSZOKWNPEI5M5SHVTHOGPV7:/opt/docker/overlay2/l/R4MPNCU3FKCJST2UANLQGW2BM5:/opt/docker/overlay2/l/W3H4WAWWZBSXBPPC3X3UT63Z7U:/opt/docker/overlay2/l/JEF6XMYIVLXV5BDOFYOYQS5TSV:/opt/docker/overlay2/l/S5TA64X475NTRM3FLDOX37T3JP:/opt/docker/overlay2/l/DGFFNJGH44TSI76AIMEF6TCLRA:/opt/docker/overlay2/l/NBWFIIHLF6ZJFUL7E6CHCQI7K6:/opt/docker/overlay2/l/42ILX2JYB3UY5HKKVXZQIOLAT6:/opt/docker/overlay2/l/WMA7FF5CVZKJUJ4PI7AWPU2VWG:/opt/docker/overlay2/l/R6KKV722PHDU3VHICZB7WM7V52:/opt/docker/overlay2/l/JW4KM5OAT6AR3XXD35WXYYWCHF:/opt/docker/overlay2/l/GQFGGV5K4NWKLKI7OUHBREO4KV:/opt/docker/overlay2/l/MZGJNJROFCWB2CZFNDGGMT3S5U:/opt/docker/overlay2/l/FBXODFXTJPXHZX2LMGB2HGPGZI:/opt/docker/overlay2/l/KXQ4Z4FM42OH3MYIYHLRX5MGJL:/opt/docker/overlay2/l/PXL42EVXOYO4COF6OKG7UBZFLB:/opt/docker/overlay2/l/B5LSXKFV7MNKDJ4QMWWEBZ3QSG:/opt/docker/overlay2/l/DP6LQYZ4DVEVED3OPHUYZ364RQ:/opt/docker/overlay2/l/Y6XVQL2YASXVMQTFNOSAEDO7XF,upperdir=/opt/docker/overlay2/b1c8d831feafc49e420a49f987c03af7ba7d197fb4cdf68b0d6bfa976b917723/diff,workdir=/opt/docker/overlay2/b1c8d831feafc49e420a49f987c03af7ba7d197fb4cdf68b0d6bfa976b917723/work)
overlay on /opt/docker/overlay2/9db851bc231a5296f045b050da579755f2935b4b82bdd89732475c5098143c37/merged type overlay (rw,relatime,lowerdir=/opt/docker/overlay2/l/AYJTF7P33VSXGONG7H4D4BEUIG:/opt/docker/overlay2/l/AM5QYJGAHZW544LO2JQ4XEMBPO:/opt/docker/overlay2/l/JXIFRSA4545WJZGDVN4SSD6MKX:/opt/docker/overlay2/l/JXAKOAYT4BVAYWFLBSC7JFRBNN:/opt/docker/overlay2/l/UURTVOXJXGXZTQU7LOY37IVCIB:/opt/docker/overlay2/l/KL3P4M55BXHHM3WXXWXU4BCXEJ:/opt/docker/overlay2/l/B5CGFL6LJYTLK4JG6LFUHUMYKF:/opt/docker/overlay2/l/7ZRUDX6MBV25NRJCCZWRQ5PZGW:/opt/docker/overlay2/l/PJEDIR6DPU7URRQYYUZLGGAYJQ:/opt/docker/overlay2/l/HZJR2KLGOKELVYASN2F35ANBGB:/opt/docker/overlay2/l/GJ4URXC5GTZFPMCMWTJ7BHRMGQ:/opt/docker/overlay2/l/6ERU6ZT7QB2ZQJRGGRZFU22BEQ:/opt/docker/overlay2/l/7DI76ZRT2J76AA3D2ZAWU3BEVN:/opt/docker/overlay2/l/VORLTSQG3CAEXHCZ5QGEFZKQ5M:/opt/docker/overlay2/l/PYUFPNF6DUXE7XSCC67I2ZEFK2:/opt/docker/overlay2/l/WW3RLMGBNDPAFFULDTMUPSV3KZ:/opt/docker/overlay2/l/DCSHA7ABYTYU3VLXH3DIS67FDH:/opt/docker/overlay2/l/FS3JSTD62JMT3GQPIPDFNWQM32:/opt/docker/overlay2/l/NNV36ERWODOXQ3INPL56PG7Y6H:/opt/docker/overlay2/l/KAFUSJXFZZXAWGDH57OPIUMRVJ:/opt/docker/overlay2/l/M6VHY2ASGHLB7CCXJ77IAYUUIS:/opt/docker/overlay2/l/KSV7NPD643WDZM7ICP7L5W6WWB:/opt/docker/overlay2/l/F3R4QV5LT4ZSYI3CLTWUQ6RMG4:/opt/docker/overlay2/l/CBLOQBYDHZOB55ARXD6YZI7JWS:/opt/docker/overlay2/l/D4QSUEQ5GYVWLIE6YGBHRKY64J:/opt/docker/overlay2/l/RRW2RNBOWPVUHHWYDG3RK7RDUQ:/opt/docker/overlay2/l/XL4FDM4DGF3Y2XQMESHVTNCH73,upperdir=/opt/docker/overlay2/9db851bc231a5296f045b050da579755f2935b4b82bdd89732475c5098143c37/diff,workdir=/opt/docker/overlay2/9db851bc231a5296f045b050da579755f2935b4b82bdd89732475c5098143c37/work)
nsfs on /tmp/run/docker/netns/default type nsfs (rw)
nsfs on /tmp/run/docker/netns/78c547a916c9 type nsfs (rw)
nsfs on /tmp/run/docker/netns/dbc9ecdd7e7e type nsfs (rw)
nsfs on /tmp/run/docker/netns/07bb3dcb0fbf type nsfs (rw)
nsfs on /tmp/run/docker/netns/483a8a3e62dc type nsfs (rw)
overlay on /etc/backup type overlay (rw,relatime,lowerdir=/etc/backup,upperdir=/tmp/sysupgrade.mkldDn/upper,workdir=/tmp/sysupgrade.mkldDn/work)
overlay on /etc/backup type overlay (rw,relatime,lowerdir=/etc/backup,upperdir=/tmp/sysupgrade.bHhjJe/upper,workdir=/tmp/sysupgrade.bHhjJe/work)
[root@RPi-OpenWRT /]# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                58.2G     10.6G     47.7G  18% /
tmpfs                     1.9G    166.4M      1.7G   9% /tmp
/dev/mmcblk0p1          383.8M     71.6M    312.2M  19% /boot
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/root                58.2G     10.6G     47.7G  18% /opt/docker
overlay                  58.2G     10.6G     47.7G  18% /opt/docker/overlay2/bc9dbd3fea71b29197f866b29293554129e445de93102735f37fa2f52bea92de/merged
overlay                  58.2G     10.6G     47.7G  18% /opt/docker/overlay2/90250b6b944339b66b55c26fcc2c81017877d2b260dd92c05b484ee0aec8dfb6/merged
overlay                  58.2G     10.6G     47.7G  18% /opt/docker/overlay2/b8cecfc5ae47dd96a726432b2768a1ddc757bcc10d11323eea4d84dce109c742/merged
overlay                  58.2G     10.6G     47.7G  18% /opt/docker/overlay2/cf23169914c71d632b598d1e83fbfb29c2786b9f27c2b8f90657044599d068cb/merged
overlay                  58.2G     10.6G     47.7G  18% /opt/docker/overlay2/074283efecff7cc8393bde94cfcb3f806e1980c04d0ee4ac456a1e5dffa8db97/merged
overlay                  58.2G     10.6G     47.7G  18% /opt/docker/overlay2/16bc8951579f2808014d5f8e7588bc4da475a7cdbdb53a612620dcb403c53f15/merged
overlay                  58.2G     10.6G     47.7G  18% /opt/docker/overlay2/b1c8d831feafc49e420a49f987c03af7ba7d197fb4cdf68b0d6bfa976b917723/merged
overlay                  58.2G     10.6G     47.7G  18% /opt/docker/overlay2/9db851bc231a5296f045b050da579755f2935b4b82bdd89732475c5098143c37/merged
overlay                   1.9G    166.4M      1.7G   9% /etc/backup
overlay                   1.9G    166.4M      1.7G   9% /etc/backup
[root@RPi-OpenWRT /]#

1 Like

hmmmm...

umount -l /etc/backup
umount -l /etc/backup
sysupgrade -b /tmp/test.tar.gz
ls -lah /tmp/test.tar.gz

other than that... probably the

/dev/root                58.2G     10.6G     47.7G  18% /opt/docker
overlay                  58.2G     10.6G     47.7G  18% /opt/docker/overlay2/...

are throwing the ( mainline ) logic a problem... if you can boot without the docker mounts and test again...


also heed comments here if your sysupgrade.conf is trying to backup docker stuff located on /

Unmounted successfully

1 Like

Sure, let me give it a try.

1 Like

Okay, so trying without dockerd enabled after a reboot got rid of the overlays temporarily, as per this mount output:

/dev/mmcblk0p2 on / type ext4 (rw,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
overlay on /etc/backup type overlay (rw,relatime,lowerdir=/etc/backup,upperdir=/tmp/sysupgrade.klEEkm/upper,workdir=/tmp/sysupgrade.klEEkm/work)

However it seems that the backup was still unable to be created on the tmpfs:

[root@RPi-OpenWRT /]# sysupgrade -b /tmp/test.tar.gz
Wed Sep 29 01:44:16 CDT 2021 upgrade: AUTORESTORE [no]
Wed Sep 29 01:44:16 CDT 2021 upgrade: Saving config files...
Failed to create the configuration backup.
[root@RPi-OpenWRT /]# ls -lah /tmp/test.tar.gz
ls: /tmp/test.tar.gz: No such file or directory

What seems interesting is that while the command was running both busybox and tar kept either core 1 or 3 up to 100%, changing between them over time, and RAM usage increased up to 1.4GB till failure, then dropping down to around 800MB.

The mSD card I'm using is 64GB and my RPi is the 4GB version, so at least concerns of lack of space are not at the top of the list for me right now (according to the Software tab I have over 81% available storage space).

At least it seems that the mount was successfully created now on /etc/backup

[root@RPi-OpenWRT /]# ls /etc/backup
installed_diffONE.txt
installed_diffTWO.txt
installed_packages.txt
installed_packages_clean.txt
installed_packages_clean.txt.wREMopK
installed_packages_community_original.txt
[root@RPi-OpenWRT /]# mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
overlay on /etc/backup type overlay (rw,relatime,lowerdir=/etc/backup,upperdir=/tmp/sysupgrade.klEEkm/upper,workdir=/tmp/sysupgrade.klEEkm/work)

So I'm not sure if given the last commands' results if it would be a good idea to attempt the upgrade again.

[root@RPi-OpenWRT /]# ls /tmp/sysupgrade.klEEkm
upper/ work/
[root@RPi-OpenWRT /]# ls /tmp/sysupgrade.klEEkm/upper
installed_packages.txt
[root@RPi-OpenWRT /]# ls /tmp/sysupgrade.klEEkm/work
work/
[root@RPi-OpenWRT /]# ls /tmp/sysupgrade.klEEkm/work/work
[root@RPi-OpenWRT /]# ls
bin/
boot/
dev/
downloads/
etc/
lib/
lib64@
lost+found/
mnt/
opt/
overlay/
proc/
restorefiles/
rom/
root/
run/
sbin/
srv/
sys/
systeminfo
tmp/
usr/
var@
wireshark-helper_202107v2.tar.gz
www/
www_fakeinternet/
[root@RPi-OpenWRT /]#
1 Like

is your backup too large?

tail -n20 /etc/sysupgrade.conf

Oh, that's what you meant.

Yeah, perhaps it is a tad chonky now that I think about it.

[root@RPi-OpenWRT /]# cat /etc/sysupgrade.conf
## This file contains files and directories that should
## be preserved during an upgrade.

/bin/toaster.sh
/etc/openvpn/
/root/wrt.ini
/root/docker/compose/servicehub/
/restorefiles/
/etc/custom/cumulative.txt
/etc/dropbear/authorized_keys
/root/.ssh/known_hosts
/root/.ssh/authorized_keys
/root/.ssh/
/etc/HomeAssistant/
/etc/init.d/rclone-mounts
/etc/nut/
/etc/plex/
/etc/docker/
/etc/vhusbd/
/etc/x3mRouting/
/usr/bin/rclone
/etc/hosts
/etc/sysupgrade.conf
/etc/firewall.user
/etc/packagesremove.txt
/etc/packagesinstall.txt
/etc/luciqrcodes.txt
/bin/wirelessinfo.sh
/etc/perftweaks.txt
/tmp/rrd/
/var/lib/nlbwmon/
/etc/dummypath
/etc/quagga/ospf6d.conf
/etc/quagga/ospfd.conf
/etc/quagga/zebra.conf
/root/eeprom.config.raw
/root/eeprom.config.merge
/etc/custom/manpage/
/etc/tvheadend/
/etc/simple-adblock.addnhosts.gz
/etc/simple-adblock.dnsmasq.gz
/etc/simple-adblock.ipset.gz
/etc/simple-adblock.servers.gz
/etc/simple-adblock.unbound.gz
/var/run/simple-adblock.servers
/etc/custom/firewall/dscp/backup/

Given the extra RAM, is there a way to expand the tmpfs limit, or is it that I'm reaching said limit what's triggering the problem?

[root@RPi-OpenWRT /]# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                58.2G     10.5G     47.7G  18% /
tmpfs                     1.9G      6.4M      1.8G   0% /tmp
/dev/mmcblk0p1          383.8M     70.8M    313.0M  18% /boot
tmpfs                   512.0K         0    512.0K   0% /dev
overlay                   1.9G      6.4M      1.8G   0% /etc/backup

you can expand /tmp ... but the file is then copied to boot which has only 200MB free... so it won't solve the issue...

i.e.

mount -o remount,size=3000M /dev/shm /tmp/

large data that should be kept during upgrade is best handled with an fstab mount to an additional usb3 drive (and left out of sysupgrade.conf)

########################### /etc/config/fstab

config mount
	option target '/opt'
	option uuid 'aa8fca3f-7077-4f41-a289-ca04fc22470d'
	option enabled '1'
	option enabled_fsck '1'

above '/opt' is an example for the runtime mount location of the large data files...

looking at your backup list... i'm guessing one/some of these directories contain more than around 300MB

/root/docker/compose/servicehub/
/etc/HomeAssistant/
/etc/nut/
/etc/plex/
/etc/docker/
/etc/vhusbd/
/etc/x3mRouting/

so the idea is to;

  • get them under '/opt' or ( the /etc/config/fstab external usb3 drive mountpoint ) AND/OR
  • bindmount / symlink them to the external drive at startup etc. etc. OR
  • manually backup and restore them
1 Like

I see... looks like I got to an edge case again :sweat_smile:

As I'm understanding, by pointing /opt to an external drive I should be able to handle Docker screwing with the backup, with the only downside being having to deal with an external drive having to be plugged in at all times.

As such, having a "big" mSD card is of limited usability at the moment, and most multitasking operations that require storage space should be left up to external flash storage for the time being, is that correct?

If so, would a 32GB stick of ext4 over USB3 suffice for the mount, or should I consider something larger like an NVMe enclosure?

it is volatile due to the built in backup constraints...

it can be used for 'scratch'... ( temporary chroots / lxc ) or runtime lxc/docker... but you

  • must handle backup and restore manually

sounds good to me... for stuff like docker tho' it may fail after a few months... so ssd/nvme is definately a more robust option (but will likely need a usb hub)

1 Like

Okay, this one seems like the best alternative so far.

So then I should just move over the docker-compose mounted volumes over from /etc to /opt and as long as /etc and the rest of the stock partitions can fit under the 200MB limit everything would be peachy.

Then this would mean definitely moving everything over to and mounting /opt on an external drive would be the final solution for in place upgrades. Well, I learn something new every day.

Thanks for the help! :smiley:

1 Like

Yup... perfect!


OpenWrt is based on traditionally small amounts of flash memory ( 8M to 128M )... where only tiny backup files are/can-be stored...

In this build... i've made several 'enhancements' to support

  • larger amounts of packages
  • expansion of the rootfs
    but the underlying backup method is still traditional ( although with a stock image /boot is maybe 50M not 300M )

I tried to make it very clear when I implemented ROOTFSEXPAND that this will be an underlying limitation... ( and have told anyone using large datasets to use an exteral drive / mount for those ) since day 1... but it is good for you to test the limits, and see how errors manifest first hand... (and edge cases with verbose debugging help I learn alot from... so thanks)

( i.e. I still need to make this advice more clearer... and perhaps in the future I will make some more modifications to better support large data migration )

these constraints (and solutions) will exist on official (all) images...

Thank YOU wulfy, honestly you're the most patient developer I've dealt with so far, and as you say this experience has definitely teached me a lot of somethings, having you along for the ride certainly has helped my sanity from dwindling any lower :sweat_smile:

Then again, to tell you the truth the search function only helped me so much in finding out that you had already answered this sort of question, as I just found out about the quote above from checking the replies to the OP, so maybe something like a README.md on the download site or a warning to check the replies on the OP would help discoverability if you're still able to edit that one (I honestly thought the replies were either praise from fellow users or reserved posts for thread managing).

In any case, I sure am glad that I can put to rest this latest adventure, and a donation is surely coming your way after payday :blush:.

Thanks for everything, I guess i have my work cut out tomorrow. :sweat_smile:

1 Like

one it's setup it works beautifully... (and upgrades are fast as large data does not need to be moved)

[root@dca632 /usbstick 53°] mount | grep usbstick
/dev/sda1 on /usbstick type ext4 (rw,relatime)

[root@dca632 /usbstick 52°] uci show fstab | grep -A3 usbstick
fstab.@mount[2].target='/usbstick'
fstab.@mount[2].uuid='aa8fca3f-7077-4f41-a289-ca04fc22470d'
fstab.@mount[2].enabled='1'
fstab.@mount[2].enabled_fsck='1'

[root@dca632 /usbstick 52°] df -h | grep usbstick
Filesystem                Size      Used Available Use% Mounted on
/dev/sda1               112.3G     29.8G     76.8G  28% /usbstick

It looks beautiful indeed! Now I just need to harvest the convention bag for a stick 'till I can get my hands on another NVMe drive. Not too shabby for being my first homelab! :grinning_face_with_smiling_eyes:

1 Like
/usr/lib/lua/luci/dispatcher.lua:427: /etc/config/luci seems to be corrupt, unable to find section 'main'

should I reboot?

1 Like

hmmm... that's the second time you've had an odd /etc/config/luci error but seems uniq to you...

so will be really hard for me to troubleshoot... I think last time we were thinking about failing sdcard or something... (what model is the sdcard?)

if nobody else has the issue... likely that or related to some additional package/manual change? but also suspect the error is a little misleading... like that config file is not the real issue or something... is there any relationship between high-io (lots of file copy operations) and the error?
you only need the last rpcd restart command see below

ucivalidate.sh 2>/dev/null | grep luci
cat /etc/config/luci
###################################
curl -sSL https://raw.githubusercontent.com/wulfy23/rpi4/master/utilities/config-luci > /etc/config/luci
rm -rf /tmp/luci*
/etc/init.d/uhttpd restart; /etc/init.d/rpcd restart

40 results on the forum...

'rebooting fixes but comes back'

'make sure rpcd is running'

ok this seems closest...
'And I seem to be able to reproduce the crash, even after your suggested move. Whenever I browse to the connection stats page and then somewhere else, I get an error'


so... some sort of rpcd crash related to visiting the 'connections' page?

think you should join in on the thread above ( or this github issue ) as it's looking like a non-build related resource problem (conntrack js overheads/quirks spamming rpcd? lib-json-c struct overflow? beyond my paygrade!)...

lol@slim-wrt workaround! just remove connections!


maybe see if this helps... (needs restart and browser cache clear);


sed -i 's|pollInterval=3|pollInterval=10|g' /www/luci-static/resources/view/status/connections.js
1 Like

It is fine now after reboot.
Yes, I was trying to check status > realtime graphs > connections

memory card is from Kingston select plus 32GB

1 Like

fyi...;

Failed to create the configuration backup

they will get;

############################################
Failed to create the configuration backup
############################################
it's probably too big (max 200MB)
remove large directories from your /etc/sysupgrade.conf
and backup / restore them manually
############################################

thanks again for the feedback...
(note: 200MB is the tar.gz limit which is probably something closer to 550MB in raw data files depending on the filetype)

Every time we talk you impress me more and more, honestly it's perfect!

Thanks for all the help so far!

And while on the topic of Big large data, I caught a glimpse that you were able to get ffmpeg to use hardware acceleration to a degree and was wondering if you had kept the libraries around so as to use them with Jellyfin per this guide, since I'm able to see the onboard encoder just fine.

Also, not sure if this is something that "requires" fixing, but it seems that the original youtube-dl is being superceded by this fork (yt-dlp), since the mantainers of the original project don't seem to be as active as in previous years, so while I don't use the feature personally, it might be worth it to take a look into changing over to the newer binary and giving it a test drive.

Also seem to be having some issues with both Wireguard and Transmission not opening their ports even after explicitly opening them in the firewall, but I'm pretty sure that has more to do with the packages rather than the build.

The upgrade worked correctly from yesterday's convo over to today's current build, and aside from some connection timeouts I'm looking into, everything's peachy so far.

Will keep you posted if I find anything else, and thanks again for all your guidance!

1 Like