Joined: 05 Oct 2008 Posts: 647 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Thu Oct 27, 2022 12:15 Post subject:
I ran the commands from the alias definition in the GUI through Run Commands.
The shutdown script ran and wrote logger command output to the syslog.
I havve no way of knowing if the actual commands in the script were succesful.
The router continued running and both /jffs and /opt were still/again mounted when I checked in Services, USB.
Oct 27 14:05:41 R7800 user.notice ---: /tmp/.rc_shutdown script: Stopping rc.unslung
Oct 27 14:05:46 R7800 user.notice ---: /tmp/.rc_shutdown script: Unmounting /jffs and /opt
Oct 27 14:05:51 R7800 user.notice ---: /tmp/.rc_shutdown script: Do e2fsck -p check on thumbdrive partitions sda1 & sda2
If you try to unmount something that has a script running from it or even has a shell open with the current directory on it you'll fail with a resource busy. That's why my shutdown alias starts with a cd; which changes to the home directory. My GUI shutdown script runs a hidden copy of my shutdown script placed in the home directory on boot by my startup script.
Code:
/tmp/root/.myShutdown.sh
That way the unmounts don't fail. I assume your entware and other things running off those filesystems have already stopped when the unmount is attempted.
The .profile is explained on page 16 but I generate it on the fly which explains the double quote cut&paste error earlier.
Code:
# setup a ~/.profile file
OUTFILE=/tmp/root/.profile
Joined: 05 Oct 2008 Posts: 647 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Thu Oct 27, 2022 20:16 Post subject:
I implemented your advice on having a myShutdown.sh script in the home directory /tmp/root.
(and the .profile file with the alias)
Both .profile and myShutdown.sh are copied to /tmp/root in the course of the startup script in the GUI.
I have disabled sending dnsmasq.leases to /jffs in an attempt to free /jffs from open files, which prevent unmounting.
myShutdown.sh script:
#!/bin/sh
# AR - 02-05-2022, 27-10-2022
# Shutdown script for manual shutdown
So ... /opt is unmounted and checked as intended, but /jffs (/dev/sda1) remains busy. However, per lsof there are no open files on /dev/sda1 ...
I have a file with reserved ip's on /jffs.
Would that be kept open on the thumbdrive, or are the contents copied to RAM when the router is running?
Only firewall.sh is run from /jffs, but I assume it is closed as soon as execution finishes (which is several times during router startup).
Joined: 05 Oct 2008 Posts: 647 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Fri Oct 28, 2022 0:48 Post subject:
The problem likely was having samba shares for /jffs and/or /opt 'open' in my laptop. No file windows open, but just having them mentioned in the file manager's directory list in the left panel under the heading Network with the ejector icon next to it (this is on Linux Mint).
After I 'ejected' those, the shutdown proceeded with flying colors:
(this was after several earlier runs of myShutdown.sh done before finally ejecting the samba shares!)
I made more changes than just that before this latest successful attempt. Among other things I put the delay procedure waiting for jffs and optware to be mounted at the very beginning of the startup script. After that copying all script files to be run into the ~ directory /tmp/root. Only then the rest.
Using the shutdown procedure it should no longer be necessary to remove the thumbdrive from the router in order to check and repair the file systems on it.
My R7800 keeps going after the shutdown, but of course it needs to be rebooted for proper operation as /jffs and /opt end up unmounted.
I suspect abruptly cutting power to the router is what causes the FS errors on the thumbdrive. It happens with e.g. Raspberry Pi's, too, if you cannot shut them down properly, but Raspberry OS performs a file system check in an appropriate spot during the boot procedure.
AFAIK there's no telling how early thumbdrive partitions may get mounted, so it may not be possible for a user to have FS checks executed in a user added script before those partitions get mounted with certainty. The is-mounted commands used to delay the startup script until jffs and opt are mounted usually take only a few seconds each, but that delay may just be because it takes some time to find out.
Last edited by ArjenR49 on Fri Oct 28, 2022 9:18; edited 1 time in total
Was just about to click "post reply" to say to check for network shares. Then refreshed the browser and your last post appeared. Sounds like you're all set.
I have a couple of aliases to quickly/easily remount partitions without rebooting. I've seen dd-wrt lose a mount before but not recently so I almost never use those aliases.
If you have an improved nvram-dd-wrt.ini file for nvram-save.sh variables please share it. Some obsolete variables names need to be replaced by up to date variables.
Joined: 05 Oct 2008 Posts: 647 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Fri Oct 28, 2022 9:58 Post subject:
yoyoma2 wrote:
Was just about to click "post reply" to say to check for network shares. Then refreshed the browser and your last post appeared. Sounds like you're all set.
That's what I thought, too. All ready ...
yoyoma2 wrote:
I have a couple of aliases to quickly/easily remount partitions without rebooting. I've seen dd-wrt lose a mount before but not recently so I almost never use those aliases.
If you have an improved nvram-dd-wrt.ini file for nvram-save.sh variables please share it. Some obsolete variables names need to be replaced by up to date variables.
I only added those command scripts from the GUI that were missing from the original, but as it is now, there's not much in the last three, just a call to a script in the ~ directory.
Nvram variables are uncharted territory for me. Manually comparing name lists would be very tedious. A utility like Kompare comes to mind. I've used it for propagating my own changes to newer versions of python scripts posted by their author. Probably something a more sophisticated user would do with Github, but I haven't taken to that.
As I understand from recent forum posts, there are some new variables and changes in the DDNS section.
For now your suggestion serves to prove that this router tuning is indeed a never ending business, like any hobby. Of course, I am very happy with the improvements that I was able to make with your help. Thank you!
I need to do some more household chores and plant flower bulbs, though, before I leave my cottage for the winter months
Added @ArjenR49's variables to the [Administration - Commands] section in nvram-dd-wrt.ini.sample. Only affects nvram save/restore not upgrading/downgrading.
Can someone run checknewversion.sh and confirm the easyddup self update works. You need to have a recent version of easyddup that has file VERSION.txt. Thanks.
checknewversion.ini needs the following settings for self update to work:
Joined: 05 Oct 2008 Posts: 647 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Fri Oct 28, 2022 17:07 Post subject:
yoyoma2 wrote:
New version 0.9.2 (October 28th).
Changes:
Added @ArjenR49's variables to the [Administration - Commands] section in nvram-dd-wrt.ini.sample. Only affects nvram save/restore not upgrading/downgrading.
Can someone run checknewversion.sh and confirm the easyddup self update works. You need to have a recent version of easyddup that has file VERSION.txt. Thanks.
checknewversion.ini needs the following settings for self update to work:
Changed only the two variables FORUM* and then ran the script on the router (in ssh session). Didn't bother with the email. Your instructions were exactly concise enough
(I have no email on the router. Why would you want email on a router? )
Output:
root@R7800:/opt/easyddup# checknewversion.sh
Upgrading easyddup from version 0.9.1 to version 0.9.2
Getting latest easyddup package from dd-wrt forum.
Installing and running new easyddup version 0.9.2
root@R7800:/opt/easyddup#
So, yes it works. Or rather, it says that it updated. I didn't check a version number ....
Checking for a new build to appear any minute ... it's an addiction
I past dd-wrtoholic firmly into the dd-wrtocd with a side dish of despair.
There are tons of hobbies that take up tons of time like netflix binging, video games, social media, TV... that teach and contribute nothing. This hobby is still productive and helpful and I personally appreciate all the guru contributions...
when you tried out the experimental_driver. Comment out (with #) or delete the EDDUP_HARDWARE_FOLDER line and the default folder will be used. See the bottom of page 14 of this thread where EDDUP_HARDWARE_FOLDER is discussed.
when you tried out the experimental_driver. Comment out (with #) or delete the EDDUP_HARDWARE_FOLDER line and the default folder will be used. See the bottom of page 14 of this thread where EDDUP_HARDWARE_FOLDER is discussed.
Since the dd-wrt ssl certificate expires occasionally, I added a new keyword in easyddup.ini.sample so just add the following line in your easyddup.ini to force easyddup to use http instead of https thus bypassing the expired certificate problem.
Code:
EDDUP_DISABLE_HTTPS=Y
Improved error handling so even without EDDUP_DISABLE_HTTPS the menus still work since we correctly fallback to the secondary url used by the website which has the updated certificate. The final download does require EDDUP_DISABLE_HTTPS=Y until the dd-wrt server is fixed.
The improved error handling fixes a possible zero byte file size in multipart download so upgrading to 0.9.3 is recommended regardless of https/http.
As usual to upgrade just run checknewversion.sh but make sure your checknewversion.ini file has these lines with your forum credentials so the download can work.
Since after upgrading checknewversion.sh runs easyddup at the end you will get an error due to the expired certificate but it can be ignored if a message already said that easyddup was upgraded. Putting EDDUP_DISABLE_HTTPS=Y in your easyddup.inibefore upgrading might avoid this error.
