Re: configuring remote headless servers

2016-09-01 Thread Manuel Bouyer
On Thu, Sep 01, 2016 at 06:02:33PM +0100, Steve Blinkhorn wrote: > But for now my original question still stands: what about using > /fastboot? it means your system won't run fsck at boot and mount them read/write despite being marked unclean. This can cause a panic/reboot loop. -- Manuel

Re: configuring remote headless servers

2016-09-01 Thread Steve Blinkhorn
I'm grateful for the sharing of wisdom and experience.I have worked out that the servers most likely do have IPMI (they are Fujitsu Siens Primergy RX100 GSO1), but given their age I suspect it will prove to be an early version. I saw something in the BIOS setup that looked related, but given

Re: configuring remote headless servers

2016-08-31 Thread Lyndon Nerenberg
> But this led me to wonder how I would cope if, for instance, a server > came up in single-user mode requiring an fsck. The standard way to deal with this in DC deployments is to use IPMI: 1) Redirect the BIOS console to the IPMI virtual console. 2) Redirect the boot loader prompts to the IPMI

Re: configuring remote headless servers

2016-08-31 Thread Swift Griggs
On Wed, 31 Aug 2016, Steve Blinkhorn wrote: > It took three days for an engineer with sufficiently developed skills to > become available: He solved the problem by switching the server on. Having found no good way to truly address issues like this without some control of my own, I don't deal

Re: configuring remote headless servers

2016-08-31 Thread Michael van Elst
st...@prd.co.uk (Steve Blinkhorn) writes: >But this led me to wonder how I would cope if, for instance, a server >came up in single-user mode requiring an fsck. This is handled by using server hardware that has an out-of-band management console, i.e. BMC, ILO, DRAC, iRMC, or just a serial

Re: configuring remote headless servers

2016-08-31 Thread David Brownlee
On 31 August 2016 at 11:34, Steve Blinkhorn wrote: > Following on from the recent saga of upgrading from 2.0 to 7.0 which > assiduous readers may recall, the servers were re-installed in their > racks in the data centre. All was well with one of them but the > other apparently