Recent content by ugdp3

This finally did the trick, and the entware directory is mounted to /tmp/opt, while leaving the asusware directory alone.

I see Mounted '/tmp/mnt/drivename/entware' on /tmp/mnt/drivename/asusware.arm in the syslog. I'm wondering if it's this check acting up. It seems readlink /opt returns tmp/opt for me, that is, a relative path.

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

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

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...

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...

The output is as follows: /dev/sda1 7626880 15060 7203808 0% /tmp/mnt/drivename 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...

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 |...

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...

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...

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...

I seem to have successfully set up asuswrt-scripts, together with a corresponding /jffs/scripts/dnsmasq.postconf script: #!/bin/sh [ -z "$1" ] && exit 1 # Remove IPv6 DNS servers sed -i '/^dhcp-option=lan,option6:23.*$/d' $1 # Add Pi-hole as IPv6 DNS echo...

It seems what I need to do is replace dhcp-option=lan,option6:23,[::] in dnsmasq.conf with dhcp-option=lan,option6:23,[fe80::mypiholeslinklocaladdress]. However, I have no idea how to do this. Looks like it may be possible on stock ASUSWRT though?

Yes, I did set the IPv6 DNS to my Pi-hole, and it "works", however it's being proxied by the router. The RA messages contain the IPv6 address of my router instead of that of my Pi-hole. The IPv4 side of things work correctly, and DNS is set to my Pi-hole's IPv4 address. The problem is with...

I have an ASUS RT-AX59U router running the official firmware (Merlin is not available), and a Pi-hole on my network acting as DNS. I have configured the router's DNS settings (both LAN/WAN) to be the Pi-hole instead of my ISP's DNS servers. This works well on IPv4 (DHCP includes my Pi-hole's...