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

Please attach your /boot/grub/grubenv file.

i have the same issue ...

I also have the same issue ...

+ /boot/grub/grubenv

grubenv attached

I also have the same issue...

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!

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.

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

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.

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

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

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

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

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.

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

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.

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.

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.

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.

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.

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

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.

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

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

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

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

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

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.

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.

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 ?

ps about post #32 : all partitions are ext4

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

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.

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.

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.

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

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'

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.

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

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

@msth67

#79 used here; no separate /boot

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

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

Linux, bringing families together since 1991!

:)

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

I had a fresh installation of Ubuntu 14.04 64Bit

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

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

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.

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

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.

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?

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

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?

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.

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

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

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.

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

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.

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?

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.

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

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.

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.

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.

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.

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.

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

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.

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!

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

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!

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

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"

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!

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

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

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

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