Grub2: Once set, stays set

English Install/Boot/Login
#1

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?

Thanks,

GEF

#2

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

Sounds more like an EFI BIOS option You are changing

#3

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.

#4

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

#5

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.

#6

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

#7

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

#8

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.

#9

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
#10

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

btrfs

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

ubenv

Thanks

#11

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)

#12

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

#13

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:


lsblk --output NAME,FSTYPE,LABEL,UUID,PARTLABEL,PARTUUID,MOUNTPOINT,SIZE

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)

#14

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?

Thanks,

GEF

#15

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

#16

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.

#17

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.