Error: Invalid environment block

I had the same problem. Deleting grubenv had no efect.
Solved it temporarily using following commands in recovery shell
# cd /boot/grub
# rm grubenv
# grub-editenv grubenv create
# grub-editenv grubenv set default=0
# grub-editenv grubenv list
default=0

Thanks. This is obviously filesystem corruption of some kind (and I
don't know why; it's particularly weird that it seems to happen
repeatably), but for this particular case I'll make grub-common's init
script check for a zero-sized file on boot, and if so then make it just
delete it.

 status fixcommitted

Note that this happens more often on Karmic Koala (alpha), with it's use of ext4 for /boot seeming to lead to more instances of 0-length files upon system issues (in my case, the kernel crashed). I was just about to add some more information to support this, but I see Colin has fixed it. Thank you so much.

I just had a look at the fix, and I suggest a better fix would be to allow load_env to continue with just a warning if it fails reading the file. It's not like scripts don't have to handle unset environment variables in any case. That would allow for more exotic forms of filesystem corruption.

On Thu, Oct 01, 2009 at 10:14:51AM -0000, Glen Turner wrote:
> I just had a look at the fix,

Not sure how you managed that, since it's only on my laptop hard disk
right now!

What I meant is that I trialled your idea by hacking my init scripts as you suggest. You might want to test your idea further when I modify the script to "just delete it" the boot sequence still fails complaining about a read failure on grubenv. You need to say "/usr/bin/grub-editenv /boot/grub/grubenv create". Not sure if /usr is mounted at that point, as everything on this machine is in one partition.

The simplest approach might be to patch grub2 loadenv to be more robust when seeing failure.

I'd like to know why an explicit create is necessary for you, as
'grub-editenv /boot/grub/grubenv unset recordfail' will create the
environment block implicitly, as verified from the code and demonstrated
here:

  $ rm -f grubenv
  $ grub-editenv grubenv unset recordfail
  $ ls -l grubenv
  -rw-r--r-- 1 cjwatson cjwatson 1024 2009-10-01 16:17 grubenv

Where did you make your change? I put this line above '... unset
recordfail' in /etc/init.d/grub-common:

  [ -s /boot/grub/grubenv ] || rm -f /boot/grub/grubenv

Incidentally, there is a very good reason why loadenv doesn't create the
environment block itself - GRUB's filesystem modules don't have write
support, and adding that would expose us to a whole range of exciting
new possible bugs. For this reason, we create the file when we're in a
real operating system, and all GRUB has to do is write into a
pre-allocated block on the disk, which is pretty simple and safe.

Is your problem perhaps that loadenv is finding a zero-sized environment
block and failing before we boot into Ubuntu at all? If that's what's
happening, then we could make it treat a zero-sized block like an absent
one, or something like that.

Is there a way to recover from this when it hit me without reinstalling the system?

Yes the comments above give you a workable way to recover your system.

You need to be able load a live linux operating system that can write your your filesystem.

I used a live-usb drive. You can use the ubuntu install cd for this purpose.

After booting into the live cd based environment, you need to mount the partition on your main system that contains /boot.

Then you can make the necessary modifications to grubenv as per comments above.

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

This should give a bootable system.

I assume this problem is related to the instabilities in ext4?

Hi Colin :)

I don't know if you already had committed your fix, however this bug still happens. I just tried to be back from hibernation, but I can't. To solve I erased grubenv file following the comment #11 and everything works normally.

Check if you have the lines by pressing e when booting

recordfail=1
save_env recordfail

if so you can delete them by pressing Ctrl-D and then boot by Ctrl-X

What does recordfail does?

This bug was fixed in the package grub2 - 1.97~beta3-1ubuntu7

---------------
grub2 (1.97~beta3-1ubuntu7) karmic; urgency=low

  * debian/grub-common.init: /boot/grub/grubenv sometimes seems to end up
    zero-sized for some reason. If it is, just delete it (LP: #439784).

 -- Colin Watson <email address hidden> Sun, 04 Oct 2009 21:52:10 +0100

Solution given by Lepikk worked for me.
Just for completeness, I've used a cd-rom of Ubuntu Karmic Beta1 and from the option I've choosed "restore damaged installation" or something like that.
Than I've followed the wizard and when asked I've launched a console shell with /dev/sda1 (wich is my root filesystem) mounted.
And here I've inserted the grub-editenv command given by Leppik.

Well this bug still affects me after every unclean shutdown (karmic ubuntu 32-bit, fully upgraded) as of today and with
grub (1.97~beta3-1ubuntu8) installed.
Workaround: when grub loads and the menu is seen, press e and delete the 2 rows:
recordfail=1
save_env recordfail

Then normal boot with cntr-x.
After the system is up just hit reboot and the system runs OK.

As noted below, I still see this problem:

-r-------- 1 root root 3398 2009-10-08 00:45 grub.cfg
-rw-r--r-- 1 root root 0 2009-10-08 00:56 grubenv

Upon trying to boot, I can't. I manually mounted the partition, deleted grubenv b hand, and rebooted. Still now good. I had to remove:

recordfail=1
save_env recordfail

from grub.cfg, and then I could boot. Packages installed, which I could see when I booted:

ii grub-common 1.97~beta3-1ubuntu8 GRand Unified Bootloader, version 2 (common
ii grub-pc 1.97~beta3-1ubuntu8 GRand Unified Bootloader, version 2 (PC/BIOS

I had the same problem with a 32-bit install, but after following mr Bergman´s "recepy" I can "kill" the computer by pushing the restart button, and it boots up perfectly again. So a clean shutdown is no longer needed. Thank you, mr Bergman!

Eh... just one more thing. I am not a real newbie, but I don´t type in Terminal more than necessary. So, I got some help with the linux commands here: http://www.tuxfiles.org/linuxhelp/fileman.html

Deleting grubenv was no problem (rm grubenv after doing sudo su). Then I typed sudo gedit to open gedit but after erasing the two lines recordfail=1 and save_env recordfail, I couldn´t save it, I got the complaint that I was trying to write to a read-only media.
I don´t know what I did wrong, but as the rm command had already worked, I got around this problem by doing this:
I tested "save as" and that worked, and saved my new config-file as grub2.cfg.
Then I erased grub.cfg (rm grub.cfg) and renamed grub2.cfg to grub.cfg (mv grub2.cfg grub.cfg). It worked.
Then restart and...
Perfect! Opened a few applications and with all of them running, pushed the restart-button on my computer (a really ugly shutdown).
The computer booted up, and everything works perfectly. I have done it over and over again, no problem. Thanks again.

Colin maybe it makes sense to use something like this in grub.cfg?
Untested but that should work.

if [ -s /boot/grub/grubenv ] ; then
set grubenv_notzero = "true"
fi
if [ -n $grubenv_notzero ] ; then
load_env
[...]
if [ -n $grubenv_notzero ] ; then
save_env
fi

>I couldn´t save it, I got the complaint that I was trying to write to a read-only media.
grub.cfg is made read only for everyone, inclusive root.
With vim you can overwrite it with using ":w!"
If your editor doestn't have something like this then just use sudo chmod u+w grub.cfg
But don't forget that the next update-grub run overwrites your changes nevertheless.

Overwriting should be OK, as I don´t plan to do any update until the final 9.10 arrives. By then, this bug will surely have been taken care of.

please Colin submit a new fix asap because during these stormy days this bug is getting annoying, and the 2009-10-04 solution doesn't work (if it was a solution) :)

greets

Colin, this affected one of my machines today, which was up to date. It's an ext4 filesystem. Is there any more work planned on this for Lucid? I don't know how rare an event it is, but it's a catastrophic failure when it happens until someone finds this bugreport, there's little else in the way of help out there. Also, since the move to grub2, a lot of the docs Google throws up are out of date.

Instead of changing grub.cfg, what I've done on my computer was to change /etc/grub.d/10_linux (the source file when generating the grub.cfg):

Remove the lines that mentions recordfail:

$ diff /etc/grub.d/10_linux /etc/grub.d/.10_linux.bak
59a60,61
> recordfail=1
> save_env recordfail

I then run:
$ sudo chmod u+w /boot/grub/grub.cfg
$ sudo grub-mkconfig > /boot/grub/grub.cfg
$ sudo chmod u-w /boot/grub/grub.cfg

This should stop update-grub from adding the lines back.

I should also add that this change would affect all linux kernels - probably including other parallel linux installations in addition to the Karmic installation...

FWIW, if you change /etc/grub.d/10_linux, you don't need to make
grub.cfg unwritable - /etc/grub.d/10_linux is an input to update-grub,
not an output from it, and furthermore it's a conffile so changes to it
are preserved on upgrade.

I have not confirmed this yet by looking at any code, but the reason that grubenv is ending up zero bytes is likely that some code is writing to grubenv ( from linux, not grub itself ) by doing something like: write file "grubenv.tmp"; unlink file "grubenv"; rename "grubenv.tmp" , "grubenv". The reason this is likely being done is that /boot/grub/grubenv is read only. The problem is that unless in data=ordered mode ext* ( this affects ext3 also now that ordered mode is not default ) will sometimes write metadata before data. The work around to prevent zero byte files was to implicitly fsync when renaming over an existing file; because the code is unlinking grubenv first this implicit fsync is not triggered.

To fix this you could either temporarily make grubenv writable and do the standard write new file then rename over old or do: write /boot/grub/grubenv.tmp; fdatasync /boot/grub/grubenv.tmp; unlink /boot/grub/grubenv; rename /boot/grub/grubenv.tmp to /boot/grub/grubenv; fsync /boot/grub/ .

Even if that is not the cause of the problem I don't see how checking for a zero byte file during init is a fix since this bug will prevent users from getting to init in the first place, but I am likely just not understanding something.

On Tue, Oct 13, 2009 at 05:29:10PM -0000, Jordan wrote:
> I have not confirmed this yet by looking at any code, but the reason
> that grubenv is ending up zero bytes is likely that some code is writing
> to grubenv ( from linux, not grub itself ) by doing something like:
> write file "grubenv.tmp"; unlink file "grubenv"; rename "grubenv.tmp" ,
> "grubenv". The reason this is likely being done is that
> /boot/grub/grubenv is read only. The problem is that unless in
> data=ordered mode ext* ( this affects ext3 also now that ordered mode is
> not default ) will sometimes write metadata before data. The work around
> to prevent zero byte files was to implicitly fsync when renaming over an
> existing file; because the code is unlinking grubenv first this implicit
> fsync is not triggered.

grub-editenv already does an *explicit* fsync, so I don't think this can
be it.

In any case, this bug will be fixed properly in my next upload, as per
Felix's suggestion. It's just waiting for me to have a chance to reboot
and test it.

Looking at grub-editenv.c, as Colin said, it does call fsync explicitly so my theory was wrong.

However, it looks like grub-editenv is still not atomic: If you run "grub-editenv /boot/grub/grubenv set foo=bar" the first thing it does in create_env_blk_file() is call fopen( "/boot/grub/grubenv", "wb" ) truncating the actual file, not a temporary version. So if grub-editenv crashes between the fopen() and the fwrite() ( admittedly only two real lines of code ) or somehow fopen() succeeds but fwrite() fails, you will be left with a zero byte file.

Is there a reason why grub-editenv doesn't write to a temporary file? Would grub-editenv calling grub_util_error() or otherwise crashing trigger apport?

Am Dienstag, den 13.10.2009, 18:59 +0000 schrieb Jordan:
> However, it looks like grub-editenv is still not atomic: If you run
> "grub-editenv /boot/grub/grubenv set foo=bar" the first thing it does
> in
> create_env_blk_file() is call fopen( "/boot/grub/grubenv", "wb" )
> truncating the actual file, not a temporary version. So if
> grub-editenv
> crashes between the fopen() and the fwrite() ( admittedly only two
> real
> lines of code ) or somehow fopen() succeeds but fwrite() fails, you
> will
> be left with a zero byte file.
>
> Is there a reason why grub-editenv doesn't write to a temporary file?

Colin already fixed this on 1st October upstream.
Now it's:

  asprintf (&namenew, "%s.new", name);
  fp = fopen (namenew, "wb");
[...]
  fclose (fp);

  if (rename (namenew, name) < 0)
    grub_util_error ("cannot rename the file %s to %s", namenew, name);

That's included in beta4 which is already in Debian.

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

On Tue, Oct 13, 2009 at 06:59:11PM -0000, Jordan wrote:
> However, it looks like grub-editenv is still not atomic: If you run
> "grub-editenv /boot/grub/grubenv set foo=bar" the first thing it does in
> create_env_blk_file() is call fopen( "/boot/grub/grubenv", "wb" )
> truncating the actual file, not a temporary version. So if grub-editenv
> crashes between the fopen() and the fwrite() ( admittedly only two real
> lines of code ) or somehow fopen() succeeds but fwrite() fails, you will
> be left with a zero byte file.

I indeed noticed the same thing a couple of weeks ago, and fixed it
upstream for GRUB 1.97~beta4. :-)

2009-10-01 Colin Watson <email address hidden>

        * util/grub-editenv.c (create_envblk_file): Write new block with a
        .new suffix and then rename it into place, to ensure atomic
        creation.

I just got hit with this bug I updated this morning so I'll do the fix then update before I say that it's still a problem

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

one hour ago I tried to upgrade Karmic (to date) and I get this issue too, unfortunately I can't remember if last update installs recent version of grub2. Any way, all this environment was tested under VirtualBox VM.

Regards

On Wed, Oct 14, 2009 at 01:55:37PM -0000, Kamus wrote:
> one hour ago I tried to upgrade Karmic (to date) and I get this issue
> too,

I don't think you gave it a chance to build and get to the mirrors.

How long will it take to get to the mirrors? I just ran into this issue, too.

@rocko It depends on the mirror. The mirror admin will set how often they sync to the main server.

How do I check what version of Grub2 I have installed?

I have experienced this bug on an up-to-date system, but it's possible the mirror was out of date. It is still at this moment telling me I am completely up to date.

Sorry for a noob question.

Am Samstag, den 17.10.2009, 05:02 +0000 schrieb Wayne McDougall:
> How do I check what version of Grub2 I have installed?
>
> I have experienced this bug on an up-to-date system, but it's possible
> the mirror was out of date. It is still at this moment telling me I am
> completely up to date.
>
> Sorry for a noob question.
>

dpkg -l 'grub*'

--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

On Sat, Oct 17, 2009 at 05:02:45AM -0000, Wayne McDougall wrote:
> How do I check what version of Grub2 I have installed?
>
> I have experienced this bug on an up-to-date system, but it's possible
> the mirror was out of date. It is still at this moment telling me I am
> completely up to date.

You almost certainly need to run grub-install to reinstall the boot
sector. In fact, I suggest using 'sudo dpkg-reconfigure grub-pc' to make
sure that it'll be installed automatically from now on.

Thank you. Yes I was running the old version and since the NZ mirror was 4 days old, I got the update from the main server.

Have also run grub-install and dpkg-reconfigure grub-pc

Will let you know if I have any further problems.

New comment/bug??

I have multiple disks on my system, partitions set and labeled thusly:

sda, (hd0) SATA, with ntfs (sata) & ext3 (home2)
sdb, (hd1) IDE 0,0, with ntfs (windows install)
sdc, (hd2) IDE 0,1, with ntfs (apps) & ext3 (home)
sdd, (hd3) IDE 1,0, with ext3 (ubuntu root)
sde, (hd4) IDE 1,1, with ntfs (save) & ext3 (home3)

Problem: grub2 does not seem to like the multi disk arrangement. Keeps trying to look for things on the wrong drives, even though it is installed on sdd.
at grub prompt, if I type ls / it points to a random drive. It changes from boot to boot. I have tried set root=(hd3,1)
and set env=/boot/grub/grubenv.
Still, the grub goes random, and also gives error:invalid environment block.
Only way I can boot to karmic is to edit out the record fail line then ctrl+x.

Is this going to be a constant thing in karmic? How about in the next release in april?

Ubuntu 9.10 i386 Desktop

Up to date system.

Single IDE drive, with Dual boot XP / Ubuntu.
/dev/sda1 NTFS
/dev/sda2 extended
/dev/sda5 linux-swap
/dev/sda3 ext4

Grub in MBR

Pentium 4 2.66MHz, 1Gb RAM
Intel chipset
IBM Netvista model: MT-M 8303-NGT

at Grub 2, editing didn't helped.

With Live-CD and grub reinstallation helped in Simple way (https://help.ubuntu.com/community/Grub2#Reinstalling from LiveCD) ... for a while, needed two similar fixes within one hour of use ( there was several reboots between Ubuntu and XP ), so it fixes the booting, but something just goes broken again.
XP has been worked fine all time, when grub has worked and booted to there.

I got this problem just today with Karmic + all updates, so it's definitely not fixed. I'm re-opening it and attaching my hardware info with apport-collect.

Architecture: amd64
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release Candidate amd64 (20091020.3)
Package: grub2 1.97~beta4-1ubuntu4.1
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 LANG=fr_CA.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-20.58-generic
Uname: Linux 2.6.31-20-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

A bit more info:
- After a blank screen from an unknown cause (sleep/wakeup failed?), I had to do a hard reboot, and ended up with the same grub "error: invalid environment block" others were describing. After searching for 3-4 hours I stumbled upon this bug, and the following steps solved it: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/439784/comments/11
- I added a new duplicate

Similar situation ...
With karmic on a dell mini-9, got the invalid environment block / failed to boot default entries.
Combining the steps shown in Zaki's post #11 above with info from http://grub.enbug.org/Grub2LiveCdInstallGuide :

Boot with Karmic LiveUSB
Ctrl-Alt-FN-F1
sudo -i
su - root
mkdir /mnt/boot
mount /dev/sda1 /mnt/boot
cd /mnt/boot/boot/grub
rm grubenv
grub-editenv grubenv create
grub-editenv grubenv set default=0
reboot
(remove LiveUSB *after* the shutdown completes)

thanks much guys :D

I have the same error after upgrade Grub to GRUB2:
"Error: Invalid environment block"

I resolved this bug in following way:
cd /boot/grub
sudo cp grubenv grubenv_bad
sudo grub-editenv grubenv create
sudo grub-editenv grubenv set default=0
sudo reboot

Now it works perfectly !

Correct /boot/grub/grubenv file on Ubuntu 10.04 after typing commands:
sudo grub-editenv grubenv create
sudo grub-editenv grubenv set default=0

I just encountered this bug today on Ubuntu 11.04 (64 bits if that matters).
My computer froze and after reboot, got this error. Ubuntu seems to boot but apparently the X server cannot start.

I can still boot using the failsafe option in grub, but after making the changes to recreate grubenv, every time I reboot something writes over grubenv and it has a size of 0 ...
My version of grub is 1.99~rc1-13ubuntu3.

same here after boot-repair a (by the installer) false configured grub.
Windows is bootable via the grub menu but ubuntu 11.10 fails to boot

Still occurs in 12.04.
Solution described in #2 fixed the problem.

I installed on Ubuntu 13.04 and get this error after one of the updates for a new kernel. I doubt the issue is connected to that, but it is NOT directly related to the installation of 13.04 Raring.

I am NOT dual-booting. Exclusively Ubuntu 13.04

I do NOT get an error in which the normal error notification can occur.

What is the 'real' fix? I see comments above on typing in sudo commands. It looks like the problem will occur again and you have to do the same command. Hmmm?

Need a permanent fix, please...

Ubuntu 12.04

Same here, Error: Invalid environment block

Press enter, then it will still log to ubuntu.

How it's happen or how to reproduce ?

After shutting down ubuntu 12.04, but without closing or shutting down firefox before. (With alot of tab open and youtube video).

Get this error, must do the leppick fix. Or shut down firefox before exiting ubuntu.

Then no more error with next reboot.

hah.

Maybe this is not a "bug" after all...

Got this as well, and ended up at this LP bug...BUT...there was something peculiar.

$ head -1 /boot/grubenv

did NOT cleanly display "GRUB Environment Block" but had a few characters garbled in that line.
I remember this from IDE times, with badly-seated cables that don't display MAXTOR but MBYUIPR or whatever on HDD detection. That's because one single bit is off due to one bent pin.
It hasn't happened too rarely that I only saw a skew cable connection when using a magnifiier, or, at least a good lighting source (which is not always given)

So thanks everybody for the "fix", but I can't blame grub2 for it yet. See above output ($ head....)