Collection of scripts for stock firmware

[jacklul]

Just checking that your script handles this: there are two pids with that configuration running on my router. I'm not needing this, but I'd thought I'd let you know.

That's interesting, why would there be two instances running off /etc/stubby/stubby-0.yml config file?
I've updated the script to use a loop, just like in my custom-configs script.

 

[rung]

My apologies, you were right all along. There is only one stubby process. This updated command now just shows on pid after all:

/bin/ps w | grep -v
 "grep" | grep -F "stubby" | grep -F "/etc/stubby/
stubby-0.yml" | awk '{print $1}'

 

[jacklul]

My apologies, you were right all along. There is only one stubby process. This updated command now just shows on pid after all:

/bin/ps w | grep -v "grep" | grep -F "stubby" | grep -F "/etc/stubby/stubby-0.yml" | awk '{print $1}'

grep -v "grep" | grep -F "stubby"

usually can be replaced with a trick like this

grep "[s]tubby"

no real speed benefits since we are replacing two calls with one regex call but we shorten the code little for easier read

 

[ugdp3]

It seems there might be an incompatibility between the usb-mount-script workaround and the Entware script. When using the workaround /opt is symlinked to /tmp/opt, which itself is symlinked to /tmp/mnt/drivename/asusware.arm. Enabling the entware script makes the mount detection fail (is_entware_mounted function specifically), as there is no such on /opt line returned in the output of the mount command. This results in the entware script's cron job mounting the entware folder again and again and again...

The output of the mount command looks like this, and I believe the duplicate lines would otherwise refer to /opt when not using the USB workaround:

/dev/sda1 on /tmp/mnt/drivename type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
... etc ...

 

[jacklul]

It seems there might be an incompatibility between the usb-mount-script workaround and the Entware script. When using the workaround /opt is symlinked to /tmp/opt, which itself is symlinked to /tmp/mnt/drivename/asusware.arm. Enabling the entware script makes the mount detection fail (is_entware_mounted function specifically), as there is no such on /opt line returned in the output of the mount command. This results in the entware script's cron job mounting the entware folder again and again and again...

The output of the mount command looks like this, and I believe the duplicate lines would otherwise refer to /opt when not using the USB workaround:

/dev/sda1 on /tmp/mnt/drivename type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)
... etc ...

This might happen if you unplug the stick after Entware script mounted /opt as Entware
/tmp/mnt/drivename/asusware.arm is not Entware folder by the workaround / Asus apps, this is caused by Asus app scripts
I am personally using both usb-mount-script and entware script and never seen this happen...

 

[ugdp3]

This might happen if you unplug the stick after Entware script mounted /opt as Entware
/tmp/mnt/drivename/asusware.arm is not Entware folder by the workaround / Asus apps, this is caused by Asus app scripts
I am personally using both usb-mount-script and entware script and never seen this happen...

I haven't unplugged the drive or rebooted the router since I first set up the scripts. Mounting the entware folder does actually work, it's just that the mount detection logic does not work properly because the output of the mount command is different from what it expects to see:

xx@xxx:/tmp/home/root# mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=246024k,nr_inodes=61506,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/ubi0_4 on /jffs type ubifs (rw,noatime,assert=read-only,ubi=0,vol=4)
/dev/sda1 on /tmp/mnt/drivename type ext4 (rw,nodev,noatime)

xx@xxx:/tmp/home/root# ls /opt
S50usb-mount-script.1        jacklul-asuswrt-scripts.url
etc                          lib

xx@xxx:/tmp/home/root# mount --bind /tmp/mnt/drivename/entware /opt

xx@xxx:/tmp/home/root# ls /opt
bin      home     libexec  sbin     tmp      var
etc      lib      root     share    usr

xx@xxx:/tmp/home/root# mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=246024k,nr_inodes=61506,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/ubi0_4 on /jffs type ubifs (rw,noatime,assert=read-only,ubi=0,vol=4)
/dev/sda1 on /tmp/mnt/drivename type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)

xx@xxx:/tmp/home/root# umount /tmp/mnt/drivename/asusware.arm

xx@xxx:/tmp/home/root# mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=246024k,nr_inodes=61506,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/ubi0_4 on /jffs type ubifs (rw,noatime,assert=read-only,ubi=0,vol=4)
/dev/sda1 on /tmp/mnt/drivename type ext4 (rw,nodev,noatime)

 

[jacklul]

I haven't unplugged the drive or rebooted the router since I first set up the scripts. Mounting the entware folder does actually work, it's just that the mount detection logic does not work properly because the output of the mount command is different from what it expects to see:

xx@xxx:/tmp/home/root# mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=246024k,nr_inodes=61506,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/ubi0_4 on /jffs type ubifs (rw,noatime,assert=read-only,ubi=0,vol=4)
/dev/sda1 on /tmp/mnt/drivename type ext4 (rw,nodev,noatime)

xx@xxx:/tmp/home/root# ls /opt
S50usb-mount-script.1        jacklul-asuswrt-scripts.url
etc                          lib

xx@xxx:/tmp/home/root# mount --bind /tmp/mnt/drivename/entware /opt

xx@xxx:/tmp/home/root# ls /opt
bin      home     libexec  sbin     tmp      var
etc      lib      root     share    usr

xx@xxx:/tmp/home/root# mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=246024k,nr_inodes=61506,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/ubi0_4 on /jffs type ubifs (rw,noatime,assert=read-only,ubi=0,vol=4)
/dev/sda1 on /tmp/mnt/drivename type ext4 (rw,nodev,noatime)
/dev/sda1 on /tmp/mnt/drivename/asusware.arm type ext4 (rw,nodev,noatime)

xx@xxx:/tmp/home/root# umount /tmp/mnt/drivename/asusware.arm

xx@xxx:/tmp/home/root# mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=246024k,nr_inodes=61506,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/ubi0_4 on /jffs type ubifs (rw,noatime,assert=read-only,ubi=0,vol=4)
/dev/sda1 on /tmp/mnt/drivename type ext4 (rw,nodev,noatime)

This is really weird behavior, no idea why would mounting entware folder show up as asusware.arm
What device? Is it newer or older model than mine?
Does the Entware actually start?
What is the output of:
cat /proc/mounts
df

 

[ugdp3]

This is really weird behavior, no idea why would mounting entware folder show up as asusware.arm
What device? Is it newer or older model than mine?
Does the Entware actually start?
What is the output of:
cat /proc/mounts
df

My router is a RT-AX59U, running firmware version 3.0.0.4.388_33407 (newer versions are bugged with unreliable Wi-Fi).

xx@xxx:/tmp/home/root# cat /proc/mounts
/dev/root / squashfs ro,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=246024k,nr_inodes=61506,mode=755 0 0
proc /proc proc rw,relatime 0 0
tmpfs /tmp tmpfs rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
/dev/ubi0_4 /jffs ubifs rw,noatime,assert=read-only,ubi=0,vol=4 0 0
/dev/sda1 /tmp/mnt/drivename ext4 rw,nodev,noatime 0 0

xx@xxx:/tmp/home/root# jas enable entware
Enabled: entware

xx@xxx:/tmp/home/root# jas exec entware start
Mounted '/tmp/mnt/drivename/entware' on /opt
Unable to start services - Entware is not mounted

xx@xxx:/tmp/home/root# cat /proc/mounts
/dev/root / squashfs ro,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=246024k,nr_inodes=61506,mode=755 0 0
proc /proc proc rw,relatime 0 0
tmpfs /tmp tmpfs rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
/dev/ubi0_4 /jffs ubifs rw,noatime,assert=read-only,ubi=0,vol=4 0 0
/dev/sda1 /tmp/mnt/drivename ext4 rw,nodev,noatime 0 0
/dev/sda1 /tmp/mnt/drivename/asusware.arm ext4 rw,nodev,noatime 0 0
/dev/sda1 /tmp/mnt/drivename/asusware.arm ext4 rw,nodev,noatime 0 0

xx@xxx:/tmp/home/root# cat /proc/mounts
/dev/root / squashfs ro,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=246024k,nr_inodes=61506,mode=755 0 0
proc /proc proc rw,relatime 0 0
tmpfs /tmp tmpfs rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
/dev/ubi0_4 /jffs ubifs rw,noatime,assert=read-only,ubi=0,vol=4 0 0
/dev/sda1 /tmp/mnt/drivename ext4 rw,nodev,noatime 0 0
/dev/sda1 /tmp/mnt/drivename/asusware.arm ext4 rw,nodev,noatime 0 0
/dev/sda1 /tmp/mnt/drivename/asusware.arm ext4 rw,nodev,noatime 0 0

xx@xxx:/tmp/home/root# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                35712     35712         0 100% /
devtmpfs                246024         0    246024   0% /dev
tmpfs                   246248      5480    240768   2% /tmp
/dev/ubi0_4              40940      2236     36576   6% /jffs
/dev/sda1              7626880     15060   7203808   0% /tmp/mnt/drivename
/dev/sda1              7626880     15060   7203808   0% /tmp/mnt/drivename/asusware.arm
/dev/sda1              7626880     15060   7203808   0% /tmp/mnt/drivename/asusware.arm

I believe the problem is that both /opt and /tmp/opt are turned into symlinks when using the asusware USB workaround, at least that is what other sources say. It may be necessary to tweak the USB startup script to undo the symlinking, or perhaps the entware script could detect this situation and implement another kind of detection.

 

[jacklul]

I believe the problem is that both /opt and /tmp/opt are turned into symlinks when using the asusware USB workaround, at least that is what other sources say. It may be necessary to tweak the USB startup script to undo the symlinking, or perhaps the entware script could detect this situation and implement another kind of detection.

The workaround is utilizing something included in the firmware, you can't undo /opt=>/tmp/opt symlink as the filesystem is read-only, that's why bind-mount is required here.
Is 'drivename' the actual label of your USB device? Does the real label contain any unusual characters?
Try entware script from develop branch and let me know if it works or at least does not create multiple mounts.

 

[ugdp3]

The workaround is utilizing something included in the firmware, you can't undo /opt=>/tmp/opt symlink as the filesystem is read-only, that's why bind-mount is required here.
Is 'drivename' the actual label of your USB device? Does the real label contain any unusual characters?
Try entware script from develop branch and let me know if it works or at least does not create multiple mounts.

The real label isn't anything special, it purely uses lowercase letters. As for the develop branch, it seems the updated version of the script now thinks entware is always mounted & as a result now does nothing at all. In particular, the output of df /opt 2> /dev/null | tail -n +2 | tail -n 1 | awk '{print $1}' is /dev/sda1 on my system, without entware mounted. Maybe instead of hardcoding on /opt in the check, it should first try to resolve any symlinks, and then check for on ${resolved_symlink}.

 

[jacklul]

The real label isn't anything special, it purely uses lowercase letters. As for the develop branch, it seems the updated version of the script now thinks entware is always mounted & as a result now does nothing at all. In particular, the output of df /opt 2> /dev/null | tail -n +2 | tail -n 1 | awk '{print $1}' is /dev/sda1 on my system, without entware mounted.

What about df /opt 2> /dev/null | grep -Fv "/dev/root" | tail -n +2 ?
I've renamed is_entware_mounted to is_opt_mounted to better reflect what that function is for, it now has two conditions and excludes /dev/root.

Maybe instead of hardcoding on /opt in the check, it should first try to resolve any symlinks, and then check for on ${resolved_symlink}.

If I resolve the symlinks they will lead me to asusware directory, which is not what we want.
Entware wants to be mounted under /opt, that's why I'm using "on /opt".

Maybe we should focus on looking up why mount --bind /tmp/mnt/drivename/entware /opt does not create the entry with /opt mountpoint.

This is how it looks on my router:

RT-AX58U:/jffs# df
Filesystem                Size      Used Available Use% Mounted on
/dev/root                42.1M     42.1M         0 100% /
devtmpfs                248.1M      3.8M    244.3M   2% /dev
tmpfs                   248.6M    512.0K    248.1M   0% /var
tmpfs                   248.6M      5.8M    242.8M   2% /tmp/mnt
ubi:data                 16.8M    120.0K     15.8M   1% /data
ubi:defaults              5.7M    380.0K      5.0M   7% /tmp/mnt/defaults
ubi:jffs2                44.5M      1.4M     40.7M   3% /jffs
tmpfs                   248.6M      5.8M    242.8M   2% /tmp/mnt
ubi:defaults              5.7M    380.0K      5.0M   7% /tmp/mnt/defaults
tmpfs                   248.6M      5.8M    242.8M   2% /tmp
ubi:defaults              5.7M    380.0K      5.0M   7% /tmp/mnt/defaults
/dev/sda1                14.1G    634.4M     12.8G   5% /tmp/mnt/sda1
tmpfs                   248.6M      5.8M    242.8M   2% /www/cpu_ram_status.asp
tmpfs                   248.6M      5.8M    242.8M   2% /www/device-map/router_status.asp
tmpfs                   248.6M      5.8M    242.8M   2% /www/Guest_network.asp
tmpfs                   248.6M      5.8M    242.8M   2% /www/state.js
tmpfs                   248.6M      5.8M    242.8M   2% /www/require/modules/menuTree.js
tmpfs                   248.6M      5.8M    242.8M   2% /www/Advanced_System_Content.asp
/dev/sda1                14.1G    634.4M     12.8G   5% /opt
tmpfs                   248.6M      5.8M    242.8M   2% /opt/var/lock
tmpfs                   248.6M      5.8M    242.8M   2% /opt/var/log
tmpfs                   248.6M      5.8M    242.8M   2% /opt/var/run
tmpfs                   248.6M      5.8M    242.8M   2% /opt/var/lib/unbound/unbound.log

RT-AX58U:/jffs# mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=254092k,nr_inodes=63523,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
tmpfs on /tmp/mnt type tmpfs (rw,relatime,size=16k,mode=755)
sysfs on /sys type sysfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
ubi:data on /data type ubifs (rw,relatime,assert=read-only,ubi=0,vol=10)
ubi:defaults on /tmp/mnt/defaults type ubifs (rw,relatime,assert=read-only,ubi=0,vol=11)
ubi:jffs2 on /jffs type ubifs (rw,relatime,assert=read-only,ubi=0,vol=13)
tmpfs on /tmp/mnt type tmpfs (rw,relatime,size=16k,mode=755)
ubi:defaults on /tmp/mnt/defaults type ubifs (rw,relatime,assert=read-only,ubi=0,vol=11)
tmpfs on /tmp type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
ubi:defaults on /tmp/mnt/defaults type ubifs (rw,relatime,assert=read-only,ubi=0,vol=11)
/dev/sda1 on /tmp/mnt/sda1 type ext4 (rw,nodev,relatime)
tmpfs on /www/cpu_ram_status.asp type tmpfs (rw,relatime)
tmpfs on /www/device-map/router_status.asp type tmpfs (rw,relatime)
tmpfs on /www/Guest_network.asp type tmpfs (rw,relatime)
tmpfs on /www/state.js type tmpfs (rw,relatime)
tmpfs on /www/require/modules/menuTree.js type tmpfs (rw,relatime)
tmpfs on /www/Advanced_System_Content.asp type tmpfs (rw,relatime)
/dev/sda1 on /opt type ext4 (rw,nodev,relatime)
tmpfs on /opt/var/lock type tmpfs (rw,relatime)
tmpfs on /opt/var/log type tmpfs (rw,relatime)
tmpfs on /opt/var/run type tmpfs (rw,relatime)
tmpfs on /opt/var/lib/unbound/unbound.log type tmpfs (rw,relatime)

# (with entware disabled)
RT-AX58U:/jffs# la /opt
drwxr-xr-x    3 admin    root         147 Oct  8 18:44 .
drwxrwxrwx   21 admin    root         381 Oct  8 18:44 ..
lrwxrwxrwx    1 admin    root          12 Oct  8 18:44 bin -> /tmp/opt/bin
lrwxrwxrwx    1 admin    root          12 Oct  8 18:44 doc -> /tmp/opt/doc
lrwxrwxrwx    1 admin    root          12 Oct  8 18:44 etc -> /tmp/opt/etc
lrwxrwxrwx    1 admin    root          16 Oct  8 18:44 include -> /tmp/opt/include
lrwxrwxrwx    1 admin    root          12 Oct  8 18:44 lib -> /tmp/opt/lib
lrwxrwxrwx    1 admin    root           7 Oct  8 18:40 opt -> tmp/opt
lrwxrwxrwx    1 admin    root          13 Oct  8 18:44 sbin -> /tmp/opt/sbin
drwxrwxrwx    2 admin    root         112 Oct  8 18:40 scripts
lrwxrwxrwx    1 admin    root          14 Oct  8 18:44 share -> /tmp/opt/share
lrwxrwxrwx    1 admin    root          12 Oct  8 18:44 tmp -> /tmp/opt/tmp
lrwxrwxrwx    1 admin    root          12 Oct  8 18:44 usr -> /tmp/opt/usr

For me /opt is a regular directory which contains symlinks to /tmp/opt/xxx, Asus' scripts mount asusware directory under /tmp/opt. You cannot simply mount Entware under /tmp/opt as there are directories used in Entware for which firmware does not have any symlink.
Perhaps, if /opt is a symlink, this could lead mount --bind to mount under the resolved path... to support this I would have to rewrite the script a bit.

My router seems to be at 3.0.0.4.388_25277, perhaps on the newer version something is now different...

 

[ugdp3]

What about df /opt 2> /dev/null | grep -Fv "/dev/root" | tail -n +2 ?
I've renamed is_entware_mounted to is_opt_mounted to better reflect what that function is for, it now has two conditions and excludes /dev/root.

The output is as follows:

/dev/sda1              7626880     15060   7203808   0% /tmp/mnt/drivename

If I resolve the symlinks they will lead me to asusware directory, which is not what we want.
Entware wants to be mounted under /opt, that's why I'm using "on /opt".

Maybe we should focus on looking up why mount --bind /tmp/mnt/drivename/entware /opt does not create the entry with /opt mountpoint.

This is how it looks on my router:
(snip)

For me /opt is a regular directory which contains symlinks to /tmp/opt/xxx, Asus' scripts mount asusware directory under /tmp/opt. You cannot simply mount Entware under /tmp/opt as there are directories used in Entware for which firmware does not have any symlink.

My router seems to be at 3.0.0.4.388_25277, perhaps on the newer version something is now different...

For me /opt is always a symlink to /tmp/opt, never a real directory.

xx@xxx:/jffs# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                35712     35712         0 100% /
devtmpfs                246024         0    246024   0% /dev
tmpfs                   246248      5568    240680   2% /tmp
/dev/ubi0_4              40940      1392     37424   4% /jffs
/dev/sda1              7626880     15060   7203808   0% /tmp/mnt/drivename

xx@xxx:/jffs# mount
/dev/root on / type squashfs (ro,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=246024k,nr_inodes=61506,mode=755)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/ubi0_4 on /jffs type ubifs (rw,noatime,assert=read-only,ubi=0,vol=4)
/dev/sda1 on /tmp/mnt/drivename type ext4 (rw,nodev,noatime)

xx@xxx:/jffs# ls -la /opt
lrwxrwxrwx    1 xx      root             7 Dec 11  2024 /opt -> tmp/opt

 

[jacklul]

Pushed another change to the develop branch, let me know if it works.

 

[ugdp3]

Pushed another change to the develop branch, let me know if it works.

It seems your latest change did the trick for me, and there are no more errors, duplicate mounts or endlessly firing cron jobs. Even though /opt is still a symlink (and mount still mentions the full asusware path), entware starts up successfully, with its files accessible at the usual locations within /opt.

 

[jacklul]

It seems your latest change did the trick for me, and there are no more errors, duplicate mounts or endlessly firing cron jobs. Even though /opt is still a symlink (and mount still mentions the full asusware path), entware starts up successfully, with its files accessible at the usual locations within /opt.

In the meantime I also pushed another change that now only resolves one level of the symlink and deletes it (/tmp/opt in your case) before mounting to make sure the mount is not created on the asusware directory but whatever /opt is pointing to.
This change might be incompatible with the previous one and will require manual unmount of the asusware mountpoint.
If it is possible for you to test this one too and confirming it is still working I will push it to main branch.

 

[ugdp3]

In the meantime I also pushed another change that now only resolves one level of the symlink and deletes it (/tmp/opt in your case) before mounting to make sure the mount is not created on the asusware directory but whatever /opt is pointing to.
This change might be incompatible with the previous one and will require manual unmount of the asusware mountpoint.
If it is possible for you to test this one too and confirming it is still working I will push it to main branch.

Even though I am using the latest version of the script, it doesn't look like it's deleting and recreating /opt at all. Probably it's because mount_opt does its thing with $opt, which at the beginning of the script is resolved to the real path of the symlink. In any case I'm not currently observing any ill behavior of the mount being done on the asusware directory, is there any specific reason why that is undesirable?

 

[jacklul]

Even though I am using the latest version of the script, it doesn't look like it's deleting and recreating /opt at all. Probably it's because mount_opt does its thing with $opt, which at the beginning of the script is resolved to the real path of the symlink. In any case I'm not currently observing any ill behavior of the mount being done on the asusware directory, is there any specific reason why that is undesirable?

The code at the beggining of the script should resolve /opt once, so $opt should become /tmp/opt, then code in mount_opt should delete /tmp/opt and make it a regular directory so mount --bind can work.
I would like to avoid putting any mounts on the USB device itself as it could lead to some undesired behavior when the USB stick is removed or suddenly dies - I'm sure the kernel can handle it but you never know...

 

[ugdp3]

The code at the beggining of the script should resolve /opt once, so $opt should become /tmp/opt, then code in mount_opt should delete /tmp/opt and make it a regular directory so mount --bind can work.
I would like to avoid putting any mounts on the USB device itself as it could lead to some undesired behavior when the USB stick is removed or suddenly dies - I'm sure the kernel can handle it but you never know...

Well, it's not doing that either. /tmp/opt is also still a symlink to /tmp/mnt/drivename/asusware.arm:

xx@xxx:/tmp# ls -la /tmp/opt
lrwxrwxrwx    1 xx    root            32 Nov 23 18:32 /tmp/opt -> /tmp/mnt/drivename/asusware.arm

 

[jacklul]

Well, it's not doing that either. /tmp/opt is also still a symlink to /tmp/mnt/drivename/asusware.arm:

xx@xxx:/tmp# ls -la /tmp/opt
lrwxrwxrwx    1 xx    root            32 Nov 23 18:32 /tmp/opt -> /tmp/mnt/drivename/asusware.arm

Did you update via jas update or fetched the script manually? I force-pushed to the repository later and maybe you have the outdated version.
The earlier version did not remove the link, so the mount command still followed /tmp/opt to /tmp/mnt/drivename/asusware.arm and mounted over it instead.

 

[ugdp3]

Did you update via jas update or fetched the script manually? I force-pushed to the repository later and maybe you have the outdated version.
The earlier version did not remove the link, so the mount command still followed /tmp/opt to /tmp/mnt/drivename/asusware.arm and mounted over it instead.

I used jas update to update. sha1 is 3d8944e08925a39f47744f2a3ef0fa93aa4b1f88, which seems to match the latest version even after the forcepush.