Re: [Pro6 6.2.4] Wizard stuck + no SSH + no discovery server

dunc · ‎2015-06-10

Hi all,

I've been running an Pro6 (Pro Pioneer, actually) with OS6 "forever", currently on 6.2.4, no problems in the past. Now I finally managed to put it into a state that I don't know how to recover from... :oops:

Here's the summary:

We recently had a BIG power surge which actually fried my UPS(!), hence the NAS lost power. When trying to restart, it simply hang in "booting...", doing nothing. As I have a 2nd NAS where I backup my data regularly, I was not afraid of resetting the Pro6. 😎

So I tried an "OS Reinstall" first. That got rid of the boot hang, but now the LCD display would show the known "Cannot connect to discovery server" message. However the NAS was still reachable via its usual IP (I use DHCP). While trying to access the admin panel to check the IP/DNS settings, the admin panel would constantly try to "refresh" itself, not reacting properly at all. :roll:

So I gave up on the UI, SSH was enabled anyway, hence I checked the /etc/resolv.conf and sure enough there was no DNS server in there besides 127.0.0.1 (and ::1). I added one manually for testing purposes... but the UI still would not work correctly. Hm. :?

So I thought "well, I have a backup and who knows what config and data files might have been damaged, so let's do a factory reset". And that's what I did. The reset seemed to work ok, the Ultra6 started to init FW in X-Raid2 mode as usual. And once it was done and booted... guess what: still the "Cannot connect to discovery server" message in the LCD. Fortunately, DHCP still seemed to work, I could call up the admin UI...

...and now the fun began. The admin UI obviously noticed that there is no config available (as it was a factory reset), and tried to forward me to the "setup wizard" (https://<readynas>/admin/wizard.html). But nothing happened. That page simply showed the usual readynas "splash" screen. And I was unable to cancel the wizard or skip it in any way, so I can not access any NAS config settings. :evil:

Oh well. let's check the files via SSH... heh... no SSH? Oh yes, I did a factory reset, so SSH is not running by default. :slap:

OK... let's see... faulty image in the flash maybe? To ensure the image is ok, I performed a USB flash recovery as described here (http://home.bott.ca/webserver/?p=166), I just replaced the 4.2.x image with the 6.2.4 image. No, I am not the 1st one to do that, and yes, this process is known to work. And it did. 🙂

However, the results were unchanged. After the USB recovery, and after an additional factory reset (just in case), the situation is still the same:

the LCD shows "Cannot connect to discovery server"

the admin GUI forwards to the "wizard.html" page and just sits there

SSH is not running, so I can not check the files

😞

Now... I do not give up that easy. Hence I familiarized myself with the "Tech Support" boot menu option. And yes, thanks to the description here (viewtopic.php?f=160&t=80239) I made it into telnet, was able to mount the file system so I can access the config via console now. :neener:

However: I simply don't know what to do next.

The resolv.conf still shows 127.0.0.1 only, as expected. But just changing that does not solve anything, and does obviously not survive a reboot as long as DHCP is active. Disabling DHCP and switching to a fixed IP via the GUI would be easy, but via telnet/busybox and with the readynas-specific config, I am just not sure how to do that. *If* that would solve anything at all. Or maybe I can tell frontview NOT to come up with the wizard via some file editing?

So now I officially accept defeat and humbly ask for help from the experts.

Thanks a bunch!

dunc · ‎2015-06-10

All that read my original post above: I had a brain fart, it's a Pro (6) - or rather a Pro Pioneer - not an Ultra 6. Sorry for the confusion, 1st post adjusted accordingly.

But the problem description itself is accurate. 😛

dunc · ‎2015-06-10

Babysteps...

in "Tech Support" mode, after mounting the correct drive, I edited the /etc/default/services file and set the following entries to "1"...

SSH=1
SSH_UI_ENABLE=1

...synced, unmounted, rebooted.

Now I got at least the SSH access back.

mdgm-ntgr · ‎2015-06-10

After doing a firmware update or factory reset if the web ui is not displaying correctly or not working as expected you may wish to try clearing your web browser cache (e.g. Temporary Internet Files in Internet Explorer), closing your web browser, then reopening the web admin interface.

Can you open RAIDar 6.0 and download the logs using that then send them to me (see the Sending Logs link in my sig)?

My /etc/resolv.conf looks like this:


# cat /etc/resolv.conf
# Generated by Connection Manager
nameserver 127.0.0.1
nameserver ::1

The resolv.conf is not why you got the error you did.

dunc · ‎2015-06-11

Thanks mdgm,

mdgm wrote:
[...] you may wish to try clearing your web browser cache (e.g. Temporary Internet Files in Internet Explorer), closing your web browser, then reopening the web admin interface.

Sure, I did that of course, but it had no effect. I even tried from multiple PCs. Sorry for forgetting to mention it in my initial error description.

mdgm wrote:
Can you open RAIDar 6.0 and download the logs using that then send them to me (see the Sending Logs link in my sig)?

Logs sent!

However... I was unable to download the logs via RAIDar 6.0, as the corresponding button was simply missing from the interface (click on image for full size):

So I basically continued with my "quest" of somehow getting the admin interface NOT to stay stuck in wizard.html. After a fresh factory reset, I entered "Tech Support" mode, and modified /etc/default/services as described above to get SSH running. Then I tried to analyze what makes the admin GUI forward to the wizard.html page. After a bit of tinkering, I saw that some JavaScript files in the dashboard query "getFirstLaunchState" methods. And if that "First_Launch" state is true, they forward to wizard.html.

OK, so I (temporarily) wanted to disable that forward. Hence I looked for the "getFirstLaunchState" implementations, and finally figured that I had to alter two /frontview/dashboard JS files:

browse_1.0.2.840.js

before: getFirstLaunchState:function(){return dpv.gp(this.xstate,"First_Launch")=="1"}
after:  getFirstLaunchState:function(){return dpv.gp(this.xstate,"First_Launch")=="0"}

frontview_1.0.2.840.js

before: getFirstLaunchState:function(){return _1.gp(this.xstate,"First_Launch")=="1"}
after:  getFirstLaunchState:function(){return _1.gp(this.xstate,"First_Launch")=="0"}

With these changes in place, the main admin GUI page basically ignored the fact that the setup wizard did not run yet, and I finally could access the admin GUI.

However: as I am fully aware that this is NOT the permanent solution, I only used the GUI to download the log files. I will not continue tinkering around with any further configurations on my own, and I will of course revert my changes as soon as necessary.

Standing by for logfile feedback now! 🙂

dunc · ‎2015-06-12

dunc wrote:
mdgm wrote:
Can you open RAIDar 6.0 and download the logs using that then send them to me (see the Sending Logs link in my sig)?

Logs sent!

Just a quick bump... I hope the logs came through OK?

FYI, the subject line was:
Attn: mdgm - [Pro6] wizard stuck + no SSH + no discovery server

Thanks!

mdgm-ntgr · ‎2015-06-15

Just had a look at your logs.

Looks like the EEPROM data for your NAS has become corrupted.

Check your PM inbox.

dunc · ‎2015-06-16

Thanks a lot, PM sent!

mdgm-ntgr · ‎2015-06-17

O.K.

There were two issues both of which are now fixed:

1. The EEPROM data was corrupt.
2. As LACP was configured on the switch but no longer on the NAS the NAS showed in RAIDar but a connection to the web admin page could not be made.

dunc · ‎2015-06-17

mdgm wrote:
1. The EEPROM data was corrupt.
2. As LACP was configured on the switch but no longer on the NAS the NAS showed in RAIDar but a connection to the web admin page could not be made.

Indeed, and thanks a bunch for your help!

And regarding the LCAP: sorry for that, I had the NAS hooked via a single NIC to a non-LCAP port for the whole time, just for the last session I wanted to have everything back in place "the usual way" --- and promptly forgot about the LCAP switch setup... just have to mention this to myself to keep my self-esteem up.
:slap:

(so for others who read this thread: LCAP was not part of the original problem, it was only a brainfart by me that happened during the last diagnosis session)

Thanks again!
😄