Even UPS connected to "regular" computers (i.e. not mining) will stop providing power if there's an outage for a long period of time, now imagine on a computer with lots of GPUs (as explained above). They're not the perfect solution and so making sure the computer wakes up on its own and starts mining again is important.
I found the solution exahash posted to be useful, not only for mining (I don't mine) but for another situations where a computer should always start up after a power outage if left alone.
Topic: Ubuntu 11.04 Natty Help with Grub boot menu on resume from power loss (Read 6193 times)
September 09, 2012, 01:34:39 PM
September 09, 2012, 01:24:12 PM
Easiest fix: Uninterruptable Power Supply
Sure it may be the easiest, but now there is massive costs with UPS.
A UPS is fine for a regular computer, but have your tried putting a 4+ GPU rig on a "regular" ups? (that is, one which plugs into a normal 15- or 20-amp circuit)
The power draw of the cards while mining will either trip the overlimit circuit in the ups or drain the batteries so fast it's not worth it.
I tried a few different 1500VA ups's when I started mining and with 2 cards they didn't run on battery for even two minutes.
If you're running fpgas it might be different.
September 07, 2012, 06:25:00 AM
Sorry for the necropost... I was running into this issue and found a way to fix it.
I edited /etc/grub.d/00_header - look for the line a few pages down with timeout = -1 and change the -1 to something positive (I use 5), save the file, then run update-grub2. That line tells grub to show the menu for whatever amount of time after an unexpected error. -1 means show the menu till someone provides input. My rigs are unattended, so I want them to boot no matter what.
The fsck after that is another story. I have no work around for a machine that's stuck waiting for input at the fsck. But you won't always have disk errors, so most of the time it will boot and resume mining if you've told it to do so.
I edited /etc/grub.d/00_header - look for the line a few pages down with timeout = -1 and change the -1 to something positive (I use 5), save the file, then run update-grub2. That line tells grub to show the menu for whatever amount of time after an unexpected error. -1 means show the menu till someone provides input. My rigs are unattended, so I want them to boot no matter what.
The fsck after that is another story. I have no work around for a machine that's stuck waiting for input at the fsck. But you won't always have disk errors, so most of the time it will boot and resume mining if you've told it to do so.
Thank you Sir, you are a Gentleman
August 18, 2012, 11:33:39 PM
Easiest fix: Uninterruptable Power Supply
Sure it may be the easiest, but now there is massive costs with UPS. 
August 18, 2012, 09:15:44 PM
Easiest fix: Uninterruptable Power Supply
August 18, 2012, 12:30:29 PM
Sorry for the necropost... I was running into this issue and found a way to fix it.
I edited /etc/grub.d/00_header - look for the line a few pages down with timeout = -1 and change the -1 to something positive (I use 5), save the file, then run update-grub2. That line tells grub to show the menu for whatever amount of time after an unexpected error. -1 means show the menu till someone provides input. My rigs are unattended, so I want them to boot no matter what.
The fsck after that is another story. I have no work around for a machine that's stuck waiting for input at the fsck. But you won't always have disk errors, so most of the time it will boot and resume mining if you've told it to do so.
Thank you for providing a solution, very much appreciated! I edited /etc/grub.d/00_header - look for the line a few pages down with timeout = -1 and change the -1 to something positive (I use 5), save the file, then run update-grub2. That line tells grub to show the menu for whatever amount of time after an unexpected error. -1 means show the menu till someone provides input. My rigs are unattended, so I want them to boot no matter what.
The fsck after that is another story. I have no work around for a machine that's stuck waiting for input at the fsck. But you won't always have disk errors, so most of the time it will boot and resume mining if you've told it to do so.
August 17, 2012, 10:27:14 PM
Sorry for the necropost... I was running into this issue and found a way to fix it.
I edited /etc/grub.d/00_header - look for the line a few pages down with timeout = -1 and change the -1 to something positive (I use 5), save the file, then run update-grub2. That line tells grub to show the menu for whatever amount of time after an unexpected error. -1 means show the menu till someone provides input. My rigs are unattended, so I want them to boot no matter what.
The fsck after that is another story. I have no work around for a machine that's stuck waiting for input at the fsck. But you won't always have disk errors, so most of the time it will boot and resume mining if you've told it to do so.
I edited /etc/grub.d/00_header - look for the line a few pages down with timeout = -1 and change the -1 to something positive (I use 5), save the file, then run update-grub2. That line tells grub to show the menu for whatever amount of time after an unexpected error. -1 means show the menu till someone provides input. My rigs are unattended, so I want them to boot no matter what.
The fsck after that is another story. I have no work around for a machine that's stuck waiting for input at the fsck. But you won't always have disk errors, so most of the time it will boot and resume mining if you've told it to do so.
June 11, 2012, 04:53:55 AM
Same problem here. I notice that if I lose AC power cleanly and it resumes cleanly then the rig will auto-start with out problems. However you get a spike after the powerloss and the rig partially reboots and then loses power again. That is when I get the "hang up" that you describe.
And yes I would like to know a solution for the problem
January 11, 2012, 03:58:40 PM
Hi chaps, wondering if someone could help me out a little here.
Basically if/when my headless rigs looses AC power and is resumed at a later time sometimes the rig will get stuck on the Grub boot loader menu with the first item selected, I have to attach a keyboard and press Enter to resume boot.
To my understanding my grub config file below is correct and it should boot the first item in the list after 10 seconds?
Any ideas on how I can disable this menu appearing after an AC power loss and just always boot the default?
/etc/default/grub
Basically if/when my headless rigs looses AC power and is resumed at a later time sometimes the rig will get stuck on the Grub boot loader menu with the first item selected, I have to attach a keyboard and press Enter to resume boot.
To my understanding my grub config file below is correct and it should boot the first item in the list after 10 seconds?
Any ideas on how I can disable this menu appearing after an AC power loss and just always boot the default?
/etc/default/grub
Code:
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
Jump to: