Grub ignores TIMEOUT options on /etc/default/grub

You have misspelled "countdown" as "countdowm". Try fixing that?

Fixed the typo, then ran update-grub and rebooted, but the issue persists.
(BTW, shouldn't I have been warned by grub about the type?)

On Tue, Jan 28, 2014 at 6:48 PM, Colin Watson <email address hidden>wrote:

> You have misspelled "countdown" as "countdowm". Try fixing that?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1273764
>
> Title:
> Grub-pc ignores the options on /etc/default/grub
>
> Status in “grub2” package in Ubuntu:
> New
>
> Bug description:
> On trusty-proposed:
>
> I have attached my `/etc/default/grub` file. After modifying it, I
> make sure to run update-grub, but the changes won't take effect on
> next reboot: the menu is shown with a timeout of 10 seconds.
>
> grub-pc:
> Installed: 2.02~beta2-5
> Candidate: 2.02~beta2-5
> Version table:
> *** 2.02~beta2-5 0
> 500 http://do.archive.ubuntu.com/ubuntu/ trusty/main i386
> Packages
> 100 /var/lib/dpkg/status
>
> ProblemType: Bug
> DistroRelease: Ubuntu 14.04
> Package: grub-pc 2.02~beta2-5
> ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
> Uname: Linux 3.13.0-5-generic i686
> ApportVersion: 2.13.2-0ubuntu2
> Architecture: i386
> CurrentDesktop: Unity
> Date: Tue Jan 28 12:37:46 2014
> InstallationDate: Installed on 2014-01-14 (14 days ago)
> InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha i386 (20140113)
> SourcePackage: grub2
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1273764/+subscriptions
>

For the sake of completeness, I attached the corrected file.

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
# GRUB_HIDDEN_TIMEOUT=0 deprecated
# GRUB_HIDDEN_TIMEOUT_QUIET=true deprecated
GRUB_TIMEOUT=1
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"

Also used style=countdown and GRUB-TIMEOUT=0 etc..

menu still showing up and GRUB_TIMEOUT_STYLE=hidden or countdown not working
changes to GRUB-TIMEOUT=0 etc.. have no effect

I noticed that os-prober overrides the timeout value, I also found this workaround:

https://gist.github.com/LeahCim/9332432

I've done a fresh install of trusty (amd64) without proposed enabled, and the issue persists. I noticed the GRUB_TIMEOUT* is been overridden on 30_os-prober. I've updated the bug description.

Status changed to 'Confirmed' because the bug affects multiple users.

This issue affects also me. Fresh install of 14.04.
Proposed workaround resolve the issue in my system.

This appears to be by design, to prevent people setting it to 0 and not knowing that you can hit shift (or escape if that fails) to get the menu back.

On a Mac and possibly other EFI based systems this is undesirable behaviour as I can already choose what OS to boot from the firmware, in my case by holding ALT, so all this does is add more delays and flickering screens to the boot process.

I love Ubuntu for its tendency to "just work" (much like the Mac's native OS) but I do not need to be babysat, and really must object to cases like this where "nanny scripts" actively fight against me making customisations to my system.

I recommend adding a comment to /etc/default/grub warning users of the 'dangers' of setting it to 0, instead of fighting them. Those who want to tinker with things and not understand what they're doing will always find ways to hose their systems, but most of them are grown adults (if not they are poorly supervised kids) and can take responsibility for their own actions and even learn something from their mistakes. All this does is cause confusion for those who do know what they're doing and work with GRUB in other distros.

I've determined the cause of this bug in my case: I have a small /boot partition outside of the root filesystem (btrfs).
Turns out that that boot partition was not added to the /etc/fstab, so all the kernel upgrading and upgrade-grub operations I was doing were in fact affecting the /boot directory inside the root (btrfs) filesystem, not the actual boop (ext2) partition.

Added the partition to /etc/fstab, cleaned the /boot mountpoint and now all is good in the world. :-)

+1 for Cloudane's post #12 - I am using Ubuntu because I want to be able to take my own decisions, and do not want to be "protected" by features somebody else thinks are good for me. Otherwise I could just use Windows instead....

Workaround worked for me, thanks for this!

+1 for fixing this. The current situation is broken, since timeout settings in /etc/default/grub do not work as expected.

Same thing here. Fresh install on v14.04.1 LTS (amd64) and there is no way to make the changes in /etc/default/grub to work.

I'm not seeing any references to any kind of TIMEOUT in os-prober. Can you be more specific?

@psusi, Please look in /etc/grub.d/30_os-prober. In particular, the last line reads:

> adjust_timeout

And the definition of `adjust_timeout` is:

> adjust_timeout () {
> if [ "$quick_boot" = 1 ] && [ "x${found_other_os}" != "x" ]; then
> cat << EOF
> set timeout_style=menu
> if [ "\${timeout}" = 0 ]; then
> set timeout=10
> fi
> EOF
> fi
> }

As you can see the `timeout` variable is set/reset to 10 (seconds).

That is very odd.. this "timeout" variable appears to be local to that script and not used for anything. 00_header uses GRUB_TIMEOUT.

gah! nevermind... all the darn HERE documents these scripts use keep confusing my eyes... that part is being echoed to the grub cfg.

Yep... that code seems to be ubuntu specific and comes from quick_boot.patch.

A workaround without editing any scripts or binaries:
GRUB_TIMEOUT=0.1

Works for me.

GRUB_TIMEOUT=0.1 gives me Peppermint Linux 7 unless I hit <Esc> when booting to go to Windows 7 again, which is what I very much want until 2020.

Thanks.

"
Kirils Solovjovs (linux-kirils) wrote on 2015-11-02: #22

A workaround without editing any scripts or binaries:
GRUB_TIMEOUT=0.1

Works for me.
"

This bug is also present in Ubuntu 16.04 Xenial LTS (if to be straight - I use Linux Mint 18.1, based on it).

Can we correct it and backport to 16.04 LTS?
This bug is absent in current Debian unstable.

Thank you.

os-proper breaks logic, set by /etc/default/grub in case, when GRUB_TIMEOUT=0, because he adds to /boot/grub/grub.cfg such lines: < http://pastebin.com/Py2VD3Qt >

Full text of my /boot/grub/grub.cfg: http://pastebin.com/QzcCfV2q

Workaround in #8 worked for me.

Ubuntu Gnome 16.04 LTS - UEFI boot

Workaround in #8 works for me too
Work-around created 3 years ago! Wow... I can't believe this simple fix is not fixed...

I'm dual-booting Windows 10 and Kubuntu 16.10 and I had the issue with the grub2 config file having a 10 second timeout then defaulting to 30 seconds upon boot.

I tried the workaround in post #8 which then caused my boot menu to be completely hidden. I then removed both files described in the workaround and removed the GRUB_HIDDEN_TIMEOUT value and ran sudo update-grub which seemed to have fixed my problem.
I have also had hibernation enabled for some time as noted in the GRUB_CMDLINE_LINUX_DEFAULT "resume=UUID=xxxxx" (swap partition) argument. I find hibernation extremely useful with laptops (I've removed the UUID for security reasons)

# 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=
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 resume=UUID=xxxxx"
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"

After 7 years of not using Linux, I just installed Ubuntu 16.04.03 and it looks like grub2 completely ignores TIME_OUT settings, so I can't hide the grub menu. Any plans to fix this? I remember this used to work in the past. Grub had no problems with TIME_OUT=0 but now it does. I already spent 4 hours searching over the Internet how to fix this.

Grub2 is completely ignoring time out. I have no recordfail set and timeout doesn't happen in a fresh 16.04.03: useless if installed on a remote box.

After reading quick_boot.patch, I think the environment variable $quick_boot (set by default) was added in order to give the user an option to force timeout to be 0. However, the test seems reversed to me:

  if [ "$quick_boot" = 1 ] && [ "x${found_other_os}" != "x" ]; then
    cat << EOF
set timeout_style=menu
if [ "\${timeout}" = 0 ]; then
  set timeout=10
fi
EOF
  fi

meaning timeout is increased to 10 when $quick_boot is set, which is not what I'll call "quick_boot". I suggest changing it to "$quick_boot" = 0.

And there should be a way to modify this variable somewhere else, since any change to the file itself will get overridden in an upgrade.

The attachment "quick_boot_fix.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

This bug has affected my laptop with Linux Mint 19.1 since the last update of grub2 a few days ago.
Fix #8 & #22 did not work for me.
I changed 2 lines in /etc/grub.d/00_header from:

  set timeout=${GRUB_RECORDFAIL_TIMEOUT:-30}

To:

  set timeout=${GRUB_RECORDFAIL_TIMEOUT:-1}

Now grub timeout is set to 1 second, this will probably change on the next upgrade but works for now.

This has happened for me too in 18.10. Randy's fix above worked for me too.

I'm affected by this bug too (on an Asus UX330U).
#33 works for me.

Exactly the same issue. It starts since I did upgrade from 16.04.5 to 16.04.6. I attached the related config files: /etc/default/grub and /boot/grub/grub.cfg. My case is definitely not like #13: I have /boot entry in /etc/fstab and I double checked that when I do `update-grub' /boot is mounted, has free space and populated accordingly:

$ cat /etc/fstab| grep /boot
# /boot was on /dev/sda7 during installation
UUID=XXXX /boot ext3 defaults 0 2

$ df -h | grep /boot
/dev/sda7 2.0G 125M 1.7G 7% /boot

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial

I also tried #33 workaround: doesn't work for me.

P.S. The most inconvenient thing for me in this is that I have a bluetooth keyboard as my primary keyboard, so now, since I did this upgrade, I have to keep another one physically attached keyboard each time when I want to boot.

(missed configs)

The workaround in Comment #33 also worked for me (and update-grub afterwards - Ivan, did you did it?)

My workaorund is setting GRUB_RECORDFAIL_TIMEOUT in /etc/default/grub to the timeout I need.

This is a very strange behavior and probably not intended!

This is the logic behind it:
# in /etc/grub.d/00_header there's a function that calls grub-probe and if the result is "lvm" (my case) it ends setting the variable recordfail_broken=1 (as if there would have been a problem while booting)
# because of this later on, and if booting in efi, the variable GRUB_RECORDFAIL_TIMEOUT is being used to set the timeout and not GRUB_TIMEOUT (as I would expect).

This is not the intended behavior as described in https://help.ubuntu.com/community/Grub2

So, if you are booting from a lvm volume, GRUB_TIMEOUT won't be used.

What is the intention of this? why lvm => recordfail_broken=1 which implies every boot is "as if last one didn't complete properly"... makes little sense to me though look intentionally made that way.

@estanislao-gonzalez-r

GRUB doesn't support writes to LVM so it always treats previous boot as failed. Sad but true.

I'm surprised this bug is very old..and still ongoing. Ubuntu focal.

Unlike @estanislao-gonzalez-r, I'm not using lvm but still have the same problem.

Meanwhile GRUB_RECORDFAIL_TIMEOUT=1 does the trick..

This bug also affects me. #31 seems to fix this.
I don't understand why the $quick_boot variable exists if it is set to be forever =1 at the start of the script anyway? I could not find any sourced scripts that would change it.

Jumping on comment earlier about 30_os-prober I as root edited /etc/grub.d/30_os-prober line #37 to set timeout=0
Hope this doesn't break anything. So far it worked, though I haven't tried a positive value with this hack.
Just did an edit to /etc/default/grub increasing timeout GRUB_TIMEOUT=2, reboot and it worked.
Why was this little trap put here? Sets timeout of zero to ten.

I also seems to be affected by this. I don't know though if adding GRUB_RECORDFAIL_TIMEOUT=1 or 0 to /etc/default/grub will fix it. Every now and then (not always) grub menu shows up when booting. Which it shouldn't do, I haven't any other os installed on the computer. No boot failure has happened neither so I couldn't think of grub menu appearing because of that. I'm using Ubuntu stock 20.04. Is there some problem with grub which could lead to this behavior? And what is the best way to fix grub menu randomly appearing at boot up?

A week ago I upgraded to a new grub2 on Ubuntu 20.04 and thought it was fixed. It wasn't. Every now and then grub menu is showing on boot which it shouldn.t. Why? My /etc/default/grub is this:

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Haven't changed anything, I did a fresh install of 20.04, when I was upgrading from 18.04. No other os on computer. Thanks in advance for investigating this.

Im having the opposite sort of problem. On Ubuntu 20.04 with grub2 2.04 - I want the menu to display but only for GRUB_TIMEOUT seconds. No matter what settings I use, it always displays indefinitely and never counts down.

If I set GRUB_TIMEOUT_STYLE="countdown", it will do the countdown and never shows the menu as expected, but we want the menu AND the menu timeout countdown.

Setting GRUB_RECORDFAIL_TIMEOUT makes no difference.

My system does boot from an LVM RAID boot partition, but I have several other identical systems configured exactly the same way that do not have this problem. It seems rather random.

This bug is still present in 22.10. I wasn't using OS_Prober anyway, so I added GRUB_DISABLE_OS_PROBER=true to /etc/defaults/grub

If Ubuntu wants to keep this behavior to protect users accidentally hiding their boot menus, perhaps they could add a line to the output of update-grub, indicating what OS_Prober has done?

As it is now, this "feature" is not documented, and the behavior is unexpected if you are trying to hide the Grub menu, for instance on a single-boot system.