[Patch] Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.

Confirming this on Ubuntu 14.04 dev with grub-pc 2.00-21 even with a completely new generated /etc/default/grub.

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

This also recently started showing on Precise too.

Options GRUB_HIDDEN_TIMEOUT and GRUB_HIDDEN_TIMEOUT_QUIET are deprecated in grub. Use

info -f grub -n 'Simple configuration'

and then you read in there:

`GRUB_HIDDEN_TIMEOUT'
     Wait this many seconds before displaying the menu. If <ESC> is
     pressed during that time, display the menu and wait for input
     according to `GRUB_TIMEOUT'. If a hotkey associated with a menu
     entry is pressed, boot the associated menu entry immediately. If
     the timeout expires before either of these happens, display the
     menu for the number of seconds specified in `GRUB_TIMEOUT' before
     booting the default entry.

     If you set `GRUB_HIDDEN_TIMEOUT', you should also set
     `GRUB_TIMEOUT=0' so that the menu is not displayed at all unless
     <ESC> is pressed.

     This option is unset by default, and is deprecated in favour of
     the less confusing `GRUB_TIMEOUT_STYLE=countdown' or
     `GRUB_TIMEOUT_STYLE=hidden'.

`GRUB_HIDDEN_TIMEOUT_QUIET'
     In conjunction with `GRUB_HIDDEN_TIMEOUT', set this to `true' to
     suppress the verbose countdown while waiting for a key to be
     pressed before displaying the menu.

     This option is unset by default, and is deprecated in favour of
     the less confusing `GRUB_TIMEOUT_STYLE=countdown'.

A debootstrap of trusty created an /etc/default/grub with

GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10

which resulted in the warning mentioned, but also caused grub to not automatically boot the default menuentry after 10 seconds. It just hung around forever waiting for a manual selection. Especially not good for headless servers.

At the time of testing, my grub version was 2.02~beta2-6

Sorry, ignore my last comment, that looks like an unrelated issue that went away by coincidence.

The grub-pc package generates the initial /etc/default/grub file based on /usr/share/grub/default/grub , which currently includes a GRUB_HIDDEN_TIMEOUT=0 line.

There is logic in the .postinst script to comment out that line if the grub-pc/hidden_timeout debconf value is set to False, but as far as I can see the only way for that to happen is if one is upgrading from a pre-version-2 version of grub and the /boot/grub/menu.list file contains the word "hiddenmenu", or if the line is already commented out (e.g. it has been done manually beforehand). (Doing a "dpkg-reconfigure grub-pc" does not prompt for that item.)

Given that GRUB_HIDDEN_TIMEOUT is now deprecated, maybe the postinst script should attempt to convert a setting for that variable into a GRUB_TIMEOUT_STYLE setting....

In any case, it seems the /usr/share/grub/default/grub file should be edited to reflect the currently recommended settings.

(Some background info about this warning message and GRUB_HIDDEN_TIMEOUT's deprecation can be found in the following threads:
  http://lists.gnu.org/archive/html/grub-devel/2013-11/msg00388.html
  http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00122.html
)

It looks like the GRUB_HIDDEN_TIMEOUT line in the /usr/share/grub/default/grub file comes from the setting at about line 60 of the debian/rules file for the grub2 source package (
  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/grub2/trusty/view/head:/debian/rules
) :

ifeq (yes,$(shell dpkg-vendor --derives-from Ubuntu && echo yes))
DEFAULT_CMDLINE := quiet splash
DEFAULT_TIMEOUT := 10
DEFAULT_HIDDEN_TIMEOUT := 0

followed by
ifneq (,$(DEFAULT_HIDDEN_TIMEOUT))
 perl -pi -e 's/^GRUB_TIMEOUT=.*/GRUB_HIDDEN_TIMEOUT=0\nGRUB_HIDDEN_TIMEOUT_QUIET=true\n$$&/' \
  debian/grub2-common/usr/share/grub/default/grub
at about line 367.

sudo update-grub
Generating grub.cfg ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-3.11.0-19-generic
Found initrd image: /boot/initrd.img-3.11.0-19-generic
Found linux image: /boot/vmlinuz-3.11.0-15-generic
Found initrd image: /boot/initrd.img-3.11.0-15-generic
Found memtest86+ image: /boot/memtest86+.bin
done

sudo gedit /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=countdown
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.modeset=1"
GRUB_CMDLINE_LINUX=""

sudo update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.11.0-19-generic
Found initrd image: /boot/initrd.img-3.11.0-19-generic
Found linux image: /boot/vmlinuz-3.11.0-15-generic
Found initrd image: /boot/initrd.img-3.11.0-15-generic
Found memtest86+ image: /boot/memtest86+.bin
done

OK

I don't have a build environment were I can actually test it, but here's an attempt to update the debian/rules file so that (under Ubuntu) it generates a /usr/share/grub/default/grub file that uses "GRUB_TIMEOUT_STYLE=hidden" instead of a GRUB_HIDDEN_TIMEOUT= line.

(Note that grub-pc.config and grub-pc.postinst would also need to be updated to reflect this change.)

The attachment "debian/rules patch to generate default/grub file without "GRUB_HIDDEN_TIMEOUT=" line" 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.]

Just to add, this bug is affecting Ubuntu 12.04 LTS (x64). It is basically making it impossible for me to lower the GRUB countdown value from 10 seconds to 5;

damir@damir-macbook:~$ sudo gedit /etc/default/grub
damir@damir-macbook:~$ sudo update-grub
Generating grub.cfg ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-3.5.0-48-generic
Found initrd image: /boot/initrd.img-3.5.0-48-generic
Found memtest86+ image: /boot/memtest86+.bin
Found Mac OS X on /dev/sda2
Found Windows 7 (loader) on /dev/sda4
done

damir@damir-macbook:~$ uname -a
Linux damir-macbook 3.5.0-48-generic #72~precise1-Ubuntu SMP Tue Mar 11 20:09:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

You can manually edit the grub.cfg file. It is not for the faint of heart... But, here goes...

sudo -i
<enter password>
cd / boot/grub
nano grub.cfg
Ctrl-W
timeout <enter>
edit set timeout=-1
to be set timeout=10
Ctrl-X (yes)

everytime you do a grub update, you need to edit that file :)

Hope that it helps.

Regards,

Phill.

Thanks for the response Phill but I already have found an easier workaround :) If others want to try it;

I have commented out the GRUB_HIDDEN* fields like this;

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
#GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5

Now I don't get that warning when updating GRUB and my countdown timer was changed to 5s from 10s. I have no idea why those 2 are not commented out by default to avoid this.....

hmm...

root@build:/boot/grub# grep -r GRUB_HIDDEN *
root@build:/boot/grub#

No sign of GRUB_HIDDEN ?

On Mon, Apr 28, 2014 at 19:11:59 -0000, Phill Whiteside wrote:
> hmm...
>
> root@build:/boot/grub# grep -r GRUB_HIDDEN *
> root@build:/boot/grub#
>
> No sign of GRUB_HIDDEN ?

The GRUB_HIDDEN... variables are found in /etc/default/grub .

       Nathan

thanks... there are times when I hate when a build relies on an /etc entry when it is so blooming simple to correct it.... but, hey such thoughts have gotten me into problems in the past... I'll just sav this is "idiots decided not to keep grub updated" department.... It will certainly not be the first time :) (Just dig up Dave Stan for the truth on that) :D

Some time ago I have made a bug report on upstream that GRUB_TIMEOUT set to a non-zero value does still work in some cases even if GRUB_HIDDEN_TIMEOUT is set: https://savannah.gnu.org/bugs/index.php?41918

Probably it is releated with this bug report.

Did:
update-grub
Got:
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Now can only boot using recovery mode.

At the time of writing this, all updates, using "Software Updater" are applied, and problem still exists.
Linux vivid 3.19.0-12-generic #12-Ubuntu SMP Fri Apr 3 04:02:54 UTC 2015 i686 i686 i686 GNU/Linux
Description: Ubuntu Vivid Vervet (development branch)

I still have this error too

Is it possible to just comment or remove these lines??? Shouldn't be a big deal to script a find/replace or find/delete as once it is fixed, the script will no longer do anything.

Try it. You will need to chroot in from LiveCD to undo the change though (if the system fails to boot)

Yes that is possible. Comment out that specific line and it will get ignored and your boot won't be affected at all (you won't notice any difference except for no more error message).

If you search for my comment on Launchpad, I copy/pasted my file after I edited it. And I've been using it like that for months since, so grub* package updates didn't overwrite my changes either interestingly enough....

Damir

> Date: Sun, 10 May 2015 05:04:37 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 1258597] Re: Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
>
> I still have this error too
>
> Is it possible to just comment or remove these lines??? Shouldn't be a
> big deal to script a find/replace or find/delete as once it is fixed,
> the script will no longer do anything.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1258597
>
> Title:
> Warning: Setting GRUB_TIMEOUT to a non-zero value when
> GRUB_HIDDEN_TIMEOUT is set is no longer supported.
>
> Status in grub2 package in Ubuntu:
> Triaged
> Status in grub2 source package in Trusty:
> Triaged
>
> Bug description:
> When running update-grub I am getting the following message:
>
> Warning: Setting GRUB_TIMEOUT to a non-zero value when
> GRUB_HIDDEN_TIMEOUT is set is no longer supported.
>
> $ sudo update-grub
> Generowanie grub.cfg...
> Uwaga: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
> Znaleziono obraz Linuksa: /boot/vmlinuz-3.12.0-6-generic
> Znaleziono obraz initrd: /boot/initrd.img-3.12.0-6-generic
> Found memtest86+ image: /boot/memtest86+.elf
> gotowe
>
> ProblemType: Bug
> DistroRelease: Ubuntu 14.04
> Package: grub2 (not installed)
> ProcVersionSignature: Ubuntu 3.12.0-6.14-generic 3.12.3
> Uname: Linux 3.12.0-6-generic x86_64
> ApportVersion: 2.12.7-0ubuntu1
> Architecture: amd64
> CurrentDesktop: GNOME
> Date: Fri Dec 6 18:49:28 2013
> InstallationDate: Installed on 2013-10-15 (51 days ago)
> InstallationMedia: Ubuntu-GNOME 13.10 "Saucy Salamander" - Release amd64 (20131015)
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=pl_PL.UTF-8
> SHELL=/bin/bash
> SourcePackage: grub2
> UpgradeStatus: Upgraded to trusty on 2013-11-05 (31 days ago)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1258597/+subscriptions

Hi folks
  The settings for /etc/default/grub to get the same behaviour as the old version are:

GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=2
GRUB_TIMEOUT_STYLE=hidden

best

    M

Sorry
GRUB_TIMEOUT=5

  M

Same problem in ubuntu 15.10

I'm getting it on Gnome Ubuntu 15.10 x64 4.2.0-21-generic

And here on Ubuntu 15.10 x64 4.2.0-23-generic

Yes, 15.10 is also affected. Will this ever be fixed?!
A bug with long beard indeed.

How can this take so much time? The problem is very simple: you have included grub settings that grub does not support anymore. All you need to do is to update the template for grub settings to include only supported settings. No more than that.

I agree with Aimo, since this seems to be such a simple bug to fix, it doesn't make sense that this hasn't been added to the current LTS 16.04 - it was reported around 3 years ago! Is this something that has been pulled from Debian, if so should we be reporting it to them?

I have this BUG and it has appeared spontaneously. I have never had it before with this distro.
Have tried a couple of suggestions found in comments above:

:~$ GRUB_DEFAULT=0
:~$ #GRUB_HIDDEN_TIMEOUT=0
:~$ #GRUB_HIDDEN_TIMEOUT_QUIET=true
:~$ GRUB_TIMEOUT=5
:~$ sudo update-grub
[sudo] password for saparonia:
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.4.0-53-generic
Found initrd image: /boot/initrd.img-4.4.0-53-generic
Found linux image: /boot/vmlinuz-3.19.0-77-generic
Found initrd image: /boot/initrd.img-3.19.0-77-generic
Found linux image: /boot/vmlinuz-3.19.0-73-generic
Found initrd image: /boot/initrd.img-3.19.0-73-generic
Found linux image: /boot/vmlinuz-3.19.0-26-generic
Found initrd image: /boot/initrd.img-3.19.0-26-generic
done

:~$ GRUB_HIDDEN_TIMEOUT=0
:~$ GRUB_HIDDEN_TIMEOUT_QUIET=true
:~$ GRUB_TIMEOUT=5
:~$ GRUB_TIMEOUT_STYLE=hidden
:~$ sudo update-grub
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.4.0-53-generic
Found initrd image: /boot/initrd.img-4.4.0-53-generic
Found linux image: /boot/vmlinuz-3.19.0-77-generic
Found initrd image: /boot/initrd.img-3.19.0-77-generic
Found linux image: /boot/vmlinuz-3.19.0-73-generic
Found initrd image: /boot/initrd.img-3.19.0-73-generic
Found linux image: /boot/vmlinuz-3.19.0-26-generic
Found initrd image: /boot/initrd.img-3.19.0-26-generic
done

elementary OS 0.3.2 Freya (64-bit)
Built on Ubuntu 14.04

Noticed timeout was at =30 and changed it to =5

made no difference

:~# cd /boot/grub
:/boot/grub# nano grub.cfg
:/boot/grub#
:/boot/grub# sudo update-grub
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.

I will probably wipe this and do a clean reinstall grr

Sapa Holliday: you need to edit file called /etc/default/grub, not /boot/grub/grub.cfg. The latter is *automatically* generated from the former when you run update-grub. Any changes you make to grub.cfg will be silently overridden any time update-grub is executed (by you or by dpkg).

Still happening in a fresh 16.04 installation.

This is still present in 17.10.

Isn't a permanent fix for this very old bug straightforward?...

In the file:
    /etc/default/grub

Comment out or remove:
    #GRUB_HIDDEN_TIMEOUT=0
    #GRUB_HIDDEN_TIMEOUT_QUIET=true

Add:
    GRUB_TIMEOUT_STYLE=hidden

Please let me know if I am mistaken about the ease of fixing this?

Patch for /usr/share/grub/default/grub

I've tried to reproduce this issue, unsuccessfully.

I remember being affect by it in the past, however. Could someone please confirm:

- That it's still an issue on artful (17.10).
- What the current version of grub2 they using is, with the output of "apt-cache policy grub2; apt-cache policy grub2-common"
- Please share the contents of /etc/default/grub and /etc/default/grub.d/* (in a pastebin ideally, such as pastebin.ubuntu.com)

On my machine running artful (grub2-common 2.02~beta3-4ubuntu7), running update-grub yields:

$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.13.0-19-generic
Found initrd image: /boot/initrd.img-4.13.0-19-generic
Found linux image: /boot/vmlinuz-4.13.0-17-generic
Found initrd image: /boot/initrd.img-4.13.0-17-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
done

This looks like the desirable behavior. I would like to understand how my machines are different here (I tried on 16.04, 17.04 and 17.10 on GCE as well).

I'm on artful (17.10) and it happens to me. It was a new installation and I haven't edited any grub files...

grub version:
grub2:
  Installed: (none)
  Candidate: 2.02~beta3-4ubuntu7
  Version table:
     2.02~beta3-4ubuntu7 500
        500 http://it-mirrors.evowise.com/ubuntu artful/universe amd64 Packages
grub2-common:
  Installed: 2.02~beta3-4ubuntu7
  Candidate: 2.02~beta3-4ubuntu7
  Version table:
 *** 2.02~beta3-4ubuntu7 500
        500 http://it-mirrors.evowise.com/ubuntu artful/main amd64 Packages
        100 /var/lib/dpkg/status

/etc/default/grub contents: http://pastebin.ubuntu.com/26176041/
There is no /etc/default/grub.d directory in my system

sudo update-grub
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.13.0-19-generic
Found initrd image: /boot/initrd.img-4.13.0-19-generic
Found linux image: /boot/vmlinuz-4.13.0-17-generic
Found initrd image: /boot/initrd.img-4.13.0-17-generic
Found memtest86+ image: /boot/memtest86+.elf
Found memtest86+ image: /boot/memtest86+.bin
done

This also occurs on a newly installed bionic (unreleased) with nightly installer images.

I fixed the problem, but every time I do an update (and grub is updated), it asks me if it can install the "package maintainer's version". If I say yes, then this warning occurs.

What actually has to be done for something like this to be fixed?

On Wed, 2018-04-04 at 22:36 +0000, Stephen Buergler wrote:
> What actually has to be done for something like this to be fixed?

That's easy. Since this is a Ubuntu-only bug, someone on the Ubuntu
grub team needs to just remove the line of code that inserts the long-
unsupported arg in the grub config, and its magically fixed. Why that
take so many years is the real mystery.

@John Mellor! made my day.

It worked on Bionic:

$ sudo update-grub
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.15.0-29-generic
Found initrd image: /boot/initrd.img-4.15.0-29-generic
Found linux image: /boot/vmlinuz-4.15.0-28-generic
Found initrd image: /boot/initrd.img-4.15.0-28-generic
Adding boot menu entry for EFI firmware configuration
done

$ sudo apt-get install grub-efi-amd64-bin
Reading package lists... Done
...
The following packages will be upgraded:
   grub-common (2.02-2ubuntu8.1 => 2.02-2ubuntu8.2)
   grub-efi-amd64-bin (2.02-2ubuntu8.1 => 2.02-2ubuntu8.2)
   grub-efi-amd64-signed (1.93.2+2.02-2ubuntu8.1 => 1.93.3+2.02-2ubuntu8.2)
   grub-pc (2.02-2ubuntu8.1 => 2.02-2ubuntu8.2)
   grub-pc-bin (2.02-2ubuntu8.1 => 2.02-2ubuntu8.2)
   grub2-common (2.02-2ubuntu8.1 => 2.02-2ubuntu8.2)
6 upgraded, 0 newly installed, 0 to remove and 26 not upgraded.
Need to get 4,290 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
...
Replacing config file /etc/default/grub with new version
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-29-generic
Found initrd image: /boot/initrd.img-4.15.0-29-generic
Found linux image: /boot/vmlinuz-4.15.0-28-generic
Found initrd image: /boot/initrd.img-4.15.0-28-generic
Adding boot menu entry for EFI firmware configuration
done
Setting up grub-efi-amd64-signed (1.93.3+2.02-2ubuntu8.2) ...
Installing for x86_64-efi platform.
Installation finished. No error reported.

Installed a clean bionic install, made sure grub2 binaries are at version 2.02-2ubuntu8.1, running `sudo update-grub` resulted in printing out the Warning: message. Then upgraded all grub2 binaries to 2.02-2ubuntu8.2 from bionic-proposed, re-ran the command and confirmed no message is visible.

This bug was fixed in the package grub2 - 2.02-2ubuntu8.2

---------------
grub2 (2.02-2ubuntu8.2) bionic; urgency=medium

  * debian/rules: replace GRUB_HIDDEN_* variables with the more concise and
    less confusing GRUB_TIMEOUT_STYLE=hidden. (LP: #1258597)
  * debian/control: update Vcs links.

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 17 Jul 2018 14:13:52 -0400

The verification of the Stable Release Update for grub2 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package grub2-signed - 1.93.3

---------------
grub2-signed (1.93.3) bionic; urgency=medium

  * Rebuild against grub2 2.02-2ubuntu8.2. (LP: #1258597)

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 17 Jul 2018 14:31:57 -0400

This bug was fixed in the package grub2 - 2.02-2ubuntu13

---------------
grub2 (2.02-2ubuntu13) cosmic; urgency=medium

  * debian/patches/tests_update_for_new_qemu.patch: update qemu options to
    remove deprecated options that fail tests.
  * debian/patches: fix up busted patches due to git-dpm:
    - debian/patches/add-an-auto-nvram-option-to-grub-install.patch
    - debian/patches/grub-shell-test-helper-disable-seabios-sercon.patch
  * debian/patches/r_x86_64_plt32-is-like-r_x86_64_pc32.patch: For the purpose
    of grub-mkimage, the R_X86_64_PLT32 relocation is basically the same as
    R_X86_64_PC32. Make R_X86_64_PLT32 supported.

 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 19 Jul 2018 09:46:53 -0400

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