Sunfire V880 crashes on "reboot" command

[aixquest]

Hi,

Anybody seemed crash on Sunfire V880 after a "reboot" command. After performed command "reboot -rv" on the server, the host was not able to login. After investigated, it turned out the OS had removed some important directories like the /bin (suspected corruption within the OS). Problems were saw on multiple V880 and V440 servers.

Thanks in advance.

 

[bfitzmai]

According to the man pages for reboot, the syntax for the command you are using should be "reboot -- -rv... The -- is a delimiter that separates the reboot and boot options.

 

[aixquest]

Would that cause a problem without the delimiter? I believe I tried with this command too.

 

[bfitzmai]

I don't know if the command syntax caused the removal of files. I never liked the reboot command, most likely because in SunOS and early Solaris days, reboot didn't run a File System sync. Also, command reboot does not run the /etc/rc scripts that will shut down services gracefully.

Since you are running command reboot, I can assume you have root privileges. I personally like the command "init 6" better than reboot. Init 6 will bring the system down running the /etc/rc scripts and reboot. If you must run a reconfiguration boot, you can create a file in the root directory called "reconfigure" using command "touch reconfigure". This will cause a reconfiguration boot when system reboots.

With Solaris, if the file system doesn't know what to do with a particular inode (file), it will place the inode in a directory called "lost+found".

Upon boot up, the OS run fsck on each partition and will try to fix any file system problems... If there are problems that can not be corrected, a message to go into Single User Mode will appear and you will have to run command fsck manually on the corrupted partition to fix file system problems.

 

[aixquest]

Thanks for the info. It's a very good tip.

 

[cndcadams]

aixquest;

In my experience I have used reboot -- -r many times without any issues. The v portion is just for extended boot information(used it once, found no need for it), the r is for reconfiguration. If you are not adding any hardware that requires a reconfiguration reboot then I would not use these flags. If you are trying to reconfigure the system you could run touch /reconfigure and then do an init6. Or do a shutdown and then do boot -r.
Or if adding disks and running solaris 9 just run devfsadm -c disks to reconfigure system to recognize them.
i can not remember if Solaris 8 has devfsadm but it did have drvconfig(I have used this but heard it does not always update path_to_inst properly).
I did look into some sun issues and found problems caused by people running reboot -rv with out the delimeters.

Thanks

CA

 

[aixquest]

I have V880 server that removed /bin files after the reboot and resulted not able to login to normal session. I used "shutdown -y -i6 -g0." I really don't understand why this is happening.

 

[cndcadams]

aixquest;

this is very strange. I have loaded and tested many v880's with no problems shuting them down, installing new hardware booting them back up etc..

What OS are you loading, how are you loading them?

What are you doing to the systems that require a reboot?

Give me any information that you feel is relavent.

I can't image what is going on but will be happy to help as much as I can.

thanks

CA

 

[aixquest]

I used the V880 for test to add and remove volumes from the array and running I/O. It also has Veritas Volume Manager 4.0 application running on the machine. OS is Solaris 9. Usually, the system reboot for adding and removing volumes on the host.

uname -a:
5.9 Generic_118558-11 sun4u sparc SUNW, Sun-Fire-880
pkginfo -l VRTSvxvm:
VERITAS-4.OR_MP1_PointPatch1.4

 

[cndcadams]

aixquest;

Hmmm. Are you encapsulating the boot drive and doing any raid with it?

How long have you had your V880 running, have you used this system in the past to do testing without any issues?

Is there a chance you can load the system, don't bring the boot drive under veritas control(if you are), run some tests and try a reboot or shutdown?

If you do the above atleast we can rule out veritas as having something to do with this issue. Also I would say hardware does not have anything to do with this.

Thanks

CA