Grub ignores TIMEOUT options on /etc/default/grub

Bug #1273764 reported by Edwin Pujols
260
This bug affects 58 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Triaged
Medium
Unassigned
Vivid
Triaged
Medium
Unassigned

Bug Description

This is a fresh install of trusty (amd64), without proposed (since this grub package has reached the regular repos).

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 even when GRUB_TIMEOUT_STYLE is set to countdown.

After reading grub.cfg and googling a bit I found this:

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

(30_os-prober is overriding the values of GRUB_TIMEOUT and GRUB_TIMEOUT_STYLE.)

Description: Ubuntu Trusty Tahr (development branch)
Release: 14.04

grub-pc:
  Installed: 2.02~beta2-7
  Candidate: 2.02~beta2-7
  Version table:
 *** 2.02~beta2-7 0
        500 http://do.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

Revision history for this message
Edwin Pujols (edwinpm5) wrote :
description: updated
Revision history for this message
Colin Watson (cjwatson) wrote :

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

Revision history for this message
Edwin Pujols (edwinpm5) wrote : Re: [Bug 1273764] Re: Grub-pc ignores the options on /etc/default/grub

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
>

Revision history for this message
Edwin Pujols (edwinpm5) wrote :

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

Revision history for this message
H. van de Kolk (rikolk-f) wrote :

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

Revision history for this message
Edwin Pujols (edwinpm5) wrote :

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

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

Edwin Pujols (edwinpm5)
summary: - Grub-pc ignores the options on /etc/default/grub
+ Grub ignores options on /etc/default/grub
Revision history for this message
Edwin Pujols (edwinpm5) wrote : Re: Grub ignores options on /etc/default/grub

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.

description: updated
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Koalakoker (koalakoker) wrote :

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

Revision history for this message
Cloudane (cloudane) wrote :

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.

Revision history for this message
Gilberto Gaudêncio (quazatron) wrote :

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. :-)

Revision history for this message
Liz W (no-name) wrote :

+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!

Revision history for this message
Øyvind Stegard (oyvindstegard) wrote :

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

Revision history for this message
alfa (alfa42) wrote :

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.

Revision history for this message
Phillip Susi (psusi) wrote :

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

Changed in grub2 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Edwin Pujols (edwinpm5) wrote :

@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).

Edwin Pujols (edwinpm5)
Changed in grub2 (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Phillip Susi (psusi) wrote :

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

Revision history for this message
Phillip Susi (psusi) wrote :

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

Revision history for this message
Phillip Susi (psusi) wrote :

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

Changed in grub2 (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
tags: added: vivid
tags: added: rls-v-incoming
tags: removed: rls-v-incoming
tags: added: rls-w-incoming
summary: - Grub ignores options on /etc/default/grub
+ Grub ignores TIMEOUT options on /etc/default/grub
tags: added: rls-w-notfixng
removed: rls-w-incoming
Revision history for this message
Kirils Solovjovs (linux-kirils) wrote :

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

Works for me.

Revision history for this message
Charles L. Rodgers (sonnyrodgers) wrote :

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

Revision history for this message
Niora (naumovvladislav) wrote :

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.

Revision history for this message
Niora (naumovvladislav) wrote :

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

Revision history for this message
Justo (jtorres1825) wrote :

Workaround in #8 worked for me.

Ubuntu Gnome 16.04 LTS - UEFI boot

Revision history for this message
Xebozone (markdavidoff) wrote :

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

Revision history for this message
M Griffin (mgriffin3390) wrote :

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"

Revision history for this message
Eugene (egnk) wrote :

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.

Revision history for this message
Paul (pcp1976) wrote :

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.

Revision history for this message
Tony Beta Lambda (tony-xty) wrote :

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.

dino99 (9d9)
tags: added: artful bionic
removed: vivid
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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.]

tags: added: patch
Revision history for this message
Randy Usegnu (usegnu) wrote :

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.

Revision history for this message
NJ (njspam+ubuntulaunchpad) wrote :

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

Revision history for this message
friskyRingo (mrcrag) wrote :

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

Revision history for this message
Ivan Zorin (iaz) wrote :

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.

Revision history for this message
Ivan Zorin (iaz) wrote :

(missed configs)

Revision history for this message
angus73 (angus73) wrote :

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

Revision history for this message
Estanislao (estanislao-gonzalez-r) wrote :

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.

Revision history for this message
Ivan Frederiks (idfred) wrote :

@estanislao-gonzalez-r

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

Esokrates (esokrarkose)
tags: added: focal
Revision history for this message
Chrescht (sekateur) wrote :

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

Chrescht (sekateur)
tags: added: eoan
Revision history for this message
Simon (fischer-sim) wrote :

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.

Revision history for this message
daryl_haataja (daryl-haataja) wrote :

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.

Revision history for this message
pelm (pelle-ekh) wrote :

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?

Revision history for this message
pelm (pelle-ekh) wrote :

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.

Revision history for this message
Wyllys Ingersoll (wyllys66) wrote :

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.

Revision history for this message
sem (semitones) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.