environment block not implemented on btrfs

Confirmed here. Though my configuration is a bit different it gives the same behaviour as here above described.
I run Natty alpha3 amd64 with kernel 2.6.38-7-generic.

sudo fdisk -l responds with the following:

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x57853315

   Device Boot Start End Blocks Id System
/dev/sda1 1 13 102400 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 13 2563 20480000 83 Linux
/dev/sda3 2563 54428 416603136 83 Linux
/dev/sda4 * 54428 60802 51198976 7 HPFS/NTFS

With /dev/sda1 mounted as /boot formatted as reiserfs, /dev/sda2 is also formatted as reiserfs and mounted as /
/dev/sda3 is an ext4 partition mounted as /home and /dev/sda4 is my Windows partition.

I get the same problem.
I just received a SSD Disk, so I did a fresh install of Natty Alpha 3 and get the error since the first boot (2.6.38-5)
Update to be up 2 date change nothing (2.6.38-7 essentially)

I didn't remember getting this issue with my old disk before (I was already in Natty since it was avalaible by updating from 10.10)

Same problem in Kubuntu Desktop Desktop i386 (natty-deskitop-i386.iso 20110329.1)

This is actually a misleading error message: what's happening is that GRUB's btrfs implementation doesn't implement the file read hook interface for returning blocklists to calling code. I posted to grub-devel about this and the upstream maintainer pointed out that, even aside from multi-device problems, writing to btrfs from GRUB is fundamentally risky because:

 * the same block may be used by multiple snapshots
 * every tree which uses a given block will contain its checksum, and so on recursively

However, btrfs reserves space at the start for the boot loader. This space is more than GRUB needs to embed itself, and so we could use 1KB of it for an environment block.

In any case, this is not a new problem that arose from using subvolumes, nor does it prevent booting (you get a spurious "Press any key to continue" prompt, but if you just ignore it it'll boot anyway). Downgrading to wishlist.

For reference here is Colin's post to grub-devel, no followups since 2011-02 it seems.

http://lists.gnu.org/archive/html/grub-devel/2011-02/msg00011.html

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Natty (development branch)
Release: 11.04
Codename: natty
grub2:
  Installed: (none)
  Candidate: 1.99~rc1-13ubuntu1
  Version table:
     1.99~rc1-13ubuntu1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ natty/universe i386 Packages

Same here. Seems to be a btrfs thing as I have never seen this and is the first time I have used btrfs.

Thanks, but there's no need to post further reproduction information to
this bug. This is a missing feature and we know about it.

I've also run into this bug. However, it's on a machine (server) with no GPU and no keyboard. It's a bit of an annoyance because it means that I'd need manual intervention to reboot the machine (e.g. after power failure, where it would usually come back up on its own).

Not to nag or anything... but it would be nice if my bootup were unattended. I'll leave a keyboard atop my server until it's fixed.

I think you can probably make it unattended for the time being by
editing /etc/grub.d/00_header, commenting out the following lines with a
leading # sign on each line, and then running update-grub:

  cat << EOF
  if [ -s \$prefix/grubenv ]; then
    set have_grubenv=true
    load_env
  fi
  EOF

This has the effect of disabling features like savedefault and the
system that forces the menu to be displayed if the previous boot failed;
but you aren't getting those features on btrfs right now anyway.

Thanks for the tip, Colin. However, I think simply removing my GPU had the same effect. It reboots unattended now.

Confirmed here in natty final version.

Confirmed in natty final (64bit) too.

See comment 8, and please don't post further confirmation messages to this bug report.

With the risk of sound like another "me too, waa waa", I just want to ask a question based on the piece of info in #5 ("and so we could use 1KB of it for an environment block") compared to the piece of info on https://help.ubuntu.com/community/btrfs ("take care to keep about 1 Mib space free at the beginning of the disk").

Will doing this (keeping a meg free at the beginning of the disk) work around this semi-error? I forgot to do so when installing, and while it installed just fine, I ended up with this error message at boot. Just want to know if re-installing with a bit of space reserved in the beginning would help.

Sorry if I'm butting in where I should keep quiet :)

Nevermind, on closer inspection, my disk has exactly 1 MB free at the beginning, as it's been partitioned with ubiquity and therefore follows the best-practice of 4k properly aligned sectors.

So to answer my own question: No, this does not change this particular issue - these two things are not related :)

Yet again confirmed - I added a new btrfs at the end of my disk - going to try again in ext4. Shame!

I have a multi-boot system. Ubuntu Natty is on an ext4 partition. Boots with no error. Xubuntu 11.04 is on a btrfs partition and upon boot I get the same the error message:

'sparse file not allowed.
press any key to continue'

As Colin pointed out in #8, there's no need to add any more confirmations and "me too"s - the bug is known and being attended too.

I think it's a bit strange you consider this bug 'wishlist'. In server environment, where remote reboot is a must, it's quiet a showstopper. You might say no one using btrfs on servers. Maybe, but many servers using reiser (which is also affected).

Not booting after upgrade, well... I think its a very serius bug, not a 'wishlist'.

In my tests this did not actually impede automatic booting even though
it claims to require input.

In any case, new feature = wishlist. You should not take that to mean
that I consider it low priority.

Correctly booting an operating system is a wish list :)
Is this effecting boot times?

First time trying btrfs and I got the same error right after grub menu:
"error: sparse file not allowed. Press any key to continue ..."

I had another problem with the package apt-xapian-index refusing to configure on upgrade so I removed it and now the system merely hangs on the error above for a few seconds before booting without pressing any key ...

So is this a grub2 bug or a python bug?

Thanks.

Sorry for the "me too" comment, but I can confirm the bug for Oneiric beta 2.
Just so you know, because Oneiric wasn't mentioned yet.

First time trying btrfs and I got the same error right after grub menu:
 "error: sparse file not allowed. Press any key to continue ..."

same problem

after a few seconds the system boots but it is a bit sinister . . to have this message greeting users

Same problem in final version of Oneiric.

Same problem in Ubuntu 11.10 32bit

Is there a way to get grub2 to ignore this error?

This affects me (oneiric ocelot, amd64).
Can anybody test it on ubuntu precise(pre-alpha)?
If this error is still present in precise, it could be fixed before precise final will be released.

Same problem in Ubuntu 11.10 32bit

I justclean installed 11.10 in / using btrfs and got same error
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000585b6

   Device Boot Start End Blocks Id System
/dev/sda1 * 261316608 312580095 25631744 7 HPFS/NTFS/exFAT
/dev/sda2 237316094 261316607 12000257 5 Extended
/dev/sda5 257316864 261316607 1999872 82 Linux swap / Solaris
/dev/sda6 237316096 257316863 10000384 83 Linux

Partition table entries are not in disk order

I have the same problem with Precise Pangolin 12.04 Alpha 1 and a btrfs partition : immediately after the BIOS screen, I see a message "error: sparse file not allowed". After a few seconds, the Linux boots starts successfully.

Every time I boot Ubuntu 11.10 on btrfs, I have to "press any key to continue". It is very annoying!

Well, seems it boots even without pressing a key. But it boots too long...

There are some other problems, not sure what they are.
I installed Oneiric on an BTRF partition and it has trouble booting, after
pressing the key it goes back to the BIOS quite often.
On the exact same machine, reinstalling to an EXT4 filesystem and it boots
every time.
I realize that this is not scientific or enough for a bug report, but maybe
it will be familiar to someone else.
Regards
Wilbur

On Wed, Dec 7, 2011 at 11:26 AM, Andrey Zaytsev
<email address hidden>wrote:

> Every time I boot Ubuntu 11.10 on btrfs, I have to "press any key to
> continue". It is very annoying!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/736743
>
> Title:
> environment block not implemented on btrfs
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/grub/+bug/736743/+subscriptions
>

Same problem.

Ubuntu 12.04 LTS Beta 1 - 64 bits
Fresh install on btrfs formatted from Ubiquity

$ mount
/dev/sda1 on / type btrfs (rw,subvol=@)
...
/dev/sda1 on /home type btrfs (rw,subvol=@home)

same problem on 32bit 12.04 Beta using btrfs. Installed from USB Stick.

It affect Precise Pangolin too with btrfs. Very annoying.

i don't know if its allready in there but btrfs should definately be marked as experimental in the final LTS if the problem persists until release

Just installed Precise Pangolin 64bit as a fresh install from USB using btrfs as filesystem for / and /home and have encountered the same issue.

Same problem.

Ubuntu 12.04 LTS Beta 1 - 64 bits
Fresh install on btrfs formatted from Ubiquity

$ mount
/dev/sda1 on / type btrfs (rw,subvol=@)

Linux maria 3.2.0-23-lowlatency #31-Ubuntu SMP PREEMPT Wed Apr 11 02:24:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

again "sparse file not allowed"
but my system is *not* booting.

Ubuntu 12.04 LTS Beta 2 - 64 bits
     (Linux ubuntu 3.2.0-20-generic #33-Ubuntu SMP Tue Mar 27 16:42:26 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux)
on fresh SSD with one btrfs partition in the root (and not in a subvolume, what was intended)

Colin Watson's fixed seems to work for me ... after commenting out the lines suggested in 00_header and running update-grub it seems to have cleared it ...

GPT partition table
1) non-fs (bios_grub)
2) swap
3) btrfs (root mount)

kubuntu 12.04 3.2.0-23-generic on a AMD64 cpu

Breakthrough!

Messing around with netdown in /etc/init.d/halt is a waste of time.

Shutting down like this:
  ifconfig eth0 down; shutdown -h now

WORKS!

Gah, wrong defect, ignore.

Confirmed in Ubuntu 12.04 LTS 64-bit (final release) using the native btrfs option in Ubiquity.

Ubuntu 12.04 LTS 32-bit Final Version, using the btrfs format option during Installation.
but still encounter the o.g. Error Message. After a few second (or pressing any key) the system is booting with no further problems

"me too" comments are not helpful. If you wish to make it known that you are affected by this, please check the "affects me" box at the top of the bug. This bug is well understood and needs no further input.

Same problem with Xubuntu 12.04 (Precise Pangolin):

$ sudo fdisk -l
Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000cb13b

   Device Boot Start End Blocks Id System
/dev/sda1 * 2048 48828415 24413184 83 Linux
/dev/sda2 48828416 52733951 1952768 82 Linux swap / Solaris
/dev/sda3 52733952 234440703 90853376 83 Linux
$

Quantal alpha 3 also affected...

1.5 years to apply 4-line long patch...
confirmed in 12.04.1

Well, it's not a patch. It's a workaround for those who have btrfs installed. The rest non-btrfs based systems still want those 4 lines. Please note that cjwatson is maintainer of grub2 and he proposed this as a dirty workaround not a solution that we can apply and upload into the archive.

Reading the documentation [1] it leads to believe that load_env is excluded from certain type of systems. Yet reading the code I did not find those guards (maybe they are not explicit). In any case, until blocklists are implemented for btrfs, load_env should not stall the boot. Showing warnings is fine, but should not stall the boot. load_env can fail for many reasons outside of grub's control, but I don't see why this is so important to require user input.

I will try this again with recent 2.00 packages.

[1] http://www.gnu.org/software/grub/manual/html_node/Environment-block.html

I don't like to comment when I don't have nothing to add, but I just did a 12.10 install with btrfs, and I would not consider "do not show an erroneous scary message to users that stalls boot every time" as wishlist/new feature.

The only wish here is "I wish this worked properly"...

+1

Confirmed that this still exists in released Quantal.

Still exist in kubuntu 12.10.

Just upgraded to Kubuntu 12.10 - again the bug. However commenting out the lines in 00_header does not work anymore?

I have commented out these lines:
#cat << EOF
#if [ -s \$prefix/grubenv ]; then
# set have_grubenv=true
# load_env
#fi
#EOF

and_

# if [ -n "\${have_grubenv}" ]; then if [ -z "\${boot_once}" ]; then save_env recordfail; fi; fi

I also did not forget to issue a
sudo update-grub
afterwards.

Any Ideas?

Comment 59:
The workaround did work for me on 12.10, but I only commented the first part (the lines from cat << EOF to EOF).

The second part wasn't needed.

On comment 60 : Works for me MINT 14

With a btrfs install, I started getting the grub screen with the error message:

'sparse file not allowed.
press any key to continue'

I tried the temporary "fix" by Colin on comment #10 which temporarily fixed the problem. After a few successfull boots without any error messages, I then began to get a different error message:

'recordfail...
press any key to continue'

I then tried what's suggested in bug 669481
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/669481
Unfortunately the problem was still there.
For now, everything is working ok. What I've done is follow the advice on comment #10 from this bug, but I've also removed the #s from /etc/grub.d/00_header where it says:

function recordfail {
   set recordfail=1
   if [ -n "\${have_grubenv}" ]; then if [ -z "\${boot_once}" ]; then save_env recordfail; fi; fi
}

Everything is working fine now.

Short of implementing btrfs environment-block support for GRUB, we need a better workaround that doesn't involve manually hacking config files.

The scripts in /etc/grub.d/ can determine the type of the root filesystem---we see this in /etc/grub.d/10_linux, assigning to GRUBFS---so there's no reason why the workaround Colin gave in comment 10 cannot be automated.

I'm attaching a proof-of-concept patch, against /etc/grub.d/00_header as of Quantal, that conditionalizes inclusion of the grubenv code on the type of the root filesystem. If "/" is on btrfs, then a warning is printed, and an alternate bit of code is put into /boot/grub/grub.cfg.

Ubuntu folks: Can we get something like this in, for the time being? The "sparse file not allowed" error prompt is a rough edge that *needs* to go away.

The attachment "Proof-of-concept patch against /etc/grub.d/00_header" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

I just rebuilt my system using Kubuntu 12.10. I thought I would try BTRFS. Now I get this same error message while booting. I hope this bug gets squashed soon.

It's been a bug for two years now. It has a known, easy to implement fix. If the ubuntu devs wanted to fix it they would have done it a long time ago.

On 13-02-21 03:10 AM, ill wrote:
> It's been a bug for two years now. It has a known, easy to implement
> fix. If the ubuntu devs wanted to fix it they would have done it a long
> time ago.

Indeed. It's this apathy for the real problems real users have that is
driving me away from Ubuntu. All new installs are Fedora now.

I guess they are too focused on tablets and TVs any more.

+1

I'm suffering from this as well, and I'm very often under the impression that Ubuntu's bug reporting system is there for getting users complains and le it be, not for solving them.

Over years I filled hundreds of bug reports here, almost all of them never got any solution nor fix, until the upstream fixed things someday, probably without having ever heard about bugs posted here :-/

I can't speak for Ubuntu maintainers, but this _is_ a wishlist-priority bug concerning a file system that's still considered experimental, and a patch was recognised just under a month ago. I've been annoyed by this bug as well, but I doubt a little patience will kill anyone at this point.

Aki Rossi, is reiserfs considered experimental? If you've read the previous comments, you are aware this affects more than just btrfs. That alone should bump the priority up a notch or two.

Also the fact that this bug is two years old means the time span for patience has long been left standing in the dust...

On 13-04-06 06:05 AM, Harald Glatt wrote:
> Also the fact that this bug is two years old means the time span for
> patience has long been left standing in the dust...

Patience for this bug to be fixed or patience with Ubuntu in general?

I know which one it is for me.

13.04 amd64

First HAPPY BIRTHDAY for this bug!!!

Found a cool technical upgrade, cannot press the key due usb keyboard to override the message. So i have to wait the full timeout.

Will this ever be fixed?

Error is also available in 13:10 (save file not allowed)
Perhaps eliminate mel?
After so many years, this can not be true.

Sorry, (spare file not allowed)

bug still not fixed in 14.04
:-(

Maybe I'm missing something(ubuntu specific?), but I can't believe no one mentioned this simple obvious workaround yet (tested to work on Gentoo with btrfs /boot on separate partition):

GRUB_SAVEDEFAULT=false

in your /etc/default/grub

(must rerun Grub after this change, depending on your OS (I'm not on Ubuntu): ie. (Arch/Manjaro)$ sudo update-grub or (Gentoo)# grub2-mkconfig -o /boot/grub/grub.cfg )

Now the `error: sparse file not allowed.` is gone because there's no attempt made to write to the file /boot/grub/grubenv anymore, as were the case when GRUB_SAVEDEFAULT=true

Optionally, also avoid using GRUB_DEFAULT=saved unless you understand what it does if you do. I'm using GRUB_DEFAULT=0 (to have the cursor always be positioned on the first entry in the menu)

Cheers.
E.

I'm copy/pasting relevant `info grub` here to save you some time(in case you were not going to look this up anyway):

`GRUB_DEFAULT'
     The default menu entry. This may be a number, in which case it
     identifies the Nth entry in the generated menu counted from zero,
     or the title of a menu entry, or the special string `saved'.
     Using the id may be useful if you want to set a menu entry as the
     default even though there may be a variable number of entries
     before it.

     For example, if you have:

     menuentry 'Example GNU/Linux distribution' --class gnu-linux --id example-gnu-linux {
        ...
     }

     then you can make this the default using:

          GRUB_DEFAULT=example-gnu-linux

     Previously it was documented the way to use entry title. While
     this still works it's not recommended since titles often contain
     unstable device names and may be translated

     If you set this to `saved', then the default menu entry will be
     that saved by `GRUB_SAVEDEFAULT' or `grub-set-default'. This
     relies on the environment block, which may not be available in all
     situations (*note Environment block::).

     The default is `0'.

`GRUB_SAVEDEFAULT'
     If this option is set to `true', then, when an entry is selected,
     save it as a new default entry for use by future runs of GRUB.
     This is only useful if `GRUB_DEFAULT=saved'; it is a separate
     option because `GRUB_DEFAULT=saved' is useful without this option,
     in conjunction with `grub-set-default'. Unset by default. This
     option relies on the environment block, which may not be available
     in all situations (*note Environment block::).

15.2 The GRUB environment block
===============================

It is often useful to be able to remember a small amount of information
from one boot to the next. For example, you might want to set the
default menu entry based on what was selected the last time. GRUB
deliberately does not implement support for writing files in order to
minimise the possibility of the boot loader being responsible for file
system corruption, so a GRUB configuration file cannot just create a
file in the ordinary way. However, GRUB provides an "environment
block" which can be used to save a small amount of state.

   The environment block is a preallocated 1024-byte file, which
normally lives in `/boot/grub/grubenv' (althou...

* grub does not write to btrfs because of its checksum/cow stuff.
* btrfs is aware but doesn't seems to care as it says on its FAQ: "grub needs btrfs to support a reserved area" (and not "btrfs needs to implement reserved area")
* ubuntu is hit by this problem for years but it is something for either grub or btrfs to solve.

I love this "Somebody else's problem" way to deal with complicated problems...

Both grub and btrfs devs seems to not want to fix this problem by themselves as it is not a problem that hit them directly. Only distros that glue them together that face this problem. So, a distro or a "volunteer expert devel user" (that's not me) might be the one that proposes the fix.

SLES and OpenSuSE already uses btrfs rootfs for some time. Does it mean that grub-once simply does not work with them (and they are fine with it)?

I'm no Btrfs nor grub specialist but it is difficult to understand why is to difficult to write 1k from grub in today's multi TB disks...

Thinking about btrfs:

Btrfs already support nodatacow for a single file (chattr +C). Probably this is not enough but a little more might be.

If nodatacow files does not use checksum, one more problem is solved. If not, maybe it is the case to implement a "chattr +K" for "disable checksum for file". Some metadata like ctime/mtime would be out-of-sync but this is a minor issue.

For snapshots, it deals with nodatacow file doing a one-time cow (it increases the reference count). Again, a new "chattr +n" for "duplicate file blocks on snapshot" would keep the file block dedicated for that "copy" (duplicating data). An alternative would be grub checking the "reference count" of grubenv and avoid a write if >1. In a "best effort", ubuntu should duplicate the grubenv file whenever its "reference count" is >1 on shutdown.

Maybe all too complicated...

Thinking about grub:

In old disk format, where the first partition starts at sector 63, I guess it is already difficult to have btrfs support in grub. The last time I tried, it failed to write all needed modules. So, writing to btrfs is the last problem to deal as there is no space even for reading btrfs. For new partitions, grub has plenty of space as the first partition starts at sector 2048. In this case, grub do have a spare 1k in 1M of space. So, load_env could accept an alternative storage location based on blocks or just after the last module. This might be easier than write to any FS out there. The only problem is that grub-editenv would need to write directly to the block device. This solution is ideal as it might solve all FS write problems related to load_env (and not only for btrfs).

And, for the record, include me in the "me too"s list of affected people.

I do not experience this in trusty. Is this still an issue?

Rolf, please show the partition table of the trusty system that you tested.

On Thu, May 26, 2016, 23:45 Rolf Leggewie <email address hidden> wrote:

> I do not experience this in trusty. Is this still an issue?
>
> ** Changed in: grub2 (Ubuntu)
> Status: Triaged => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/736743
>
> Title:
> environment block not implemented on btrfs
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/grub/+bug/736743/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: product=grub; status=New; importance=Undecided;
> assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=grub2; component=main;
> status=Incomplete; importance=Wishlist; assignee=None;
> Launchpad-Bug-Tags: apport-bug i386 iso-testing natty oneiric patch
> precise quantal raring running-unity
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: a-ansorge abdawson adel-abdullin amedee
> andrew-woodhead666 andrewkk andzaytsev arielm0rph atreju-tauschinsky
> blogspot brian-interlinx bubuta chris-std cjwatson crichton damahevi
> dandart danielbuus davidnielsen-deactivatedaccount eduardor-lanave
> emanuelczirai-deactivatedaccount ericdhh erlinda-urban fieroch funmaker-11
> gjditchfield grasscap hachre henrik-nyberg ignissport illumilore inaldo
> info-rothert jakobk jcwinnie jonkers kamahat kangarooo kiencke klaib
> knuckles lixo-geeksmith lorkki luizluca lun4tic lunarok manveru mathewc
> mcmichael-thomas meszaros-gergely nicolasdiogo oscarivera9 psusi r0lf skunk
> spamistrash swami-petaramesh terpstra007-gmail theoldfellow thomas-juberg
> wilbur-harvey xnox zatloukal-frantisek
> Launchpad-Bug-Reporter: atreju (atreju-tauschinsky)
> Launchpad-Bug-Modifier: Rolf Leggewie (r0lf)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: siretart
>

This is still an issue with grub 2.02.beta2-15 (on Manjaro OpenRC) - the fix mentioned above from Gentoo still works:

set GRUB_SAVEDEFAULT=false in /etc/default/grub & run update-grub

Not really. The issue is still present on trusty.

If your /boot is a btrfs, grub2 does not know how to save its env.

In order to reproduce:

While on grub menu, press c
Type: save_env xxx

Disabling GRUB_SAVEDEFAULT just disables the feature that needs save_env. It is not a fix.

this is hilarious!! How could this bug still present on Ubuntu 17.10 with btrfs!!!

Because it basically can't be fixed.

what is preventing the patch from #63 to be implemented? I am no grub wizard by a long shot, but the patch looks sane.

And I have to correct myself. When I spoke in #79, I had /boot on a separate ext4 partition so it would not be surprising that I did not run into this. I've now made a fresh bionic installation entirely on btrfs and I ran into this almost decade-old bug.

I would like to see a fix that would allow the Grub environment block to be relocated inside the EFI System Partition (VFAT file system so writing and reading should just work).

I tried to find how I could do that on my own, but that is anything but trivial.

OK so I actually found out how to do the above thing.

So apply the provided patch for /etc/grub.d/00_header.
Original used for patching is from Ubuntu 17.10 (GRUB 2.02~beta3-4ubuntu7.3).
Move or create your grub env block file to efi partition:
ubuntu original location: /boot/grub/grubenv
patch location: /boot/efi/EFI/ubuntu/grubenv
Run update-grub2 to create the new grub config.

I do not know what EFI specs or something like that
says abount using EFI partition for the GRUB env block,
but it DOES work for me.

Oh and this is not a complete solution in any way as there are those grub environment tools that you can use on runing system that would need a fix too. So final solution could be a setting on /etc/default/grub that controls between the default location and ESP location.

This same issue bit me using 18.04. I think this should really be reclassified as an installer bug.
Ubuntu has known for many releases that a single btrfs root partition does not work properly.
The installer should warn people when they use a single partition that is btrfs that grub cannot write to it and you may want a separate ext4 /boot partition to avoid problems.

I've given up on BTRFS and gone back to ext4 because of this issue. No one
is interested in fixing this.

On Wed, Jun 20, 2018 at 11:08 PM, Robert Hardy <email address hidden>
wrote:

> This same issue bit me using 18.04. I think this should really be
> reclassified as an installer bug.
> Ubuntu has known for many releases that a single btrfs root partition does
> not work properly.
> The installer should warn people when they use a single partition that is
> btrfs that grub cannot write to it and you may want a separate ext4 /boot
> partition to avoid problems.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1152839).
> https://bugs.launchpad.net/bugs/736743
>
> Title:
> environment block not implemented on btrfs
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/grub/+bug/736743/+subscriptions
>

Just create a small ext4 partition and have it mounted as boot. The rest can stay btrfs. I have done this and it works as expected.

This problem will never be fixed as long as everyone frames the others for this. You would have to get the grub people talk to the btrfs people.

Regarding Ubuntu, it should warn you at install about having boot on a btrfs partition.

Note however the disadvantage of this: if you create a snapshot of your btrfs system, the stuff in boot will not be included.

This has been the advice since day 1. It's obviously not what many want.
I'd expect that someone at Canonical might have a better chance at spurring
communication between GRUB and BTRFS than a mere end-user.

On Sun, Jun 24, 2018 at 7:25 AM, Lars Stockmann <email address hidden>
wrote:

> Note however the disadvantage of this: if you create a snapshot of your
> btrfs system, the stuff in boot will not be included.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1152839).
> https://bugs.launchpad.net/bugs/736743
>
> Title:
> environment block not implemented on btrfs
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/grub/+bug/736743/+subscriptions
>

SUSE has fixed this patching grub to use reserved area in BTRFS:
https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-grubenv-in-btrfs-header.patch?expand=1

Is anyone can explain why /etc/grub.d/00_header generate /boot/grub/grub.cfg like this by default for btrfs partitions? I have at least one laptop where it cause GRUB2 menu appear on every boot with 30 seconds counter:

function recordfail {
  set recordfail=1
  # GRUB lacks write support for btrfs, so recordfail support is disabled.
}
...
if [ "${recordfail}" = 1 ] ; then
  set timeout=30

Of course, there is several workarounds for this issue, but why 00_header was written like this in first place?

Thank you for reporting this bug to Ubuntu.
Ubuntu 11.04 (natty) reached end-of-life on October 28, 2012.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

For Information purposes only

Kubuntu 23.10

"error: sparse file not allowed. Press any key to continue ..."

It's not a problem, because a message appears for a few seconds and then the system boot continues by itself.

I added 2 lines to the Grub.
/etc/default/grub
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

/etc/fstab
/ btrfs defaults,subvol=@ 0 1
/home ext4 defaults 0 2
/boot/efi vfat umask=0077 0 1

fdisk -l
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Device Start End Sectors Size Type
/dev/sdX 2048 66447359 66445312 31,7G Linux filesystem ///system on btrfs
/dev/sdX 66447360 125042687 58595328 27,9G Linux root (x86) ///home on ext4
/dev/sdX 2048 1050623 1048576 512M EFI System ///boot/efi