Grub2: Once set, stays set

Hi, I’ve a newly installed dual-boot laptop, openSUSE 13.1 with KDE and Win7. When restarting, if I choose the OS that should boot next, it works fine. But after that, it continues to boot that same OS, every time, until I manually delete the “next” entry from /boot/grub2/grubenv.

The laptop is an HP 17-e118dx, great specs for the price. Yes, it comes with Win8 installed, and my install medium for Win7 is prior to Service Pack 1. That means I had to enable legacy support, and I didn’t use UEFI for either OS. (That’s an adventure described in another thread).

Are there any other details that would provide a clue as to why Grub2 gets “stuck” on one entry?



This is grub this does this??? Are you sure??

Sounds more like an EFI BIOS option You are changing

The “next_entry” line in grubenv doesn’t get wiped automatically after it’s used; you think the fact that I have an efi-capable system (set to legacy support) somehow prevents grub2 from updating its configuration file? It’s a small thing; I can just avoid invoking a next entry when I restart from KDE, but sometimes the small things rankle.

What file system you using. As I recall BTRFS writes are not supported in grub

Unlikely. If you are using “btrfs”, then there might be a problem of grub not being able to write to that file system. But I’m only guessing.

I wanted to keep it simple. Ext4, as the installer proposed.

So let use get this straight by merely select other then the default OS the next boot will select that OS again. Is that right? I must admit to being amazed lol

If I select openSUSE 13.1 just to save a few seconds on restart, that stays too. The difference is that in openSUSE, I can edit grubenv without rigmarole, to delete the next_entry line.

Please boot into openSUSE and show output of

/usr/sbin/grub2-probe --target fs /boot/grub2/grubenv
/usr/sbin/grub2-probe --target abstraction /boot/grub2/grubenv

Output of /usr/sbin/grub2-probe --target fs /boot/grub2/grubenv


Output of /usr/sbin/grub2-probe --target abstraction /boot/grub2/grubenv



On 2014-08-10 20:16, gfagan wrote:
> Output of /usr/sbin/grub2-probe --target fs /boot/grub2/grubenv
> btrfs

So what you said yesterday:

|> I wanted to keep it simple. Ext4, as the installer proposed.

is not true, you have btrfs. That’s your problem…

Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

I doublechecked; if I run the partitioner, it clearly shows ext4

On 2014-08-11 00:46, gfagan wrote:
> I doublechecked; if I run the partitioner, it clearly shows ext4

Ok, please run this commands in a terminal:


and paste it all here, from initial command prompt, to last command
prompt, in a single mouse sweep, and please do so inside code tags (the
‘#’ button in the forum editor).
See photo

Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Hi Carlos, I appreciate your willingness to help me. Sorry I disappeared for a couple of days (houseguests) and sorry I reported wrong information (checked wrong computer). I do have BTRFS, not what I intended but I’ll live with it now. Does BTRFS prevent Grub2 from wiping its next_entry variable on its own?



I think so. As far as I know, grub2 is unable to write to “btrfs” file systems. Presumably that will be a future enhancement.

Thanks for the info. I understand BTRFS is still under development. Last time I played around with it, I did so on purpose, now I can’t remember what was going through my head when I clicked install on this machine. But all my data lives on the NTFS partition, so worst case scenario is a reinstall.

In my experience it is stable.

But the problem is not because btrfs is still under development, but because grub2’s btrfs support is not complete yet.