Dynamically updating HM tab ttitle


 
The reason I used the dl image is because I can never remember the .gz image URL... Could you maybe put the .gz URL on the dl page to use for in place update?
 
Steve_M said:
Pi Zero W.
Click to expand...
Iiiiis it overclocked? I just attempted it on my Zero W with a 28,992KB .img file and it takes 1m18s, with about 15 of that being the file upload itself. The uhttpd server times out in 60 seconds so I get the Bad Gateway message before it can complete. The only way I can upload an image is to use a .gz version on both the Zero W (1000MHz) and the B (700MHz).

Took me all morning but I figured out the issue with the long delay. It was driving me nuts last night when I was trying to test some firmwares and I kept having to gzip them to test because it would time out. Still need to get it all cleaned up and into our proper source tree though.
 
Nope.

I just did it again, over a WAN connection :)

25 seconds to upload the file and get to the next "proceed with upgrade" page and 65 seconds after that I was able to ssh into it.

The "System - Flashing..." / "Waiting for changes to be applied..." screen never exits for me, I just open another browser tab and start using it.
 
I'm sorry to keep beating this poor horse, but we're talking about a full 29MB .img file uploaded through the webui right, not the 9MB compressed image? My Zero does the 9MB image in about 25 seconds. I wonder what the difference is between our systems.

Ohhh wait! Are you using /cgi-bin/luci/ or just /luci/? Or does your have an alias line for /luci/ to /cgi-bin/luci? Because I could see either of those bypassing this bug, because it doesn't use the in-process LUA CGI-- it shells out and calls LUA externally.
 
Yep, 29mb file. Not sure what the path is, whatever the defaults are. I've done nothing on my end to make this work. It just works. Maybe the nginx proxy in front of the HM is helping it? I should try directly to the IP of the HM.
 
Oh maybe! That's baffling though, it's been a thorn in my side forever that I couldn't just directly upload an uncompressed image to the flashops page. I didn't know there was a Canadian Secret to being able to make it work. In any instance I pushed a new snapshot that fixes the slowness with a patch until I can get it fixed upstream. It might take a while because guess what, the OpenWrt and LEDE people have settled their differences and re-merged last week-- thus fragmenting all their split communities again. I gotta poke around until I find the right person. It also means I've gotta rebase all the code again BACK to the OpenWrt project once their code merges settle. That shouldn't be too much of an issue because it looks like it is mostly going the LEDE way.
 
haha I really did feel sorry for the LUA library's block class. We're pumping a 29MB file through it and it builds a tower of strings, collapsing it each time the top two strings are larger than the one below it (or it reaches 10 stacks)
Code: 
Read 1KB x10, creating a new string for each read. Put each on the stack.
Compress the 10 strings down to 1x 10KB string
Read 1KB x9 creating new strings
Compress the 9 strings down to 1x 9KB string
- Read / repeat until you have a stack of strings 1KB, 2KB, 3KB, 4KB, ... 10KB
Compress the 1K and 2KB together to make it 3KB, 3KB, 4KB, ... 10KB
Read 1K again
Collapse the entire stack to 10+9+8+7+6+5+4+3+3+1KB = 56KB
- Read / repeat this whole process until by the end you're merging piles of strings that are several megabytes each
And don't forget you've also allocated 29,000x 1KB strings along the way! It uses hundreds of megs of RAM on the Pi to put the file back together again.

EDIT: Also this!
xG7HYch.png
 
Last edited:
So, it turns out that my nginx proxy is somehow helping to smooth things out.

When I connect directly to the IP of Pi Zero it gives me:
Code: 
Bad Gateway
The process did not produce any response

When going through my nginx proxy, I get:
Code: 
Flash Firmware - Verify
The flash image was uploaded. Below is the checksum and file size listed, compare them with the original file to ensure data integrity.
Click "Proceed" below to start the flash procedure.


Checksum
MD5: 728e867b6ac7a6a486ffa8582e41a946
SHA256: 5b2217f31a68ce96a35188cb2d8f53c99dbfbaa9653741627a0156e8e2187ff8
Size: 28.25 MB
Configuration files will be kept.
 
You must log in or register to reply here.

 

Back
Top