Detecting if the "F1" prompt will halt a reboot

[Derek Schwartz]

It's really bad news to have servers hang at an F1 prompt when doing a massive patch deployment.

I'd like to create a simple command-line utility that would return an error level if the F1 prompt is set to hang the server. Then, I could easily create deployment scripts that could safely skip those servers (of course, logging the failures to a text file for later follow-up) and not cause high-severity tickets and panic! I didn't see anything reported by WMI to check the flag. Can I programmatically access the Compaq monitoring agents via some kind of API?

I had to ditch the simplistic idea of scanning the event logs for failures. Our servers archive their logs every night and start clean each day. We're not allowed to use Insight Manager, so that's also not an option.

I can't be the only one who's needed something like this!

Thanks,
Derek

[Edward Sliman]

I believe you can turn a setting on in the bios to not stop on an error, but it requires a rev upgrade to latest firmware. We have had to do this with several older servers(1850,6400, etc) and I believe the 5000 was also one of them. Hope it helps.

[David Claypool]

Why are you "not allowed" to use Insight Manager?

[Derek Schwartz]

Well, the F1 hangup is good for things that could possibly cause data loss if booting continues, so disabling it probably wouldn't be a good thing in the long run. However, it seems a bit overkill for something simple such as a bad power supply or bad drive.

As for not being able to use Insight Manager, I think our management is really pushing Tivoli for monitoring and wants us to use it as the ONLY monitoring tool since it automatically generates service tickets to the correct support groups on the mainframe ticketing system. This way, they actively monitor all operating systems (Win/Unix/Linux) with a single tool, no matter what brand of hardware it's running on.

When people attempt to remotely reboot servers in a multi-site environment, it's just counterproductive to have to travel to each site (or open trouble tickets for physically unreachable sites) just because one or two servers get stuck during reboot. That's why I was looking for something that could not ignore, but temporarily skip a server in a batch reboot procedure. It would let the immediate work be completed without needless business impact.