can a machine running linuxbios be remotely reset/reboot from crashed/frozen state over a network connection?
thanks
ryan
On Sun, Feb 25, 2007 at 07:05:56PM -0500, Ryan Moszynski wrote:
can a machine running linuxbios be remotely reset/reboot from crashed/frozen state over a network connection?
No.
This needs dedicated hardware in the machine and LinuxBIOS is "just" software. Also, LinuxBIOS is done and over with in the system after it has started the payload.
//Peter
can a machine running linuxbios be remotely reset/reboot from crashed/frozen state over a network connection?
This needs dedicated hardware in the machine and LinuxBIOS is "just" software. Also, LinuxBIOS is done and over with in the system after it has started the payload.
If your (server-class) machine has a networked IPMI BMC then you can do remote reset with it just as well if the machine runs LinuxBIOS as it would with the vendor BIOS. Well it *should* work, who knows :-)
Segher
On Mon, Feb 26, 2007 at 02:59:06PM +0100, Segher Boessenkool wrote:
can a machine running linuxbios be remotely reset/reboot from crashed/frozen state over a network connection?
This needs dedicated hardware in the machine and LinuxBIOS is "just" software. Also, LinuxBIOS is done and over with in the system after it has started the payload.
If your (server-class) machine has a networked IPMI BMC then you can do remote reset with it just as well if the machine runs LinuxBIOS as it would with the vendor BIOS. Well it *should* work, who knows :-)
Yeah, quite. While I *have* got one IPMI card working with LinuxBIOS, in my experience most IPMI implementations are prime examples of why proprietary software is bad. I have yet to encounter an IPMI card that is stable and adheres to the spec. The situation is improving somewhat with IPMI 2.0, but vendors are still pushing out extremely buggy products, with even buggier proprietary IPMI client software. The free software IPMItool is a much more reliable piece of client software, but it lacks support for some IPMI boards/features, and it can't stop the IPMI boards from being so buggy that they crash themselves...
My current feeling is that with LinuxBIOS, you get reliable remote console on the serial port (as opposed to proprietary BIOSes, where console-to-serial is often slow as molassis, and almost never actually reliable). So; combining the reliable LinuxBIOS serial console with a device that turns the serial connection into a network accessible one (for instance, another GNU/Linux box with a serial port), and another device that can power-toggle your machine is a reliable remote control solution.
The alternative is a more advanced BMC - stuff like Dell's DRAC4, and HP's ILO. But these, too, are totally proprietary and often buggy. Try, for instance, to access an HP ILO with ECN enabled on your machine - it won't work. And the console redirection they provide is most often a graphical console, which makes things slow. Also, console redirection requires help of browser applets that are often unreliable. I have used them successfully though to power-toggle machines - that part seems more or less reliable.
Thanks, Ward.
If your (server-class) machine has a networked IPMI BMC then you can do remote reset with it just as well if the machine runs LinuxBIOS as it would with the vendor BIOS. Well it *should* work, who knows :-)
Yeah, quite. While I *have* got one IPMI card working with LinuxBIOS, in my experience most IPMI implementations are prime examples of why proprietary software is bad.
Yeah, don't construe my comments as a recommendation to use IPMI. I was just pointing how remote reset typically works with current machines.
I have yet to encounter an IPMI card that is stable and adheres to the spec. The situation is improving somewhat with IPMI 2.0, but vendors are still pushing out extremely buggy products, with even buggier proprietary IPMI client software.
And there's no indication this situation will improve any time soon.
And the console redirection they provide is most often a graphical console, which makes things slow. Also, console redirection requires help of browser applets that are often unreliable. I have used them successfully though to power-toggle machines - that part seems more or less reliable.
(Graphical) console redirection isn't a good solution for non-mswindows machines, it's way too fragile. For anything sane good solutions exist already (serial lines, telnet, that kind of thing). Not much consumer-class stuff has support for these things built in though.
Segher
On 2/26/07, Segher Boessenkool segher@kernel.crashing.org wrote:
If your (server-class) machine has a networked IPMI BMC then you can do remote reset with it just as well if the machine runs LinuxBIOS as it would with the vendor BIOS. Well it *should* work, who knows :-)
yep, it certainly ought to work, ... It will fail if: 1) IPMI cpu shares an ethernet port with the main system 2) remote controller has timed out the ARP entry for the system you are trying to reset
because the IPMI CPU does not respond to ARP.
So, the IPMI CPU -- which controls power and reset -- depends on the host CPU -- the one running Linux, which may be hung -- to operate. Unbelievable.
You're much better off depending on a watchdog timer than IPMI. IPMI has not worked out. From reading the standard, I would have to guess the folks who wrote it are not really OS people -- but I'm guessing.
ron
If your (server-class) machine has a networked IPMI BMC then you can do remote reset with it just as well if the machine runs LinuxBIOS as it would with the vendor BIOS. Well it *should* work, who knows :-)
yep, it certainly ought to work, ... It will fail if:
- IPMI cpu shares an ethernet port with the main system
That is supposed to work actually, using a VLAN and a direct connection between BMC and NIC.
- remote controller has timed out the ARP entry for the system you
are trying to reset
because the IPMI CPU does not respond to ARP.
For remote management you typically use MAC addresses, not IPv4, so it *should* work. It's all bloody fragile though.
You're much better off depending on a watchdog timer than IPMI. IPMI has not worked out. From reading the standard, I would have to guess the folks who wrote it are not really OS people -- but I'm guessing.
Well certainly not open source OS people ;-)
</rant>
Segher
On Monday 26 February 2007 00:05, Ryan Moszynski wrote:
can a machine running linuxbios be remotely reset/reboot from crashed/frozen state over a network connection?
If you want an ultra-cheap solution to this and you have a NIC with external Wakeup-on-LAN (WoL) connector (such as the old Intel EtherExpress Pro), you can connect the WoL signal (via a transistor and a few resistors) to the mobo reset switch.
You send the WoL ethernet frame and the machine reboots, independent of any BIOS or software state.
Its probably not such a good idea for production environments, but in my experience it does work very nicely. The cost (per machine) is probably ~£1 +10--20 minutes of time building the unit and install it. In fact, it was cheaper to replace the NICs (for ones with external WoL connectors) that to use external signalling device.
The electronics should be safe: I believe a properly made Reset-on-LAN will not damage a machine; but, needless to say, you do this at your own risk!
I'm putting together a page together describing this in more details. I can post the details here, if people want.
HTH,
Paul.
On 27.02.2007 12:00, Paul Millar wrote:
The electronics should be safe: I believe a properly made Reset-on-LAN will not damage a machine; but, needless to say, you do this at your own risk!
I'm putting together a page together describing this in more details. I can post the details here, if people want.
Yes please.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Paul Millar -
Peter Stuge -
ron minnich -
Ryan Moszynski -
Segher Boessenkool -
Ward Vandewege