[Grubenv] error: malformed file, press any key to continue

[Rkimber]

[Impact]

Some users with specific partitioning schemes may see a grub error message interrupting boot:

"error: malformed file, press any key to continue"

It appears to be caused by an invalid check for block overlap in grub2, and only applies to very specific installs, mostly using ext4, possibly limited to recent kernel versions.

[Test Case]

On an affected system, try to reboot the system.

[Regression Potential]

This is a fix which has been applied upstream for over a year, and included in 15.04. It changes comparisons in start and end values for block numbers to correctly match overlapping lists, and therefore should not affect more typical partitioning where there is no overlap. In effect, this changes increases the number of cases where a blocklist is deemed valid without removing the formerly accepted states, when loading the environment block.

A possible regression might show up as grub being unable to retrieve its last state for boot (ie. which menu entry was selected last time), but still successfully booting.

--

I have just upgraded from 12.04 to 14.04

Since the upgrade, when I boot up, the process stops and the normal grub screen is replaced after a short while by a message saying

"error: malformed file, press any key to continue"

Pressing a key allows booting to continue.

Someone else who experienced this found that the problem went away after having re-installed grub. I tried this but this did not resolve the problem for me.

synaptic reports the grub package as 2.02~beta2-9

[Phillip Susi (psusi)]

Please attach your /boot/grub/grubenv file.

[Tobias Strauß (tocomo)]

i have the same issue ...

[Ron (ron-f1)]

I also have the same issue ...

[Ron (ron-f1)]

+ /boot/grub/grubenv

[Rkimber (rkimber)]

grubenv attached

[AcCEsS (access)]

I also have the same issue...

[AcCEsS (access)]

grubenv attached...

loadenv.c (grub source):

          if (e1 > s2)
            {
              /* This might be actually valid, but it is unbelievable that
                 any filesystem makes such a silly allocation. */
              return grub_error (GRUB_ERR_BAD_FS, "malformed file");
            }

I have many Linux and other test partition
:-)

My fdisk -l output:

/dev/sda1 * 63 2103578 1051758 83 Linux
/dev/sda2 2104515 6297479 2096482+ 16 Hidden FAT16
/dev/sda3 6297480 216026054 104864287+ 7 HPFS/NTFS/exFAT
/dev/sda4 216027134 625141759 204557313 5 Extended
/dev/sda5 216027136 507041791 145507328 83 Linux
/dev/sda6 507043840 536338431 14647296 83 Linux
/dev/sda7 536340480 555870207 9764864 83 Linux
/dev/sda8 555872256 575401552 9764648+ 83 Linux
/dev/sda9 575404032 594933759 9764864 83 Linux
/dev/sda10 594935808 614465535 9764864 83 Linux
/dev/sda11 614467584 625141759 5337088 82 Linux swap / Solaris

Sorry for my poor english!

[RickKnight (rick-knight)]

I also have this issue. It started after I upgraded to Kubuntu14.04 LTS from a clean, fresh install of Kubuntu 13.10. The 13.10 splash worked correctly.

[Shaform (shaform)]

I have the same issue after a clean install of Ubuntu 14.04 64-bit.

[Teoman (yabguteo)]

I have the same issue after a clean install. I am using Ubuntu 14.04 x64. It does not effect the boot process or anything, however it is kinda annoying. Either press a key to continue or just wait for 5 seconds and it will continues itself. The hdd which I have my ubuntu on is an SSD which split into 3 partions; file, home and swap and also the bootloader is on the same disk.

[Geoff Clements (geoff-v8x)]

I have it after an upgrade from 12.04 LTS. Doesn't appear every time though.

[Mark Munkacsy (mark-munkacsy)]

Also affects me. Seems similar to (or identical to) GRUB Bug #42134 (http://savannah.gnu.org/bugs/?42134).

[matangdilis (matangdilis)]

I also have this issue on a clean install of UbuntuStudio AMD64. The / is on an ssd drive.

[matangdilis (matangdilis)]

...clean install of UbuntuStudio 14.04 AMD64 rather...

[Avi Marcus (avi-amarcus)]

I had this on a clean install of 14.04, similarly / was on an SSD. Grub was still quad booting to other drives/installs.
After a few more reboots it seems to have gone away, I didn't do anything particularly to fix it.

[Paweł Stołowski (stolowski)]

I've this issue on all three PCs I installed 14.04 on - these are i386 and amd64 installations. All three have fairly simple partition setups: just 2 primary partitions (for / and /home) and a swap partition. During installation I reused existing partitions and only marked root filesystems to be formatted. All machines have standard HDDs (not SSDs).

[paul (paulgault-r)]

also affects me. clean install of ubuntu 14.04 onto a small 32 gig SSD with home partition on a 3TB drive and win7 on another 1TB drive.
install done with a usb stick. i didn't bother using the ubuntu "make a startup disk" tool. just used dd to write the iso onto the usb stick.
unity appeared/loaded ok on first boot where i installed the fglrx-updates package for my AMD graphics chip.
had problems on second and subsequent boots of error message on boot of "error: malformed file, press any key to continue". as i selected auto login during install the desktop appears but not the unity toolbar/dashboard, etc leaving it pretty unusable.
i can still get to other tty screens with ctrl+alt+F2 and i tried purging fglrx-updates and replaced it with fglrx. no dice. same problem. i purged unity and replaced with gnome and gdm. lots of system error popup messages. still not usable.

[Simplet (simplet)]

Same issue here. Ubuntu 14.04 clean install. 1HDD, 3 partitions : "/" "home" and "swap".
Message is random, sometimes it displays and I need to hit a key, sometimes not and it boot straight.

[josefko (jkotarba)]

Same issue here, Kubuntu 14.04 32 bit upgrade from 12.04, 1 HDD, 3 partitions: "/", "swap" and the rest. Message is random.
The second computer with upgrade Kubuntu 14.04 x64 upgrade from 13.10 without message. There are more partitions there, with Windows 7.

[luvr (luc-vanrompaey)]

I also got this error, but now it's gone.
I have Ubuntu 14.04 installed on my /dev/sdb3 partition, and the GRUB2 boot loader is installed on the boot sector of the partition (not on the Master Boot Record).

The problem disappeared after I did the following (though I'm unsure if that's what made it disappear; for all I know, it could be sheer coincidence):

Booted Ubuntu 14.04. Got the error, but the boot completed OK.
Ran the following three commands (as root, i.e., after I issued the "sudo su -" command):

grub-install --force /dev/sdb3
grub-install --force --recheck /dev/sdb3
update-grub

Rebooted Ubuntu 14.04. Still got the error, but, again, the boot completed OK.
Repeated the very same three commands.

Rebooted Ubuntu 14.04 one more time.
The error was gone.

So far, the issue hasn't returned.

[Travis Falkenberg (travis-falkenberg)]

Have had this error, exactly as described, on and off since a new installation of Xubuntu 14.04 (beta). Thought it might go away on official release but has remained.

Grub is installed on /dev/sda

Was running Ubuntu 12.04 from a different partition on the same disk but have now deleted it. Did an update grub to get rid of the 12.04 boot option but the malformed file issue remained.

Tried what luvr(luc-vanrompaey) did in the above post, substituting /dev/sda.

Appears to have worked for the time being at least.

[Luigi R. (xluigi84)]

After update one of the following files a pop-up window showed up suggesting a reboot then I got the error at startup:

compiz_1%3a0.9.11+14.04.20140423-0ubuntu1_all.deb
compiz-core_1%3a0.9.11+14.04.20140423-0ubuntu1_amd64.deb
compiz-gnome_1%3a0.9.11+14.04.20140423-0ubuntu1_amd64.deb
compiz-plugins-default_1%3a0.9.11+14.04.20140423-0ubuntu1_amd64.deb
gettext_0.18.3.1-1ubuntu3_amd64.deb
gettext-base_0.18.3.1-1ubuntu3_amd64.deb
libasprintf0c2_0.18.3.1-1ubuntu3_amd64.deb
libasprintf-dev_0.18.3.1-1ubuntu3_amd64.deb
libcompizconfig0_1%3a0.9.11+14.04.20140423-0ubuntu1_amd64.deb
libdecoration0_1%3a0.9.11+14.04.20140423-0ubuntu1_amd64.deb
libgettextpo0_0.18.3.1-1ubuntu3_amd64.deb
libgettextpo-dev_0.18.3.1-1ubuntu3_amd64.deb
libnautilus-extension1a_1%3a3.10.1-0ubuntu9_amd64.deb
nautilus_1%3a3.10.1-0ubuntu9_amd64.deb
nautilus-data_1%3a3.10.1-0ubuntu9_all.deb

[luvr (luc-vanrompaey)]

Looks like the error message does still appear every now and then.
Must have something to do with the '/boot/grub/grubenv' file, which gets recreated upon each boot.

The code snippet posted by "AcCEsS" above (cf. comment #7) must be responsible for the error, though I have no idea what it is trying to test for.

[Søren Løvborg (kwi)]

So, this appears to be caused by a well-intentioned sanity check in Grub that sees an error where there's none when checking grubenv files spanning multiple "blocks".

In checking that blocks don't overlap, the code has an if-statement that appears to be accidentally negated ("if (s2 > s1)", should be "if (s1 > s2)"), causing Grub to *always* report an error *unless* all blocks overlap. Offending commit appears to be cb72aa1.

I can only assume that the only reason this hasn't been caught earlier is that the grubenv file most commonly only consists of one Grub "block"?

[Søren Løvborg (kwi)]

Aaand here's the upstream bug. http://savannah.gnu.org/bugs/?42134

[AcCEsS (access)]

Yesterday I made 14.04 installation on another computer. (The computer has four HDD)
The error message is the same.

fdisk -l output:
/dev/sda1 * 63 4000184 2000061 83 Linux
/dev/sda2 4000185 43070264 19535040 83 Linux
/dev/sda3 43070265 1943463374 950196555 83 Linux
/dev/sda4 1943463375 1953520064 5028345 82 Linux swap / Solaris

/dev/sdb1 * 63 4192964 2096451 6 FAT16
/dev/sdb2 4192965 2930272064 1463039550 83 Linux

/dev/sdc1 2048 125831167 62914560 7 HPFS/NTFS/exFAT
/dev/sdc2 125831168 3907028991 1890598912 83 Linux

/dev/sdd1 2048 3907028991 1953513472 83 Linux

[maasnet (m-vd-hoeven)]

Same issue here.

Xubuntu 14.04 (32 bit) clean install. 2 HDD, 2 partitions : "/" and "swap".

After grub the message: "error: malformed file, press any key to continue"

Pressing a key allows booting to continue.

Sometimes it displays and I need to hit a key, sometimes not and it boot straight.

Grub is installed on /dev/sda

[dino99 (9d9)]

i'm also getting this problem , but was first thinking about a "xz-utils" issue as there is sometimes an other message before that one : "console decompression error"
https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/1320077

[vagrale (vagrale)]

I had the same problem.
I found a solution here https://forum.manjaro.org/index.php?topic=10354.msg103451#msg103451
I adding the parameter GRUB_SAVEDEFAULT=true to /etc/default/grub file and that fix the problem.

[Klaus Bielke (k-bielke)]

I have the same issue after a clean install of Ubuntu GNOME 14.04 32-bit.
Filesystem is ext4 for / on sda2 and swap on sda6.
I installed grub into partition sda2 using blocklist.

Sometimes I get error message 'maleformed file',
sometimes 3x 'file not found',
sometimes no error message.

Boot continues successfully in all cases. I may, but don't need press any key.

There are more independent operating systems on this disk.
A Ubuntu 14.04 32-bit with / on sda3 and own GRUB in its partition boots always without error message.

[dino99 (9d9)]

Testing feedback

On that system, i run several different i386 installations, and get that issue ONLY with some of them. Booting is always made by the SAME grub (2.02~beta2-10). So that let me thinking that grub might not be the package to blame.

a) installations having that issue: Trusty & Utopic (stock kernels)
b) installations without that issue: The other Ubuntu ones (saucy, precise) with backported 3.13 kernels; And the Debian ones (Jessy & Sid)

So what's up ? Custom Ubuntu kernels ? Ubuntu custom settings ?

[dino99 (9d9)]

ps about post #32 : all partitions are ext4

[Quirin Lohr (coolinger)]

Found a fix for me.

I narrowed the 'malformed file' error down to grub loading the grubenv file.
I experimented a bit, deleting did not help, but setting a default entry seems to fix the issue for me:

grub-set-default Ubuntu

I installed using FAI if this helps finding the problem...

[dino99 (9d9)]

Thanks coolinger for the finding.

Glancing at my Utopic /boot/grub/grubenv, i see it writen on each boot. The latest is like:

# GRUB Environment Block
###################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################

All these #### seems insane. Note that my system is running only linux OS: ubuntu & debian, so no windows around and no empty ntfs partition.
So if that file is re-writen every cold boot, setting ubuntu as default may not work many times i suppose. Googling around "ubuntu grubenv" give lot of threads.

[dino99 (9d9)]

Additional comment to post #35

/etc/default/grub have 'GRUB_DEFAULT=0'

so its like setting ubuntu as default i suppose (or that fonction is buggy)
so why grubenv is also checked ? that seems redondant as 'grub' already have the required setting; or it is a borked grubenv file that is pushing that issue ? That does not explain why it is checked/rewriten.

[dino99 (9d9)]

and the grub.conf

# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
....

So there should be something wrong that produce all these ###### into grubenv. Maybe a font issue or a utf8 issue ? i'm using fr_FR.utf8 on that system.

[dino99 (9d9)]

That issue seems very close to lp: 1274320 which is also grubenv

[dino99 (9d9)]

New feedback

With previous boot commented since post #35, i have cleaned grubenv and set it with:
# GRUB Environment Block
grub-set-default Ubuntu

Today the cold boot is showing and other error instead the 'malformed file'; now it is 'environment block too small'. What is strange is that grubenv is checked by the boot process, but this time it has not been rewriten. That grubenv file is owned by 'root' and is 'rw'; should not it be only 'r' ?

Well, after glancing around that issue, there is a bunch of threads & reports about it over the net, like lp:439784; but sadly the number of opened grub reports is scary: lot of them are quite old and still not fixed.

Now i will test the proposed solution:

sudo su
cd /boot/grub
rm grubenv
grub-editenv grubenv create
grub-editenv grubenv set default=0
grub-editenv grubenv list
default=0

and then: dpkg-reconfigure grub-pc

hm, checking the new grubenv file , it is still 'rw'

[dino99 (9d9)]

Feedback

The #39 commands have made a clean grubenv file. The cold boot today has not shown the previous error(s). But glancing at /boot/grub/grubenv file, it has been again rewriten with the previous garbage, as reported into post #35. So back to madness.

[dino99 (9d9)]

Seems the same issue has been fixed some times ago:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/913336

but is back again. Wonder why we still have these 2 packages now: the old & new versions linked together, i mean: grub-common & grub2-common.

[dino99 (9d9)]

AS per /etc/grub.d/00_header, line 38

if [ "x${GRUB_DEFAULT}" = "x" ] ; then GRUB_DEFAULT=0 ; fi

so trying with a new grubenv made with:

oem@dev32:~$ sudo su
[sudo] password for oem:
root@dev32:/home/oem# cd /boot/grub
root@dev32:/boot/grub# rm grubenv
root@dev32:/boot/grub# grub-editenv grubenv create
root@dev32:/boot/grub# grub-editenv grubenv set default="x"
root@dev32:/boot/grub# grub-editenv grubenv list

the returned value is: default=x , so 00_header rule should now understand 'GRUB_DEFAULT=0' as it might and stop grubenv be rewriten with garbage. hm, will see if its true or not.

[Quirin Lohr (coolinger)]

Hey dino99,

the x is just part of an empty string comparison!

"x${GRUB_DEFAULT}" is compared to "x"

If ${GRUB_DEFAULT} is empty, it is "x" = "x"

Also, I think the "#"s from #35 is just padding because the grubenv file has to keep a specific file size or at least minimum file size.

Since the problem only occurs if installed by an alternate installer (in my case fai), my guess is that there is just a command in the installation script missing, which is executed in the default installer.

Can anybody show a grubenv file resulting from a default installation?

[dino99 (9d9)]

hi coolinger,

i've never used fai. That installation is a fresh Trusty one upgraded to Utopic via sources.list upgrade. If i remember that issue first appear around trusty beta time.
My previous change (#42) does nothing: grub is still set to 0, grubenv is set to x and is rewriten with a bunch of ######. So nothing better. The grubenv is set back to 0.

After reboot, grubenv is like that:

GRUB_DEFAULT=0
###################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################

[Quirin Lohr (coolinger)]

I set it using the command
grub-set-default 0

And this set it to
# GRUB Environment Block
saved_entry=0
#########################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################

No more errors since then...

[Roland65 (roland65)]

#45 fixed the issue for me on Ubuntu 14.04.
Thanks!

[Roland65 (roland65)]

Sorry, I'm wrong: the fix is only temporary... The problem comes back after an update-grub, grrrr! This is strange because the grubenv file is the same before and after the update-grub...

[Roland65 (roland65)]

What I said in #47 is also wrong. It seems that the annoying message disappears at the first reboot after the command grub-set-default 0, but reappears the next reboot. So this is not a valid solution... Sorry for the trouble!
RB

[Roland65 (roland65)]

OK, these issues suggested me a workaround for the bug. Here is the recipe:

1. Create a script named rc.fixgrub in /etc with the following content:

#!/bin/sh
/usr/sbin/grub-set-default 0

2. Make the script executable:
sudo chmod +x /etc/rc.fixgrub

3. Create two links to launch the script at shutdown and reboot:
sudo cd /etc/rc0.d
sudo ln -s ../rc/fixgrub K10fixgrub

sudo cd /etc/rc6.d
sudo ln -s ../rc/fixgrub K10fixgrub

4. Reboot (or shutdown) and voila... the bug has disappeared (and this is reliable now)!

RB

[Spiralofhope (spiralofhope)]

Thanks roland65, but your script doesn't work as it is.

1. make the script

sudo nano /etc/rc.fixgrub

1b. with this content:

#!/bin/sh
/usr/sbin/grub-set-default 0

2. Make the script executable:
sudo chmod +x /etc/rc.fixgrub

3. Create two links to launch the script at shutdown and reboot:

sudo ln -s /etc/rc.fixgrub /etc/rc0.d/K10fixgrub
sudo ln -s /etc/rc.fixgrub /etc/rc6.d/K10fixgrub

I have not rebooted to test this yet.

[Roland65 (roland65)]

Yes, you're right. Since I don't use sudo, I didn't notice that 'sudo cd' doesn't work. An there was also a typo in the commands.
I tested the recipe on my three Ubuntu boxes and this solved the issue.
Thanks!
RB

[dino99 (9d9)]

I was still get 'malformed file' on each cold boot.
And i got the idea to check, with gparted, how was set the boot flag as the system boot on sda:

- boot flag was set on sdb : with the latest grub2 i am getting the error 'malformed file'. This was not an issue with the previous grub 2.02~beta2-8

- changing the boot flag to the sda hdd which is the bios booting on: and now the error is gone.

On that system cgroup-lite cant be blamed as it has never been installed. So its a grub2 regression as that error, with the same boot flag on sdb, was not seen before the latest grub2 revision.

[Quirin Lohr (coolinger)]

Disregarding #52, which seems to be a completely different thing:

I did some testing and found out that the malfornmed file only occurs when /etc/init.d/grub-common is executed.
I narrowed it down to the line

 grub-editenv /boot/grub/grubenv unset recordfail

If I skip execution of /etc/init.d/grub-common (by setting an exit 0 in it's second line), I get no more malformed file errors, if I start testing from a working state.

If I execute the causing line from a shell, I get the error the next boot.

After some more testing, I found a working workaround:
Execute the line 4 times. (5 times works as well, I did not test more)
No more errors.

This matches the previous solution of calling grub-set-default, which executes the grub-editenv binary 3 times. After it was called one time from grub-common.

So I edited the /etc/init.d/grub-common file and let it execute the same command four times, which solves the problem for me.
I did only three reboots to test it.

I checked with strace, each of the commands has the same output.

My /boot is an extra partition, filesystem ext4,

I do really, really want to hear an explanation for this, because it drives me crazy...

TL;DR:
- Remove workaround from #50
- Edit /etc/init.d/grub-common
- Duplicate the line
 grub-editenv /boot/grub/grubenv unset recordfail
until it is there 4 times in a row
- Reboot

[Quirin Lohr (coolinger)]

Addition to #53:

A better because less intrusive workaround is here, using upstart:

1. Create file /etc/init/fix-grub.conf:
sudo vi /etc/init/fix-grub.conf

2. With this content:
start on stopped rc

script
 grub-editenv /boot/grub/grubenv unset recordfail
 grub-editenv /boot/grub/grubenv unset recordfail
 grub-editenv /boot/grub/grubenv unset recordfail
 grub-editenv /boot/grub/grubenv unset recordfail
end script

[Anatoly Geyfman (anatoly-0)]

collinger, #54 worked to get rid of the original message, but introduced a new message:

error: diskfilter writes are not supported

This message, unlike the previous one, allows the server to boot 5 seconds later.

[luvr (luc-vanrompaey)]

Since it looks like the '/boot/grub/grubenv' file is rewritten upon each boot, and (as #53 indicates) the '/etc/init.d/grub-common' script appears to be responsible for this action, I decided to turn off the 'executable' flag on this script--i.e. as root:

chmod -x /etc/init.d/grub-common

As a result, the grubenv file is being left alone now, and the error no longer reappears.

I must say, though, that the error had occurred at boot time when I cleared the executable flag on the script. Consequently, the error kept on happening from that point on, until I reconfigured GRUB--i.e.:

grub-install --force /dev/sdb3
grub-install --force --recheck /dev/sdb3
update-grub

Makes me wonder what is the actual use of the grub-common script? As far as I can tell, the system works just as well without it?

[Quirin Lohr (coolinger)]

It is this line:
 grub-editenv /boot/grub/grubenv unset recordfail
When you boot, the grub loader writes into the grubenv file that the system start failed.
When the system is started, this flag is removed.

If the flag is not removed, there will be no countdown to select the default entry on the next reboot. Perhaps you do not see it if you have a single boot system.

[luvr (luc-vanrompaey)]

You're right: I hadn't noticed, but my 'grubenv' file contains a "recordfail=1" line. Also, as you state, there is no time-out on the GRUB menu.

As a further experiment, I removed the "recordfail" lines on the menu entries that included them, since I assumed that these were the commands that were responsible for updating the 'grubenv' file. And, indeed, the "recordfail=1" line no longer shows up after reboot. Furthermore, the countdown on the GRUB menu remains.

Perhaps I should try and develop my own GRUB install scripts; as it stands, the GRUB configuration file is far more complicated than what I need.

[dino99 (9d9)]

So to resume, what we surely know ?

The "malformed file" appear if more than one block is used : so the question of multiple blocks

The actual grub used (2.02~beta2.10) has not having that issue when kernel prior to 3.15 is used
That issue appear with ext4 partition

So this seems related to how the recent kernels now work with ext4 and how grub do. Browsing the grub upstream list bugs, i feel the main cause is reported as : http://savannah.gnu.org/bugs/?42466

and the new ext4 kernel rule: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/namei.c?id=455c6fdbd219161bd09b1165f11699d6d73de11c#n2831

[dino99 (9d9)]

Adding these lines into /etc/default/grub

#workaround for "malformed file" error
GRUB_SAVEDEFAULT=false

then, update-grub, will remove that error

[kerb (y-kerb)]

dino99's trick didn't work for me.

[dino99 (9d9)]

@ y-kerb

you are right, it has worked for a while, but since a week or so it warns out again. Wonder if the latest grub change (2.02~beta-2.10) can be blamed due to some other upgrades (like libc6 or else) ?

" * Simplify override_dh_install a bit. "

[dino99 (9d9)]

Add to #62 comment:

latest libc6 change: " switching us to glibc " instead of previously used eglibc (2.19~4ubuntu1)

[dino99 (9d9)]

More comments:

latest grub was built on May 8
latest libc6 built on Jun 19

so it should be a good idea to rebuild grub to take care of the latest libc6. Please devs do.

[Quirin Lohr (coolinger)]

I am living with my brute-force workaraound from #53 now.

I first thought it was because of ext4 file system for /boot, but switching to ext2 did not help.

My partitioning:
 1 32.3kB 5363MB 5363MB primary ext2 boot
 2 5363MB 9656MB 4294MB primary linux-swap(v1)
 3 9656MB 63.3GB 53.7GB primary lvm

sda1 in /boot , root is inside the lvm.

[ajgreeny (ajg-charlbury)]

I have just started seeing this problem on a newly installed Xubuntu 32bit 14.04 on a netbook (Atom cpu, 1GBram, Intel integrated gpu).
It coincided with me enabling hibernation by adding the file as shown in http://ubuntuforums.org/showthread.php?t=2219403, but that may be pure coincidence as the error occurs from cold boot and wake from hibernation. I have always pressed a key to continue and don't know if it will continue even if I dont.
I have added the line GRUB_SAVEDEFAULT=true to /etc/default/grub as suggested at post #30 and will report back results after many reboots or wakes from hibernation.

[kerb (y-kerb)]

As a hint, hoping it helps.
In my case i had the message after GRUB launching.
I could see inconsistancies in my /home partition which is EXT3 formated but at install i unthoughfully declare EXT4.
As of parameter were showing format EXT4 and another parameter (one like EXT_TYPE) was showing EXT3.
I reinstalled selecting EXT3 for my /home and the message doesn't show up any more.

[msth67 (msth67)]

I've run into this issue after installing Lubuntu 14.04 32 bit on an old laptop upgraded with a new 64GB SSD:the disk had first been partitioned with only a primary root partition (ext4) and swap, the installation process apparently went normally,then after installing the system I did get this error message on boot:
error: attempt to read or write outside of disk 'hd0'.
Entering rescue mode...
grub rescue>

from that I was able to boot the system following this advice http://askubuntu.com/questions/397485/what-to-do-when-i-get-an-attempt-to-read-or-write-outside-of-disk-hd0-error
basically with

grub rescue > set root=(hd0,<root partition>)
grub rescue > set prefix=(hd0,<root partition>)/boot/grub
grub rescue > insmod normal
grub rescue > normal

I was able to boot the system but then it was not possible to reinstall grub from the running system with the usual sudo grub-install /dev/sdX command.

As a next step,following the advice from the same link posted above,I've reformatted the drive with a dedicated boot primary partition and a primary root partition (still ext4) plus swap and installed grub to the boot partition during the installation process:now I'm getting the
 [Grubenv] error: malformed file, press any key to continue
message but the system boots most of the times either by hitting a key or waiting for the message to time out,except for some times when I see another "READ ERROR" message and I have power off and then on again the laptop.

This was a clean install on a new SSD in single boot mode (no other OS and no other partitions are present on the disk) and furthermore I've tried also Mint 17 (based off Ubuntu 14.04 as well) and got stuck in the same situation.

[msth67 (msth67)]

Just a clarification,the error message when trying to reinstall Grub in the first case ("I was able to boot the system but then it was not possible to reinstall grub from the running system with the usual sudo grub-install /dev/sdX command.") was:

Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklistts are UNRELIABLE and their use is discouraged..
grub-setup: error: will not proceed with blocklists.

The workaround described in comment #53 apparently works for me,as the error message is no longer visible,however the boot process itself now seems to take a bit longer.

[mike (dromtrasnakin)]

Using Linux mint 17 xfce based on ubuntu 14.04

This bug appeared on my system after attempting to fix a suspend session.
Normally screensaver can be unlocked with a password but somehow my system froze.

Decided to view help
Pressed Ctrl +Alt+ F1
Then type in the username and password
Then typed in help
A list of commands where displayed
but no guidance or info about grub errors

This prompted me to reboot the system
Typed in sudo reboot

After the operating system rebooted,
noticed the error malformed file. Press any key to continue.

Searched the internet for a solution.

Decided to use the synaptic package manager to find the grub packages installed on my system
Reinstalled the grub package

Rebooted my operating system

Solved

[msth67 (msth67)]

Follow up to my comment #69 : what is triggering the random "READ ERROR" message is apparently rebooting the system:cold boot does now (kinda) work with a separate boot partition and the workaround from comment #53 to hide the error message,however attempting to reboot the system often triggers this other "READ ERROR" message for which I've found no other solution than hard reset (power off) the computer and then booting it again.

[dino99 (9d9)]

An other error getting from time to time, way before the starting grub process, is:

"xz compression data is corrupted" , and need to reboot in that case. Wonder if a possible relationship can exist between these two errors.

[msth67 (msth67)]

Here's another strange fact:I've also experimented with a Grub live cd (Super grub 2disk) and a Grub recovery cd made with grub-mkrescue,they both have troubles finding the partitions on the disk.

There are three in total:
/boot partition
/root partition
/swap partition
all of them are primary.

For some reason to detect all three takes several attempts,at first the ls command or the "detect any grub.cfg" in the case of Super grub 2disk only sees the root partition,then after repeated attempts the full disk layout is recognized and the system can be booted.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1311247

[Forest (foresto)]

Response to comment #70: Reinstalling the grub packages did not fix the problem on my system.

[RickKnight (rick-knight)]

Received an auto-update for GRUB last week. Applied it hoping it would have a fix for this issue. It DID NOT.

[Bertram (bertram-q)]

I faced the bug as well, however none of the reported workarounds worked for me.

After a bit of testing I found out that the error doesn't appear when booting a boot-entry from the grub-submenu "Advanced options for Ubuntu" (see attachements), it only appears when selecting the default entry "Ubuntu".

Since the first entry of the "Advanced"-submenu is the same as the standard (i.e. the one using the latest kernel) entry, changing the default boot entry from "0" to "1" in /etc/default/grub did the trick for me. The error doesn't shop up any more.

/etc/default/grub
#GRUB_DEFAULT=0
GRUB_DEFAULT=1

Just for the sake of completeness: Moving that entry out of the submenu (by altering /etc/grub/grub.cfg manually) makes the bug reappear. The entry has to be within the submenu.

[Rajat Pandita (rajat-pandita)]

Here is what I did
Just like Bertram (bertram-q) ..

1) edit the file

/etc/default/grub
replace
GRUB_DEFAULT=0
With
GRUB_DEFAULT=1

2) sudo update-grub
3) Reboot

Issue fixed.

Thanks .
I hope more people are able to use this fix and get over with this annoying bug.

[ajgreeny (ajg-charlbury)]

I have also made that change to the /etc/default/grub file and changed

GRUB_DEFAULT=0
to
GRUB_DEFAULT=1
then ran sudo update-grub

So far after several boots the error message has not reappeared.

I realise this is something of a workaround and not a real solution, but it does appear to work.

Well done Bertram.

[Paweł Stołowski (stolowski)]

Looking at the upstream bug report, this issue was fixed on 2014-06-21. The fix is relatively small - see http://git.savannah.gnu.org/cgit/grub.git/commit/?id=1f6af2a9f8b02a71f213b4717d8e62c8a6b14fc5 - could a distro-patch be considered for it?

[cptX (myrbourfake)]

I'm waiting so many months for a new version of grub that will have this bug fixed. It's strange but I installed linux mint in several computers and only in one I got this problem. I totally reinstalled linux mint in that pc and it happened again. According to the link http://savannah.gnu.org/bugs/?42134 the bug is found and fixed, so the question now is when the new version is going to be released? Is there anything I could do by my own in order to solve this? Should I compile grub myself or should I wait for the official release?
PS: I tried all the above mentioned solutions and none of them helped!

[pickarooney (richard-walsh)]

Same issue on 14.04 Xubuntu. Posting to bookmark while awaiting a certified fix.

[wmccarty (wdmlist)]

I have two kubuntu 14.04 installations and it is appearing on both.

[Paviluf (je-rem-y-deactivatedaccount)]

Same problem on Netrunner 14 (kubuntu fork)

[Michael Rösch (ubuntuusersde)]

Same Problem here on ubuntu14.04 recently upgraded from 13.10.
The workarounds setting the grub default option is not possible for me, because I am using the system with vdr.
The vdr sets a wakeup-time which is programmed in the BIOS with nvram.
My mainboard requires a reboot for making this setting effective which is achieved by turning the system-shutdown into a reboot and choose the last menu-entry "PowerOff".
However, it turned out that this is not happening when I switch of the system with the halt-command in the grub menu entry I call after reboot.
To clearify this is the content of my 40_custom:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "PowerOff" {
        saved_entry=0
        save_env saved_entry
 sleep 4
        halt
}

When I switched off the system by power key, it worked.
The only way to make it work again was downgrading to the previously used version
2.00-19ubuntu2.1
and set the packages on hold in aptitude.

Why are we using beta-versions in a LTS-distribution?

[Carl Fletcher (caf4926)]

Same for me on 14.04
And several of my customers 14.04 installs. Not great that.
I'm already having to workaround the ibus fiasco with UK keyboard selection

[Andrei Ciobanu (andreic9203)]

For me the comment #50 was the solution.

[Hrvoje (hrvoje-habjanic)]

Hi.

Adding:

if [ -f /boot/grub/grubenv ] ; then
  mv -f /boot/grub/grubenv /boot/grub/grubenv.old
  cp /boot/grub/grubenv.old /boot/grub/grubenv
fi

in /etc/rc.local fixes this issue for me - Ubuntu 14.04.x LTS.

H.

[Forest (foresto)]

This is still a problem in Trusty. Can someone tell us whether it's fixed in Utopic?

The savannah bug report says fixed. What version of grub fixes it? Will upgrading grub fix the problem in an existing installation, or is further action required?

(Note: I'm interested in the official fix, in order to keep in line with a stock installation, not workarounds that might have to be manually removed later.)

[Erick Brunzell (lbsolost)]

I've never seen this in Utopic, only in Trusty. Additionally I've found that if I just wait an additional 5 to 10 seconds when this appears boot proceeds as expected with no user action required.

[dino99 (9d9)]

The proposed workaround do the trick, but without it the problem still exist with the latest vivid's grub.

[msth67 (msth67)]

To clarify, which one of the proposed workarounds fixes the issue ?

Does "fixing" in this case mean that no separate /boot partition is needed ?

[dino99 (9d9)]

@msth67

#79 used here; no separate /boot

[Martin (lodp)]

Solution in comment #79 worked for me, too. Do I have to fear that the appearance of a new kernel with new grub entries and so forth will screw this up again? I need a durable solution, I don't want to make cross-country support visits to my auntie...

[JohnWashington (ubuntu-johnwash)]

... go on, you know you want to!

Linux, bringing families together since 1991!

:)

[OldbadBear (oldbadbear)]

This Bug affected me but Bertram (bertram-q)'s solution worked for me to.

I had a fresh installation of Ubuntu 14.04 64Bit

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 2.02~beta2-21

---------------
grub2 (2.02~beta2-21) unstable; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * Fix overlap check in check_blocklists for load_env (backported patch
    from upstream commit 1f6af2a9; LP: #1311247).

  [ Steve McIntyre ]
  * Add support for running a 64-bit Linux kernel on a 32-bit EFI (closes:
    #775202).

  [ Colin Watson ]
  * Use mtmsr rather than mtmsrd in ppc64el-disable-vsx.patch, since the
    "VSX Available" bit is in the lower half of the MSR anyway, and mtmsrd
    faults on 32-bit systems (closes: #776400).

 -- Colin Watson <email address hidden> Tue, 27 Jan 2015 20:37:04 +0000

[cptX (myrbourfake)]

Hi, does anybody know when will we see this release in the official Ubuntu repositories? Until now I haven't see it, yet! I'm actually using Linux Mint which is based on Ubuntu and I cannot see this update as available, yet

[Phillip Susi (psusi)]

As the previous message said, it was fixed in version 2.02~beta2-21 which is sitting comfortably in the Ubuntu vivid repo. Mint is on their own update schedule so you will have to take it up with them.

[cptX (myrbourfake)]

@ Phillip Susi:

Sorry to bother again but if I understood correctly Ubuntu vivid is 15.04 right? This means that the grub2 - 2.02~beta2-21 will not be available to Ubuntu 14.04?

How can I added to my system (Linux Mint 17, based on Ubuntu 14.04)? This update is critical for me! I'm waiting for it several months now!

Regarding "Mint is on their own update schedule" I thought that Ubuntu repos are common in Ubuntu and Mint, so I don't understand why this update is not visible.

[Phillip Susi (psusi)]

I have no idea how mint works. In Ubuntu it is only in 15.04, which is still in development so Ubuntu users have to wait for that. My guess is that you won't see it in Mint until their next release either.

[cptX (myrbourfake)]

But this problem is so significant that it should be solved in all the versions that are affected!! I don't get it why it should be only available in 15.04 !!
14.04 is a LTS why isn't corrected there as well?

[cogset (jackfog66)]

Seriously, this isn't going to be backported to 14.04 ? Ubuntu 14.04 is supported until 2019,and this is a major bug.

[cptX (myrbourfake)]

Please somebody answer us! We are so many people waiting for this bug to be solved. Look the subscribers list!!! This is major!!!

Why such a serious bug is not going to be backported to 14.04 that is LTS and should be supported up to 2019?
What is the point to install an LTS if major bugs like this are not solved?

In case this bug will for any reason in this world not going to be applied to 14.04 can anybody give us some help how to compile it on our own and apply it in an existing 14.04 system?

Anybody, please?

[Joel Cairo (hitlerhasonlygotoneball)]

On Mint 17.1 KDE, here. Yes this bug has been bugging me for the last few days!

I just installed grub2 - 2.02~beta2-21. Only booted up a couple of times since, but all seems fine.

Get it here: https://packages.debian.org/sid/grub2-common

On AMD64 you'd then go to: https://packages.debian.org/sid/amd64/grub2-common/download, where you're advised to add the repo to your /etc/apt/sources.list. In my case that is: deb http://ftp.uk.debian.org/debian sid main.

My sources.list - opened as text with root - showed only the commented out CD-ROM entry. I added the above, below it.

Running the Update Manager - selecting to show levels 1 through 5 - refreshing now showed a great many updates that, obviously, or presumably, one does not want in Mint, so clicking Clear deselected them. Then just selected 'Grub' and installed.

Not knowing if the bug was in part at least a problem with /boot/grub/grub.conf I allowed the installation to replace my user-edited version, with the consequence that on reboot instead of Linux Mint <etc etc> it just listed Ubuntu. Having backed up grub.conf I then replaced 'Ubuntu' with the previous version's 'Linux Mint <etc etc>' - changing only the menu-entry names.

Then back in Update Manager, deselect showing levels 4 and 5 updates, then in Software Sources deselect the added debian sid main repo, close, reboot. Now the dozens of probably-unwanted updates are no longer displayed. So far, so good.

[Joel Cairo (hitlerhasonlygotoneball)]

Just in case anyone misunderstands the above as displayed here, that source entry is:

deb http://ftp.uk.debian.org/debian sid main

NOT just the ftp link part!

(or whatever your locale).

[Joel Cairo (hitlerhasonlygotoneball)]

And, of course, I mean grub.cfg - not grub.conf!

[cogset (jackfog66)]

That's not the way to do it: it may work, but this is an Ubuntu (major) bug and should be solved without adding packages from the Debian package repositories.

Also, it is worth reiterating that an LTS release such as Ubuntu 14.04 has to be fixed, period.

[cptX (myrbourfake)]

I totally agree! The problem though is that the assigned maintainer is probably too busy with other stuff and is not reading this thread any more! Either another maintainer should take over or we should bumb this problem to another thread!!

[Erick Brunzell (lbsolost)]

Not sure I'd consider this a "major" bug. On the 20+ machines I maintain if that message is simply ignored for 5 to 10 seconds boot completes with no user action at all. It's cosmetically nasty - in that it gives the impression that something is actually borked.

[cptX (myrbourfake)]

Maybe this specific issue isn't so critical from a system stability point of view, but regarding what actually LTS (Long Term Support) in reality means is more than critical!!! It's not acceptable an LTS system to not include this kind of bug fixes, especially when a bug is affecting so many people and for such a long time. I mean what is the point to characterize a release as LTS if this kind of stuff are not fixed! How can anybody trust an LTS then? Do we want Ubuntu LTS and Linux in general to be considered a trustworthy operating system or not?

[Phillip Susi (psusi)]

You are misinformed cptX. Ubuntu does not have assigned maintainers the way debian does. Also LTS does not mean every little annoying bug will be fixed; it means it gets security fixes so your system won't be vulnerable.

[cptX (myrbourfake)]

If LTS regards only security fixes then probably I'm misinformed! Actually, after your comment Phillip I searched it a bit and looks you are right!

So this means that there is no chance this bugfix will be backported to 14.04? We should not wait anymore?
At least it's better to know that there is no chance for it! I don't like visiting this thread every day with the hope to find an official solution.

Disappointed ...

[Phillip Susi (psusi)]

There isn't NO chance... non security bugs will be fixed when they are deemed critical enough. This particular bug isn't a big deal, which is why nobody has bothered to backport it yet. If a developer decides it bothers them enough though, they may go ahead and do the work to backport it, but since this is only a cosmetic issue, I wouldn't hold my breath.

[cogset (jackfog66)]

I still disagree: being greeted with an error message right after finishing the installation of a new OS isn't exactly the right way to start, isn't it?

Cosmetic or not, apart from seasoned users who may have seen worse, this ain't going to make a great impression on newcomers to Ubuntu- if anything, it will make it appear a bit like windows, although in the end they might find this reassuring...

There also may be more to it, although frankly I'm not sure at this point if it is directly related or not: as I've said above in comment https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1311247/comments/68 after installing Lubuntu 14.04 on a new SSD I wasn't actually able to boot the installed system, I had indeed to create a separate dedicated /boot partition or else it would never boot. That I wouldn't call cosmetic.

[krusade (fringeform)]

I too am affected by this bug.

"If a developer decides it bothers them enough though, they may go ahead and do the work to backport it..."
This is the kind of thinking that keeps linux irrelevant to the majority of computer users. Even the distributions that make an effort to cater to the non technical users are riddled with bugs, some of which are so severe as to make the os unusable (have you ever lost your graphical interface after a kernel update?). Even for an LTS edition,a bug is fixed if it bothers a developer enough. If they can find a workaround for it it means the bug is not critical...For them. For a normal user it may mean days or even weeks of research on message boards and frustrating trial and error attempts that often times make things worse. So "critical" has hardly the same meaning for knowledgeable linux users as for regular users, for whom the operating system is (and should be) a tool that is invisible. Ubuntu already is a great operating system for developers. If you want it to also be an operating system the other computer users, the scale you use to weigh the severity of bugs is wrong.

[nonsisa (nonsisa)]

I have solved this issue with a variation of the method of comment #79

First you do it exactly as in 79. then after reboot you set back GRUB_DEFAULT=0 and update-grub. After a reboot everything should work again.

As a side note these are the things that will keep ppl away from using ubuntu. Errors after updates, or installing propriety drivers failed installings etc. that screw up the system. Enough said.

[nonsisa (nonsisa)]

I've come to notice that this solution is only temporary and I still get this malformed file warnings from time to time.

Ergo there is no solution for this problem till now.

[Julian Taylor (jtaylor)]

a way that works for me is setting quick_boot to "0" in /etc/grub.d/10_linux and running update-grub2
this removes the ubuntu specific save_env command via the recordfail function
this then causes the problematic check_blocklist function to not be called.

you can verify that the save_env calls are gone in /boot/grub/grub.cfg

[Mathieu Trudel-Lapierre (cyphermox)]

So it seems all this requires is a SRU of the changes in grub2 2.02~beta2-21 to 14.04. I'm starting this now.

[Chris J Arges (arges)]

Hello Rkimber, or anyone else affected,

Accepted grub2 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2/2.02~beta2-9ubuntu1.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Steppenwolf (steppenwolf-eu)]

Tested on Mint 17, bug fixed. Thanks a lot!

[Adam Conrad (adconrad)]

Hello Rkimber, or anyone else affected,

Accepted grub2-signed into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/grub2-signed/1.34.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

@Steppenwolf - What version of grub2 does Mint 17 use? You can check with apt-cache policy grub2.

[kony (kony412)]

The trusty-proposed update (to ubuntu1.4) fixed the issue on my laptop with Linux Mint 17.2. Thank you.

@Brian Murray
It uses the standard grub2:
"grub2:
  Installed: (none)
  Candidate: 2.02~beta2-9ubuntu1.3
  Version table:
     2.02~beta2-9ubuntu1.3 0"

[Ubuntu Foundations Team Bug Bot (crichton)]

As a part of the Stable Release Updates quality process a search for Launchpad bug reports using the version of grub2 from trusty-proposed was performed and bug 1507175 was found. Please investigate this bug report to ensure that a regression will not be created by this SRU. In the event that this is not a regression remove the "verification-failed" tag from this bug report and add the tag "bot-stop-nagging" to bug 1507175 (not this bug). Thanks!

[Mossroy (mossroy)]

I successfully tested this patch.

Here is what I did :
- enabled proposed repository
- ran the following command-line (it might not be the same on different hardware) :
sudo apt-get install grub-pc
On my computer (no UEFI), it upgraded the following packages :
grub-common grub-pc grub-pc-bin grub2-common
- disabled proposed repository
- rebooted the computer (and pray ;-) ) : no error message
- rebooted the computer more than 20 more times (with some cold reboots, with and without displaying the grub menu, and after playing with memtest86, too) : no error message
- checked that the version displayed in the grub menu is 2.02~beta2-9ubuntu1.4

So I'd say it really fixed the issue for me, with no side effect.
I don't know what happened in bug 1507175 , but I did not have this issue.
I'm not sure if I should replace the verification-failed tag, but I'll add a verification-done one.
As grub is a very critical piece of software, I would be more confident if some other persons confirm it's working for them too.

NB : I'm using Ubuntu 14.04.3 (64bit) on an Asus Eee PC 1015PX

[Mathieu Trudel-Lapierre (cyphermox)]

Removing verification-failed; this has been an ongoing issue, and it appears to be unrelated to the bugfix here; grub-efi-amd64 reports an error on a system on which it isn't supposed to be installed (in bug 1507175).

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 2.02~beta2-9ubuntu1.4

---------------
grub2 (2.02~beta2-9ubuntu1.4) trusty; urgency=medium

  * Fix overlap check in check_blocklists for load_env (backported patch from
    upstream commit 1f6af2a9). (LP: #1311247)

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 23 Sep 2015 21:29:20 -0400

[Chris J Arges (arges)]

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.

[Launchpad Janitor (janitor)]

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

---------------
grub2-signed (1.34.5) trusty; urgency=medium

  * Rebuild against grub-efi-amd64 2.02~beta2-9ubuntu1.4 (LP: #1311247)

 -- Adam Conrad <email address hidden> Mon, 05 Oct 2015 04:23:21 -0600