Bitcoin Forum
December 10, 2016, 05:09:47 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Ubuntu 11.04 Natty Help with Grub boot menu on resume from power loss  (Read 5975 times)
MiningBuddy
Moderator
Legendary
*
Offline Offline

Activity: 1058


฿itcoin ฿itcoin ฿itcoin


View Profile
January 11, 2012, 08:58:40 PM
 #1

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
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"

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481346587
Hero Member
*
Offline Offline

Posts: 1481346587

View Profile Personal Message (Offline)

Ignore
1481346587
Reply with quote  #2

1481346587
Report to moderator
1481346587
Hero Member
*
Offline Offline

Posts: 1481346587

View Profile Personal Message (Offline)

Ignore
1481346587
Reply with quote  #2

1481346587
Report to moderator
flatronw
Jr. Member
*
Offline Offline

Activity: 50


View Profile
June 11, 2012, 09:53:55 AM
 #2



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
exahash
Sr. Member
****
Offline Offline

Activity: 276



View Profile
August 18, 2012, 03:27:14 AM
 #3

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.



MiningBuddy
Moderator
Legendary
*
Offline Offline

Activity: 1058


฿itcoin ฿itcoin ฿itcoin


View Profile
August 18, 2012, 05:30:29 PM
 #4

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!

d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
August 19, 2012, 02:15:44 AM
 #5

Easiest fix:  Uninterruptable Power Supply

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
MiningBuddy
Moderator
Legendary
*
Offline Offline

Activity: 1058


฿itcoin ฿itcoin ฿itcoin


View Profile
August 19, 2012, 04:33:39 AM
 #6

Easiest fix:  Uninterruptable Power Supply
Sure it may be the easiest, but now there is massive costs with UPS.

flatronw
Jr. Member
*
Offline Offline

Activity: 50


View Profile
September 07, 2012, 11:25:00 AM
 #7

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 Sir, you are a Gentleman


exahash
Sr. Member
****
Offline Offline

Activity: 276



View Profile
September 09, 2012, 06:24:12 PM
 #8

Easiest fix:  Uninterruptable Power Supply
Sure it may be the easiest, but now there is massive costs with UPS.
They can be got for the same price as an old laptop and a new battery Wink

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.
gbl08ma
Sr. Member
****
Offline Offline

Activity: 306


Donations: http://tny.im/nx


View Profile WWW
September 09, 2012, 06:34:39 PM
 #9

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.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!