Updated to 6.9.0, can no longer reboot from GUI / and I suddenly am being asked for a root password

[tiny-e]

Performed the update a couple of days ago, the reboot at the update didn't complete, box unresponsive to ping.  When I went over to it and flipped the monitor on, no signal.  Hit the reset button and it booted fine.

 

Just tried to reboot the server from the GUI to verify it's still happening... it is. 

Also, when I try to ssh to the server now, I'm asked for a password.  I've never set one... (no external access).  I changed the password of the root account from the terminal prompt available in the gui and then could log in over SSH... doesn't look like that survived reboot.   Is that normal?  I don't necessarily care if there's a password required, but I didn't originally add it, and now I can't log in over ssh unless I change the password in the gui using the built-in terminal. 

Attached my anonymized diagnostics in case it's needed. 

Thanks for any help you can offer.

nimbus-diagnostics-20210309-1124.zip

[Squid]

As of 6.9 SSH access requires a password to be set for root (which will also then ask you for the password to login to the webUI).  You can set this within the Users tab

[tiny-e]

2 minutes ago, Squid said:

As of 6.9 SSH access requires a password to be set for root (which will also then ask you for the password to login to the webUI).  You can set this within the Users tab

OK -- Thanks-  Was that mentioned in the update and I missed it?

[ljm42]

5 minutes ago, tiny-e said:

OK -- Thanks-  Was that mentioned in the update and I missed it?

yep  https://wiki.unraid.net/Unraid_OS_6.9.0#SSH_Improvements

[tiny-e]

Thanks Again -- So I'm getting ready to apply the next update and got this warning -  

Quote

Current unRaid Version: 6.9.0 Upgrade unRaid Version: 6.9.1


Checking for plugin updates
OK: All plugins up to date

Checking for plugin compatibility
OK: All plugins are compatible

Checking for extra parameters on emhttp
Issue Found: emhttp command in /boot/config/go has extra parameters passed to it. Currently emhttp does not accept any extra paramters. These should be removed

 

If I look at the go file it shows me this:

root@Nimbus:~# cat /boot/config/go
#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp -p 8008  &

I think this is left over from PiHole wanting port 80 a while back.  I tried commenting the line out --and the webgui / nginx failed to start (not sure if it's related, but added the line back and it worked again... ) -- I currently access the server on port 8008.

Any ideas?

Edited March 9, 2021 by tiny-e

[ljm42]

You can set the port under Settings -> Management Access -> HTTP Port. I'm guessing you already did that several versions back.

 

After making that change, edit your go script to look like this:

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &

 

[tiny-e]

I'm good with port 80 now... no more pihole, so should I get rid of the line in the go file and set via the GUI?  Do I need to tell the GUI port 80, or will it default there?

 

(Thanks again)

 

[ljm42]

I'd say double-check that Settings -> Management Access -> HTTP Port is set to 80 (or whatever port you want), then in your go script change this line:

/usr/local/sbin/emhttp -p 8008 &

to this:

/usr/local/sbin/emhttp &

 

[tiny-e]

I'd say double-check that Settings -> Management Access -> HTTP Port is set to 80 (or whatever port you want), then in your go script change this line:

/usr/local/sbin/emhttp -p 8008 &

to this:

/usr/local/sbin/emhttp &

 

Ah- got it. So the http server doesn’t start, period, without the emhttp command. I thought this setting may have been overriding the default.

So when I nuked the whole line, no GUI.


Sent from my iPhone using Tapatalk

[tiny-e]

OK -- So that's all sorted now, but I still can't effect a reboot of any kind from the GUI (or even from the command line).    When it does boot, it looks/sounds like this.  I'm not totally up on beep counting, not even sure if these are POST code beeps or maybe something else (drive controller card)? 

 

https://www.dropbox.com/s/u9mk367qg870p1m/IMG_0630.MOV?dl=0

[ljm42]

Sorry, I'm not clear, the video looked like it booted fine? Or did you have to interact with it some way to get it to boot?

[ljm42]

It looks like other people are having trouble rebooting:

 

 

If that looks like your issue, maybe join the conversation and upload your diagnostics over there

[tiny-e]

19 hours ago, ljm42 said:

Sorry, I'm not clear, the video looked like it booted fine? Or did you have to interact with it some way to get it to boot?

That's the manual reboot after I effected the GUI reboot.  Machine was hung up before that.   Switched my boot settings to "Legacy" and that seemed to help (only tested 1 time, as the server wanted to run a parity check due to the failed reboot) -- Also updated the quite-old BIOS of the server to the latest version as Supermicro showed the update as being critical. 

 

[ljm42]

Good ideas.

 

Hmm, until you are confident that reboots work, I'd suggest stopping the array manually before you shutdown or reboot. Array status is stored on the flash, so if the array stops successfully before the system hangs then you can avoid unclean shutdowns and forced parity checks.