grub-common does not unset "recordfail" on hibernate when using systemd

[Ewan]

My priority for this bug:
Low - I have a workaround that doesn't appear to cause negative side effects.

Symptom:
After hibernate, grub2 menu is displayed for 30 seconds

Workaround:
set GRUB_RECORDFAIL_TIMEOUT=0

More details:

lsb_release -rd
Description: Ubuntu 15.04
Release: 15.04

I have re-enabled hibernate, and it basically works. Information in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1443735/ causes me to believe that on hibernate, recordfail is getting set. As a consequence, the grub2 menu is displayed, unless GRUB_RECORDFAIL_TIMEOUT is set to 0.

Grub2 team suggested this should not be happening, and that a new bug be opened for this. My interpretation of https://wiki.ubuntu.com/Bugs/FindRightPackage was to log this bug here, which I've done via ubuntu-bug linux

Info relating to installed bios:
https://johnlewis.ie/custom-chromebook-firmware/rom-archive/
http://johnlewis.ie/coreboot-parrot-seabios-suspend-27102013.rom

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-22-generic 3.19.0-22.22
ProcVersionSignature: Ubuntu 3.19.0-22.22-generic 3.19.8-ckt1
Uname: Linux 3.19.0-22-generic x86_64
ApportVersion: 2.17.2-0ubuntu1.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: user 1490 F.... pulseaudio
CurrentDesktop: Unity
Date: Fri Jul 17 21:27:21 2015
HibernationDevice: RESUME=UUID=ca1b5985-7f8a-4931-9692-16fda5bd3fd7
InstallationDate: Installed on 2015-07-12 (5 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
MachineType: Google Parrot
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-22-generic root=/dev/mapper/ubuntu--vg-root ro
RelatedPackageVersions:
 linux-restricted-modules-3.19.0-22-generic N/A
 linux-backports-modules-3.19.0-22-generic N/A
 linux-firmware 1.143.1
SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/27/2013
dmi.bios.vendor: coreboot
dmi.bios.version: 4.0-4745-g1ce4860-dirty
dmi.chassis.type: 3
dmi.chassis.vendor: Google
dmi.modalias: dmi:bvncoreboot:bvr4.0-4745-g1ce4860-dirty:bd10/27/2013:svnGoogle:pnParrot:pvr1.0:cvnGoogle:ct3:cvr:
dmi.product.name: Parrot
dmi.product.version: 1.0
dmi.sys.vendor: Google

[Brad Figg (brad-figg)]

This change was made by a bot.

[Robie Basak (racb)]

I'm pretty sure this would need to be fixed in grub2 packaging, not in the kernel.

[Jose Bartolome (zubzou)]

the problem lies on grub_common.service after ubuntu 15.04 (migration to systemd) the unset recordfail must be done by a systemd unit, example under
https://ubuntuforums.org/showthread.php?t=2333934

[Robie Basak (racb)]

Thanks Jose. I think what needs doing here is pretty clear, so I'm marking this as Triaged. It may be more appropriate to send a fix up to the Debian BTS though, if the latest in unstable isn't fixed already.

[Cas (calumlind)]

Any update on this bug being fixed or reported upstream? I spent ages trying to figure out why the grub menu was appearing with a 30secs timeout after hibernation when it was supposed to be set to hidden! It may be a trivial bug but it really is not obvious that recordfail would be set for clean shutdown and startup.

This is on 17.04 lubuntu.

To workaround the issue I used the forum thread details to create `/etc/systemd/system/hibernate-recordfail-fix` with the code below and then `systemctl enable hibernate-recordfail-fix`:

[Unit]
Description=Execute grub script to unset recordfail after hibernation.
After=hibernate.target

[Service]
Type=oneshot
ExecStart=/etc/pm/sleep.d/10_grub-common thaw

[Install]
WantedBy=hibernate.target

[Robie Basak (racb)]

> Any update on this bug being fixed or reported upstream?

Looks like this bug is waiting on volunteers to contribute a patch.

[b3nmore (b3nmore)]

Attached an alternative service file which unsets recordfail directly via grub-editenv.

[Jeffery To (jefferyto)]

I have opened a merge request[1] with the Debian package that addresses this issue. Hope this can be fixed soon.

Also, I wanted to note that this isn't an issue with the upstream project since the recordfail functionality is specific to the Debian package[2].

[1]: https://salsa.debian.org/grub-team/grub/-/merge_requests/22
[2]: https://salsa.debian.org/grub-team/grub/-/commit/a2dac38edcc6236bfdbefad4e9654b498843504c