grub nice 'recordfail' feature doesn't work for hibernation

[Maxim Levitsky]

Binary package hint: grub2

The following happens:

1 - system is hibernated
2 - system is resumed, the 'recordfail=1' is set, but never cleared on resume
3 - system is shutdowned/hibernated again
4 - grub screen pops up

This breaks my automated scripts for hibernate testing (and wrong anyway)

[Maxim Levitsky (maximlevitsky)]

I had fixed that for myself with this script (in /etc/pm/sleep.d/)

#!/bin/sh

# Tell grub that resume was succesfull

. "${PM_FUNCTIONS}"

case "$1" in

 thaw)
  grub-editenv /boot/grub/grubenv unset recordfail
  ;;
esac

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 1.97~beta4-1ubuntu1

---------------
grub2 (1.97~beta4-1ubuntu1) karmic; urgency=low

  * Resynchronise with Debian. Remaining changes:
    + debian/default/grub:
      - Adjust for default Ubuntu boot options.
      - Use GRUB_CMDLINE_LINUX_DEFAULT option to set "quiet splash" for
        default items only. These options won't be set in single user mode.
      - Default to hiding the menu; holding down Shift at boot will show it.
    + debian/templates.in:
      - Change default value of grub2/linux_cmdline_default to "quiet
        splash".
    + debian/config.in, debian/postinst.in, debian/grub-pc.templates.in:
      - Migrate timeout settings from menu.lst.
    + debian/grub.d/05_debian_theme:
      - Set a monochromatic theme for Ubuntu.
    + debian/legacy/update-grub:
      - Apply Ubuntu branding: title, recovery mode, quiet option, and tweak
        how memtest86+ is displayed.
      - Use UUIDs where appropriate.
    + debian/control:
      - Conflict with grub (<< 0.97-54) as well as grub-legacy.
    + debian/patches/03_ubuntu_grub_standards:
      - Remove GNU/Linux from default string.
    + debian/patches/10_crashkernel.patch:
      - Add crashkernel= options if kdump and makedumpfile are available.
    + debian/patches/951_quick_boot.diff:
      - If other operating systems are installed, then automatically unhide
        the menu.
      - Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus if
        available to check whether Shift is pressed. If it is, show the
        menu, otherwise boot immediately. If keystatus is not available,
        then fall back to a short delay interruptible with Escape.
    + debian/patches/952_sleep_shift.diff:
      - Allow Shift to interrupt 'sleep --interruptible'.
    + debian/patches/954_normal_quiet.diff:
      - Don't display introductory message about line editing unless we're
        actually offering a shell prompt. Don't clear the screen just before
        booting if we never drew the menu in the first place.
    + debian/patches/955_really_quiet.diff:
      - Remove some verbose messages printed before reading the
        configuration file.
    + debian/patches/956_linux_quiet.diff:
      - If the environment variable "quiet" is set to something other than
        0, suppress progress messages as the kernel and initrd load. Set
        this for non-recovery kernel menu entries.
    + debian/patches/957_savedefault.diff, debian/rules:
      - Add GRUB_DEFAULT=saved, as well as grub-set-default and grub-reboot
        utilities. Provides functionality essentially equivalent to GRUB
        Legacy's savedefault.
    + debian/patches/959_loopback_root.diff:
      - Keep the loopback file open so that subsequent changes to the "root"
        environment variable don't affect it.
    + debian/patches/961_handle_loopback.diff:
      - Change prepare_grub_to_access_device to handle filesystems
        loop-mounted on file images.
    + debian/patches/963_linux_no_loopmount.diff:
      - Ignore devices loop-mounted from files in 10_linux.
    + debian/patches/965_failed_boot_menu.diff, debian/grub-common.init,
      debian/rules:
      - Sh...

[BavarianPH (bavarianph)]

recordfail=1 does not reset to 0

On my system, the latest updates changed grub2 settings to were

the menu appears regardless of changes in etc/default/grub script.

recordfail is set to 1, the grub menu appears and stays,

until I choose a selection, regardless of other grub2 settings.

only by changing recordfail to 0 will the PC boot directly to OS.

Changing recordfail back to 0 returns to 1 on the next boot in grubenv.

making grubenv read-only prevents the change to 1,

but of course only fixes the symptom, not the true cause.

I had set Power Management to Never put computer to sleep,

& to Never put display to sleep, & yet it does go into suspend mode,

regardless of my settings to the contrary.

I assume that recordfail=1 may be related to Power Management failure.

System runlevels for ACPID were apparently changed by Karmic updates,

which may be related.

seperating bug reports into categories can fail to realize the connections

between these bugs, its like treating symptoms without actually curing the bug.

one script effects another script, which effects a configuration, which effects programs.

tying Grub2 into loops & feedbacks, scripts & modules, not only increases the

complexity unnecessarily, but also increases the chance for interrelated failures.

KISS=Keep It Simple S???? (Solvers?), is a good motto, because even a stupid (ignorant)

user, like myself can analyze & fix it, unless one programs the PC to fix itself, which is,

of course quite complicated.

xorg is another example of over-complicating simple steps into automatic, complicated steps,

to were the user cannot override the program.

Taking user choice away, making it complicated, to were only a wizard can fix it,

only alienates the users; and ... one ends up with another Microsoft,

were only money to pay an expert solves the problems, & even then an upgrade requires

even more money, because that is what Microsoft and companies is all about.

Ubuntu could easily turn the same way.

Make it complicate to were the average user is unable to fix the problems,

 take away the users input and choice, & togetherness is gone!

BavarianPH

Ubuntu forever, (I hope)!

cannot

[BavarianPH (bavarianph)]

making grubenv read-only prevents the change to 1, is incorrect,

grub2 simply makes it a backup file & creates a new grubenv file with recordfail=1.

so, if I want to boot directly to the O, I have to manally set grubenv recordfail=0.

I hate to say it, but Grub-legacy was simpler, & less error prone,

only an expert could benefit from Grub2, most users only care about simple, easy

choices, & want a PC just to boot to the OS of their choice without having to have

a degree in computer science.

BavarianPH

Ubuntu forever!

[BavarianPH (bavarianph)]

gksu gedit /etc/grub.d/40_custom

& add to the bottom:

fi
if [ ${recordfail} = 1 ]; then
  set timeout=3
else
  set timeout=0
fi
# end

this is a symptom fix, but also ensures that if there were a

real boot problem, one has 3 seconds (or whatever time)

to pick another option.

BavarianPH,

Ubuntu forever!

[duckien (wingofchao)]

I confirm what BavarianPH said.

[David Tomlin (davetomlin)]

Just out of curiosity, did you happen to edit your /etc/init.d/rc file and change concurrency=none to concurrency=shell? I did this because it supposedly helps ubuntu boot faster by spreading the boot scripts across two cores if you have a dual core processor. I had it set for weeks before I experienced the behaviour of ubuntu 9.10 stopping at the grub boot screen. Once the behaviour showed itself, I edited /boot/grub/grubenv to recordfail=0 manually only to have it reset back to recordfail=1 after a reboot just like you said. Once I edited /etc/init.d/rc and set the concurrency value back to "=none" just on a whim, and manually changed /boot/grub/grubenv manually again to recordfail=0, I didn't have anymore issues.

Dave

[o1092245 (o1092245-deactivatedaccount)]

I confirm what David Tomlin wrote.

After setting concurrency=none to concurrency=shell in /etc/init.d/rc the file /boot/grub/grubenv has recordfail=1 after each reboot. Resetting the line in /etc/init.d/rc to concurrency=none and one time manual edit of /boot/grub/grubenv to change to recordfail=0 resolves the problem.

Vincent

[khanh (ink-bur)]

concurrency=none is a work around, not a resolution. recordfail is still set to 1 with concurrency=shell.

[Mike Clark (mclark1129)]

I am having the same bug, and recordfail=1 even if concurrency=none for me. If I set recordfail=0 and restart grub works.. once. The next time I restart it goes back to not using a timeout. I should note that I never changed the concurrency setting at any time, it was always =none for me.

[Mike Clark (mclark1129)]

I think I've figured out the root cause of the problem in Ubuntu 9.10, upstart. I've found that on my system my default runlevel is 'unknown'. When I init into a valid runlevel and restart, GRUB once again has a timeout. Of course, that fix is only temporary as the system will once again boot into runlevel 'unknown' when the system restarts. I think that GRUB2 isn't exactly compatible with a system like Karmic that uses upstart in place of runlevels.

[Marcelo Magalhaes (m-maga)]

I realized the solution from bug report "Some essential services are not started" at https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/500520 solved the issue about recordfail.
Have a nice day!

[Dmitry Kann (yktooo)]

I confirm what Mike Clark says. Setting 'CONCURRENCY=shell' in /etc/init.d/rc causes grub2 menu to be shown on every boot.

[Martin (martin3000)]

This bug is still present in ubuntu 16.04.
What program is responsible for setting recordfail back to 0 after booting?

[Colin Watson (cjwatson)]

@Martin: /etc/init.d/grub-common (the grub-editenv call).

[Martin (martin3000)]

How about /etc/pm/sleep.d/10_grub-common ?

[Colin Watson (cjwatson)]

That may be related too depending on the exact path the system takes; but you said "after booting", in which case the init script is more relevant.

[Martin (martin3000)]

/etc/init.d/grub-common is not run after resume from hibernate. So it cannot reset recordfail.

/etc/pm/sleep.d/10_grub-common also ist not run.

This is the reason why recordfail=1 in grubenv.