I recently updated the firmware on my Stora, which caused issues (Stora would freeze up after being on for 10-15 minutes). So I did a hard reset but got the following error on setup:
Error message: at /var/www/admin/update.pm line 346
I've since tried everything to stop this error, hard resets, re-flashing, etc. Still get the same error every time. Any ideas?
Update server is down, Stora is checking for updates during registration. Because MySQL is down, unknown reply from server is causing setup script to fail. I will try to fix that, but it will take a while, as my second unit died yesterday, and I do not want to gamble with my data on healthy one.
Actually host is up, but MySQL either crashed or was stopped. Based on previous experience with recovery server, I do not keep high hopes. If I manage to get replacement board on time, I will remove that check. For now I am looking for mainboard.
Yesterday I managed to find motherboard, but it will arrive in something like 2-3 weeks to me. If you need your unit urgently setup TeamViewer on your PC or do a port forwarding to Stora SSH and web port and send me PM with details. I can fix it temporary to continue with registration and when I got mainboard will do permanent fix. At the moment temporary fix is confirmed to be working, while other is a just at early stage idea and should be tested before official public release.
While "same here" replies aren't necessarily helpful, I'm encountering the same issue and want to subscribe to the thread (created an account just so I can subscribe).
My scenario:
a few months ago (possibly in 2017?) I noticed the stora acting odd. It would lock up, being unresponsive, but the lights would still be on. So I reset the device (red button at the back) and it seemed to be ok for a few days. Then it kept doing the same thing.
I reset it again and when it came back to life it had a new behaviour: it would constantly reboot. It would also randomly power off...and then randomly power up again. The intervals between power off/on was completely random, and despite manually powering it off, it actually powered _itself_ back on!!! That one wasn't confidence inspiring 😕
In any event, I'm glad to see that it's possibly just due to the update server being offline. Actually, someone mentioned that the update server is online but the update service isnt' working?
If the stora works 'ok' when it can't connect to the update server, should I just add an entry to the hosts file that effectively points the update server ip/hostname to an unreachable address? Would that let the stora get past the update server issue?
If so: what's the address/hostname?
I did like my stora, and it had a good run. It just seems a shame to toss it simply because it's not being supported any more.
I just spazzed out and fixed the update issue. I "deparsed" the perl module for updates:
$ perl -MO=Deparse update.pm > ~/update.pl
Which then let me see what it was doing. I tried throwing a quick 'return' in it, but it turns out this gets called in 'setup_update.pm'.
So I "deparsed" that module:
$ perl -MO=Deparse setup_update.pm
Then I realized what it was doing and basically deleted the whole thing.
If you copy/paste the below into a new file (after renaming the existing one) it will bypass the setup issue.
-bash-3.2$ cat setup_update.pm
package setup_update;
sub process {
return 'success';
}
sub display {
my $vars = shift @_;
my $template = shift @_;
$$vars{'name'} = $name;
die 'Template error: ' . $template->error . "\n" unless $template->process('setup_update.html', $vars);
}
'???';
I don't know if this will fix the random rebooting issue though. That one is the most troubling for me. 😕
Actually, here's a script that'll do the aforementioned update:
#!/bin/bash
# This is the contents of the updated script:
NEW_SCRIPT=$(cat << EOF
package setup_update;
sub process {
return 'success';
}
sub display {
my $vars = shift @_;
my $template = shift @_;
$$vars{'name'} = $name;
die 'Template error: ' . $template->error . "\n" unless $template->process('setup_update.html', $vars);
}
'???';
EOF
)
# Make a backup of the existing file just in case:
cp /var/www/admin/setup_update.pm /var/www/admin/setup_update.pm.bak
# Dump the new script into the old location. Note: this doesn't have to be compiled/turned into bytecode.
# Plain-text perl scripts can be relablled .pm and used as modules.
echo "$NEW_SCRIPT" > /var/www/admin/setup_update.pm
2) create a new file and copy/paste the above code into it. If you follow the tutorial on the lenny site, he shows how to install nano. If you have nano installed, just run 'nano meow.sh' and then copy/paste the code into it.
3) make sure the file is executable by running 'chmod +x meow.sh'
4) run the script with sudo: sudo ./meow.sh
5) navigate the browser to the stora web page and it'll get past the blocker.
Warning: do the above at your own risk, yadda yadda yadda. It's fairly harmless as it makes a backup of the existing file before stomping it.
I should also point out: if anyone is brave enough (read: has lots of time on their hands) then you could easily rip through the perl code and update it to do whatever you like. I would really like to know if the update server is what was causing my reboot issue--if it was, and someone knows where that code lives, please post up. If it's actually the website doing the updates (I don't see how it could be?) then this may solve the problem inadvertantly.
Update script is called in several places as far as I know. There is a startup script which is caling it on every reboot, setup wizard during activation and maybe web management interface. I am not sure at all that just termination with "success"/code 0 will do the job. Last time before my testing unit died I've found that parts of firmware are checking for exact reply, which is generated by server. Because either MySQL crashed on update server or someone just stopped it, seems that reply "unable to connect to local socket in /var/lib/mysql/mysql.sock" is unexpected and it's causing scripts ti die with error.
About your random reboots - this might be caused by several things. Try these one by one (order is from "easy/cheap" --> "difficult/expensive"):
- disable/remove port forwarding for unit in your router. Reason - you might be hacking attempt target. Excessive hacking attempts might crash your unit. You still will be able to perform basic tasks via mystora.com
- Check SMART for your disk(s). There is a smartmontools installed inside the firmware.
- Open up unit on the back, there is a CR2032 battery. Remove it, press and keep pressed both Power + Reset buttons for 2-3 minutes. This will reset internal CMOS memory. Replace battery with new one - it's cheap and won't harm anything even if it does not help.
- Replace power adapter (DC 12V/5A). Old capacitors in adapter could not cope with electric noise suppression anymore, or adapter just can't keep enough amperage to keep Stora up in situations of high power usage due it's age. In "idle" mode it will work, but in case of miniDLNA transcoding, reindexing files on hard drives it will just got overloaded and will shut off itself. Or unit will crash due problems with power supply .
- Setup logs to be written on hard drive(s). Most of them are disabled. Or setup remote syslog server and dump it there. It will be complicated task and should be considered as last hope.
My second unit began to power on itself when power supply is connected, then began to reboot itself instead of power down, and on final week ago mainboard died - no serial TTL connection, no LED lights - just spining fan and total silence. I am awaiting replacement motherboard to arrive, so I can continue with importing last update, removing updates check and probably kicking off whole "mystora" functionality as it will become problematic in some time.
@Gitsov Cheers, thank you for the tips on the reboots and mystery power-on/offs. Now that you mention it, I can mentally recap what happened:
1) I filled one of my two drives entirely. Oops. This caused a few issues (no swap space, no logging space, etc) so I ended up doing a factory reset because I couldn't get into the Stora for long enough before it would panic.
2) After resetting the Stora, I cleaned the drives up, and figured "meh--good enough". What I _didn't_ do, was turn off uPnP, and re-configure all the settings on the Stora that I've since forgotten about. uPnP is the easiest way to get hacked (oops)--thanks for pointing out the firewall tip as well. I'll clean that up and ensure nothing erroneous is happening.
3) The Stora started acting odd shortly after the above. I took it to mean it was on its last legs and neglected it for a few months.
4) I needed the Stora so I tried to fix it, thought I fixed it, but a day or so later and it resumed its spastic reboot/ghost-power-on behaviour 😕
5) I unplugged it.
6) My family mentioned they needed to get files off of it yesterday, so I tried to reset it and found this forum post after encountering the update server error.
So that all fits with your theories. One of which may be the power unit/adapter: it was sitting in a relatively warm area. It was plugged into a UPS, so I would have thought it'd be ok, but it definitely suffered a few power outages regardless.
As for the code: the script was already returning the status--I basically just gutted the script so all that remained was one of the statements from the original:
return 'success';
I didn't get creative, I just reduced it to the lowest common denominator--the success path. It seems to have worked for the past 18 hours, but that's not exactly saying much. It's on a different internal network, however, and so the uPnP attack vector is thwarted due to the router configuration in this network. I guess I'll see if the problem persists after moving it back to the network it was in previously.
Again, thanks @Gitsov--this was great help and I appreciate the tips! Good luck with your mainboard replacement--definitely not a nice problem to encounter. 😕 If you end up digging into the perl code more let me know. Perl's not my daily language, but I'm comfortable enough with it that I can get around so I could possibly pitch in if you end up hacking away at it.
@JimFromCanada I still suspect power adapter plus maybe other ongoing issues.
Check SMART for disks, look for "Spin retry count", "ATA CRC errors", Power on retract count, Reallocation event count - excessive values on that counters might suggest problems with disk, but if they are on both drives with similar values, probably it's power supply. UPS is fine, but it can't save capacitors from heat inside adapter's case - there is no ventilation inside (it should be nearly hermetic, for safety requirements) so capacitors slowly dying due their age and excessive heat inside. So I would start with port forwarding removal and smartctl check. If portforwarding does not solve the problem, I would borrow/buy new adapter. If that does not help, next step is resetting CMOS via battery. Bad point is that all above is requiring time for tests. Keep me updated what you did - I am curious what's the cause.
About update script ... I would probably implement it in recovery or write some bash script to do it, but first need to apply update on clean uregistered firmware, apply your change and test it. Sadly I need mainboard for that, otherwise I am risking to spend again 82 hours of uploading everything and possible data loss, as it happened last time when I deliberately wiped some files and bricked unit....
@JimFromCanada can you provide a more detailed guide of the script? I have nano installed but the different commands you list always end up in an error for me.
One-week-later update: the modification seems to be holding quite well. The stora hasn’t randomly rebooted or crashed, and has held up well with typical-to-moderate streaming from the stora to my boxee box.
@Gitsov (@JimFromCanada) thanks for replies, info & offer of help. My level of understanding is that I've heard of SSH, Perl and a few other mentions but never actually used much more than the odd sudo, I'm afraid (apart from M$ BASIC before they did away with line numbers ☺).
After I posted (and just before going away, so apologies for delay) I discovered that I could access MyLibrary and FamilyLibrary and those files are now downloaded from the Stora. I have no idea whether that's because it accepted my [admin] username/password before the sign-in error or because it's anyway the same combination on my PC.
However, the MyLibrary of another (non-admin) member of the household remains inaccessible and she's not very happy... So that's what I need help with now, if anyone has any idea/s, please?
@Gitsov, the coffee & cake is still on offer ☺ but with regard to the motherboard replacement, do you mean the Stora motherboard? I'm asking because this unit will be unused once the currently-inaccessible files are downloaded.
I have a mainboard, but with problematic NAND chip. Replacement is pending (waiting for 512MB NAND and physical replacement). After 73 hours from now I will finish with migration of files from Stora to my new NAS (homebrew) and will deal with firmware on my retired unit. That's the news around me.
- You will need to create that "second" user to access files which belongs to it.
- To finish setup:
** I am assuming that you are at step with updates error ****
Open SSH, get root privilege. You should know how or how to Connect to stora via SSH. AS ROOT COPY/PASTE THIS COMMAND and run it:
echo "4" > /var/lib/admin-util/setup-page
Open in browser Stora IP address, contunue setup with remaining steps. NEVER check for updates from web interface - results are unpredictable. This is temporary and very dirty trick.
Summary with all steps required to get activated unit, from factory defaulted:
1. Open in browser IP address of stora
2. Type your product key and unit name
3. Type desired username, display name for user (optional) and password for user (twice)
4. Wait for updates failure (Error 346), don't close setup page.
5. Conect on SSH, get root privileges (there is a so much results on Google how to do it)
6. Type or copy paste command below and hit enter:
echo "4" > /var/lib/admin-util/setup-page
7. Refresh Stora setup page, it should display next step (asking for notification e-mail address I think).
8. Finish setup, login to Stora with newly created user and MAKE SURE THAT YOU NEVER CHECK FOR UPDATES!
9. Enjoy and wait for me to release firmware with stripped off update checks and pre-applied last update.
Just some progress update. I've managed to trick update mechanism to return that no new updates available. Both from web, startup scripts and setup wizard. Method is different than provided previously. Previous method did not fixed check from web interface.
