Install from openSUSE-13.2-DVD-Build0019-i586.iso does not show a grub2 menu and boots directly into 13.2 on sda3. On the very first boot the grub2 menu showed a choice to boot openSUSE 13.1 installed on sda2. Not any more. Immediately after grub2 starts it flashes “error : sparse file not allowed” before booting 13.2.
Is it possible to replace grub2 with legacy grub? That was not a choice during installation.
Remove the file /boot/grub2/grubenv and the menu should reappear.
This is a bug/limitation in grub2’s btrfs support.
https://bugzilla.opensuse.org/show_bug.cgi?id=849718
Is it possible to replace grub2 with legacy grub? That was not a choice during installation.
Yes, you can, but you have to install it manually. (with grub-install I suppose)
And you have to update the menu manually after installing new kernels IIANM.
Removed /boot/grub2/grubenv but nothing changed. I will try the solution suggested in the bug report. It’s almost one year since the report was filed.
Following the instructions in the bug report…
I fixed the grub menu problem by booting with a live USB and commenting out the lines below in /etc/grub/00_header as described here: http://www.barryprice.co.uk/2012/05/04/fun-with-btrfs/
cat << EOF
if -s \$prefix/grubenv ]; then
load_env
fi
EOF
…however /etc/grub/00_header does not exist. I (as root) invoked…
cat /etc/grub/00_header
cat : /etc/grub/00_header: No such file or directory
I suppose I could re-install 13.2 using ext4 as the file system. I’m not sure that was offered as an option. Or I could delete my 13.1 installation on sda2 by reformating the entire drive. A somewhat bothersome solution in either case. Any further suggestions would be appreciated.
It’s /etc/grub**.d**/00_header.
Thanks for the quick response. Yes indeed that file does exist. However the lines I am supposed to comment out
cat << EOF
if -s \$prefix/grubenv ]; then
load_env
fi
EOF
do not exist. But of course the solution was for a 13.1 install while I am working with 13.2 install. I think I’ve spent enough time on this problem. Thanks again.
On current Factory there’s this instead, starting at line 53:
cat << EOF
if -f \${config_directory}/grubenv ]; then
load_env -f \${config_directory}/grubenv
elif -s \$prefix/grubenv ]; then
load_env
fi
EOF
Should be the same on 13.2, so try to remove those lines.
But as this only loads grubenv if it exists, I somehow doubt that would make a difference.
Anyway, you probably should add a comment to the bug report that you have this problem on a fresh 13.2 installation.
This definitely does not happen on most systems.
I only ever saw it once on my 13.1 system using btrfs as (only) filesystem, but never again after removing grubenv…
Additional me toos won’t help here. It is clear why it happens but unfortunately it is not cleat what can be done. We want some place to store environment for grub that is easily identified at boot time. The ideal place for this is filesystem with UUID, and grub can easily search for UUID. Unfortunately grub does not implement support for writing to advanced devices or filesystems like RAID, btrfs or zfs. So it can neither reset boot once flag, nor save current selection. Storing it outside of filesystem poses problem of identifying where environment is located. Implementing full write support for everything is not going to happen over night if ever. There could be solution for specific scenarios (like using ESP on EFI systems) but not in general case. Resetting boot once flag from Linux is only partial solution that won’t work if Windows was selected. Using separate /boot partition with ext2 is not always possible, especially in case of dual-/triple-/… boot case, where you do not have easy way to create additional partition.
So sorry - I really do not know what can be done. The only thing that can be done to prevent this is to block setting boot once flag if /boot/grub is on known unsupported device. This means - no support for selecting next boot option on reboot. But at least this will not break user’s systems.
Yes, I am aware of that.
But IMHO this particular problem (“error : sparse file not allowed”) is not at all related to missing write support or grub2-reboot, and appears to be specific to btrfs.
The boot menu is not shown because of that error, not because any boot entry is set to be booted in grubenv.
I.e. the problem here is read support, not write support (or the lack thereof).
OK you are right; I mixed two issues. In this case there are actually two problems. Why grub2 fails to read grubenv (it could be related to btrfs features) and why grub2 does not display menu. The latter should actually not happen for all I can tell.
My “simple” solution was.
I sure love having choices. But so far everything works.
As indicated in comment 77 at https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/736743 the best workaround is to put in /etc/default/grub the line
GRUB_DEFAULT=0
(the default value of GRUB_DEFAULT) and reinstall grub by
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
To get rid of the error message itself, comment in /etc/grub.d/00_header the lines
cat << EOF
if -f ${config_directory}/grubenv ]; then
load_env -f ${config_directory}/grubenv
elif -s $prefix/grubenv ]; then
load_env
fi
EOF
However, this will miss some functionality once this bug will be fixed.
Well, IMHO the best (and easiest) workaround is to delete the file /boot/grub2/grubenv.
To get rid of the error message itself, comment in /etc/grub.d/00_header the lines
cat << EOF
if -f ${config_directory}/grubenv ]; then
load_env -f ${config_directory}/grubenv
elif -s $prefix/grubenv ]; then
load_env
fi
EOF
Not quite.
The error message appears when grub2 tries to write back grubenv, those lines load grubenv.
The error message itself is not really the problem though, the problem is that a boot entry is set in grubenv (which makes grub2 hide the menu and boot that one directly) and grub2 cannot reset grubenv.
But yes, removing those lines “fixes” the problem, as grubenv is ignored/not loaded at all then.
However, this will miss some functionality once this bug will be fixed.
The only missing functionality would basically be the ability to set a boot entry with grub2-once/grub2-reboot (e.g. via KDE’s “Restart” menu), and to hide the boot menu on resume after hibernation (so you could boot a different boot entry on resume, which might cause data-loss).
A side-note: this is not a bug a per se, but a missing feature in grub2, namely missing write support for btrfs partitions. 
I prefered putting the line
GRUB_DEFAULT=0
in /etc/default/grub (and updating grub2) instead of deleting grubenv, because with it OpenSUSE permanently booted again without problems
and, what I cared most about, also from a hibernated state (though the message remained).
Removing /boot/grub2/grubenv resolved this error for the next boot only, but even then ignored hibernation.
Only commenting the lines, but not updating /etc/default/grub did not change anything.
There should be no problem with hibernation, as the hibernate/resume script that sets the boot entry also resets it again after resume.
It willl set the wrong entry though if you booted an entry from “Advanced Options” and hibernate. That’s a bug.
Removing /boot/grub2/grubenv resolved this error for the next boot only, but even then ignored hibernation.
What do you mean with “ignored hibernation”? That the boot menu is shown on resume? Or that the system didn’t resume at all?
And removing grubenv does _not fix this error for the next boot only, it fixes the problem until a boot entry gets set again in grubenv, e.g. when you select an OS to boot in KDE’s restart menu.
Only commenting the lines, but not updating /etc/default/grub did not change anything.
Well, maybe with GRUB_DEFAULT=saved grub2 will still read grubenv even if it is not explicitely loaded in 00_header. I’m not sure.
The system didn’t resume but instead the same “Sparse file” error occurred, displaying the error message and asking for any key press to continue.
Here
GRUB_DEFAULT=saved
was set. After removal of /boot/grub2/grubenv , this error was gone for the next boot only, but even then the system didn’t resume but instead the same error “Sparse File” error occurred.
Hm?
I never saw grub asking for any key press to continue on openSUSE.
IIANM, this has been removed years ago.
What grub2 version and/or distribution are you actually talking about?
If the system didn’t resume at all this is a different bug as indicated, totally unrelated to the “Sparse file” error or missing write support for btrfs.
But if the system doesn’t resume, the resume script is not called and therefore the boot entry is not reset.
Confirmed that setting
GRUB_DEFAULT
to everything but saved and deleting grubenv (instead of comment out those lines 00_header) fixes the issue as well.
The issue occurred on OpenSUSE 13.2 (and now Tumbleweed) with grub 2.02 beta2.
The thread about bug
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/736743
shows that the key press request and Sparse File error often come along.
This bug report is 4 years old and from Ubuntu.
Why do you think this applies to current openSUSE versions?
Have you actually seen this key press request?
As I wrote, the version 2.02 beta2 in openSUSE 13.2/Tumbleweed does not ask for pressing a key, and not even version 2.00 in 13.1.
And I think this has even been removed upstream in grub2 itself years ago.
What does still apply is that grub2 cannot write to btrfs partitions, and therefore cannot reset the boot entry in grubenv (as mentioned). The “sparse file” error appears when it tries to write to the btrfs partition, but that message is not the actual problem. The message is a bit misleading though IMHO.
And again, for hibernating/resume this is being workarounded. A script is called on resume that resets grubenv and removes the boot entry (that’s in fact the same script that sets the boot entry on hibernation in the first place).
But if you boot a boot entry with “noresume” on the kernel command line (recovery mode e.g.) after hibernation, your system is not resumed at all, and this script is not called.
As I already indicated there is a bug that the wrong boot entry is set if you hibernate when you booted a kernel from “Advanced Options”, triggered by the “Boot snapshot” menu entry.
https://bugzilla.opensuse.org/show_bug.cgi?id=911243https://bugzilla.opensuse.org/show_bug.cgi?id=911243
As long as you boot the default kernel, hibernation/resume should work without any manual changes.
But if you hibernate after installing a kernel update (before you boot to the new kernel), this happens as well as you are in fact running a kernel from “Advanced Options” then.
The bug was reported four years ago but its status is still “Wishlist”.
Thus, as it is a problem of grub itself, it is unresovled.
Because the error, including the key press request, reproduced itself
as indicated at the bug report and the workaround applied as well,
I suspected them to be related.
So in theory there is a script executed at shutdown that prevents this error, but
in practice with
GRUB_DEFAULT=saved
the error occurred as described at the bug report.