Joined: 05 Oct 2008 Posts: 715 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Wed Aug 23, 2023 18:40 Post subject:
I can confirm that putting EDDUP_DISABLE_HTTPS=Y in easyddup.ini before upgrading avoids the error message.
The subsequent (manually initiated) upgrade on my R7800 went just fine.
root@R7800:~# cd /opt/easyddup
root@R7800:/opt/easyddup# checknewversion.sh
Upgrading easyddup from version 0.9.2 to version 0.9.3
Getting latest easyddup package from dd-wrt forum.
Installing and running new easyddup version 0.9.3
root@R7800:/opt/easyddup# easyddup.sh
All dd-wrt upgrade builds available online for 2023
1) 08-21-2023-r53396 <--- current
Current build: 53396
Select a build to install (or Q): q
Quitting
root@R7800:/opt/easyddup#
...
I had already installed r53396 in the GUI this morning or yesterday. Download using web page worked fine before I deleted the security exception which I had already forgotten about ...
The certificate on the server is valid again. Anyone who has EDDUP_DISABLE_HTTPS=Y in easyddup.ini should set it to N or delete/comment it out to start using https again.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 29.3M 100 29.3M 0 0 4320k 0 0:00:06 0:00:06 --:--:-- 4364k
Downloaded file OK.
WARNING THIS COULD BRICK YOUR ROUTER!!!
File to burn: ./fwcache/10-20-2023-r53714/netgear-r7800/dd-wrt-webupgrade.bin
Are you sure? Type YES to burn upgraded firmware: YES
Erase nvram y/n ? n
Save user settings restore point y/n ? y
Saving user settings restore point...
Burning ./fwcache/10-20-2023-r53714/netgear-r7800/dd-wrt-webupgrade.bin
WARNING: DO NOT INTERRUPT...
WAIT FOR BURN TO COMPLETE (at least 5 minutes)
Done burning
Rebooting...
./easyddup.sh: line 519: /sbin/reboot: I/O error
root@R7800:/opt/easyddup#
root@R7800:/opt/easyddup#
Situation now:
The router is running,
GUI renew results in error 404
Haven't yet looked at the script and its line 519, also not yet tried to reboot the R7800 via the still running SSH session. Saved the output as above and will then continue to find out what damage, if any.
The router has entware on a USB2 thumbdrive, which mounted fine last time I looked after the previous upgrade to build 53708, and was accessible via samba.
Glad I didn't just lose connection ....
Let's see what happens next ...
So I couldn't reboot the router via the terminal.
Forgot to try and unmount the thumbdrive partitions. They were not working properly anyway.
I pulled the thumbdrive before switching the R7800 off. Both partitions were in need of repair, which I assume means that they were 'dirty' because of the removal without unmounting.
After repairing both partitions on my Linux workstation, I powered the R7800 on again with the thumbdrive inserted. It started up in build 53714.
I have a Pi server collecting the router's syslog and saw that after the flashing, the router indeed just appeared to continue as indeed it did.
It seems to be fine now.
The sudden I/O errors are worrying, but at the moment I have no idea how to approach the problem.
Before I leave this location at the end of next month it would be desirable to get the router running reliably again ...
It seems the writing of the new firmware went fine. No idea why the root partition and others would suddenly give I/O errors. There's a file /tmp/flash.err that is generated by easyddup during the writing of the firmware to flash memory (/tmp/ doesn't persist after reboot however) but it's usually empty.
You could try to downgrade to one of the 10 most recent versions (cached ones you know worked) and re-upgrade to r53714 and see if it was just a peculiar thing about r53708 that you were on previously.
easyddup.sh -d -m 10
Some busybox commands are in RAM but reboot isn't so filesystem access is required. I used to have my dd-wrt in a different building and had it plugged into a basic APC PDU so if I couldn't login I could power cycle dd-wrt without physically going there.
Joined: 05 Oct 2008 Posts: 715 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Fri Oct 20, 2023 16:18 Post subject:
yoyoma2 wrote:
Some busybox commands are in RAM but reboot isn't so filesystem access is required. I used to have my dd-wrt in a different building and had it plugged into a basic APC PDU so if I couldn't login I could power cycle dd-wrt without physically going there.
I guess your APC PDU power cycle is kin to what I attempted with a smart power plug.
I noticed one can define an OFF and an ON event and these will be executed even if the plug looses its WiFi and internet connection. It turned out that not all smart plugs are created equal and the one I used at first wouldn't reconnect once WiFi is available again.
I dropped the project for a while, but changed the smart plug for a different one of the same brand but from a different batch. I threw the unreliable one out.
Sometimes my router doesn't start up properly after a power disconnect, so all in all it's too unreliable. When I am away, I am at 1500 km from here, but this location has my off-site backup and in fact runs that show, because it is on a CG LAN and I cannot get in from the other location.
Re the flashing. Yes, it flashed fine, but the reboot command had become unavailable. A show stopper. However, as to why, I have no idea. I'll wait to see if it happens again.
There are things I could do, like resetting and entering all settings again, or I could assume that this router has gone bad (?) and replace it with a newer R7800 I have.
Currently I am dabbling in ADS-B but try to not 'work' (hobby) too late, so I take my chances with the router for now. It's working although QoS is nonexistant since a recent upgrade (or the CG LAN has gone bad).
Would it be possible for easyddup to use the alternative automatic CLI flashing method that saves the file as /tmp/firmware.bin so it works without having to use the reboot command? _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
# Make sure working directory isn't on a thumbdrive partition before unmounting
cd /
# Stop Entware (~Optware) ...
# all its init scripts are located in /opt/etc/init.d including symlinks
logger -t $0 "Stop Entware"
/opt/etc/init.d/rc.unslung stop
logger -t $0 "Stop mDNS & SAMBA service"
# before unmounting USB thumbdrive partitions
service mdns stop
service samba3 stop
The right moment to repair 'dirty' partition file systems (as caused by suddenly disconnecting power) would, of course, be during startup.
However, I haven't found out how to do that without breaking dd-wrt startup.
The partitions are mounted automatically by dd-wrt itself. The execution of the startup command script is delayed by a routine written by egc, which makes the script wait for the two partitions to be mounted before continuing script execution. That is because the startup script next copies files from /jffs to /tmp/root. (I sometimes edit the files, and do that in /jffs).
The actual mounting is not controlled by the startup commands script.
I would have to unmount the partitions in the course of the startup command script before I can run e2fsck on them, but I fear doing so would totally derail the dd-wrt startup process.
It is not really satisfactory to have the router not check and repair the partitions left 'dirty' from a power cut (power button or otherwise).
I am not always present to pull the thumbdrive and do the repair on my workstation. If the router would always start up reliably despite the partition fs's being 'dirty', there wouldn't be a problem, but it doesn't. Sometimes it hangs and then it will not obey any keep alive settings intended to save the day, either.
This should be tested if the reboot is part of easyddup script(s):
Alozaros wrote:
Ive found the cure:
this will immediately reboot the system...
echo b > /proc/sysrq-trigger
Thanks for all the suggestions. If someone can get into the state where /sbin/reboot gives an I/O error, what's the output of these commands so easyddup can detect it and fallback to Alozaros' command:
ls -l /sbin/reboot
/sbin/reboot ; echo $?
The /tmp/firmware.bin method might work but seems like a bigger change given the years of testing with the current method.
Joined: 08 May 2018 Posts: 14968 Location: Texas, USA
Posted: Sun Oct 22, 2023 18:17 Post subject:
Are you asking for post-flash (write filename linux, etc.) output? I have not done CLI flash on my 3200, but I can do some reading up on the specifics if an alpha at the current head drops for it and post results. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Yes I was asking for post flash so I could use the normal reboot command if it's working and that special echo command if it's not. I hope to figure out how to detect that reboot isn't working from the script.
Hmmm come to think of it the "Restoring basic settings..." feature also wouldn't work if restore-mynvram.sh can't be accessed in this state.
Joined: 08 May 2018 Posts: 14968 Location: Texas, USA
Posted: Sun Oct 22, 2023 20:39 Post subject:
Without reading too far back, seems that the issue may be related to user shutdown scripts and not normal CLI flashing procedure, or not. I'm waiting to see an alpha drop on the private test server to investigate on my end. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Upgraded my R7800 from build 53714 to 53734 half an hour ago using easyddup.
Had to resort to the Linux Magic System to reboot:
echo b > /proc/sysrq-trigger
Rebooted using the GUI a few times after that. The Magic reboot had left one of the thumbdrive partitions 'dirty' judging from result of the e2fsck check in my shutdown command script (rsyslog).
If this is going to be the new routine, it should be helpful to precede the boot trick with:
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
for sync and unmount ...
