Bug 1653703 - can no longer specify boot target via either custom.cfg or grub2-set-default command
Summary: can no longer specify boot target via either custom.cfg or grub2-set-default ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-27 13:08 UTC by Bill Gianopoulos
Modified: 2019-01-30 15:02 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-30 15:02:40 UTC


Attachments (Terms of Use)
my /etc/grub2.cfg file (7.72 KB, text/plain)
2019-01-30 14:11 UTC, Bill Gianopoulos
no flags Details
All of my grub environment variables (213 bytes, text/plain)
2019-01-30 14:14 UTC, Bill Gianopoulos
no flags Details
output from set from grub (2.21 MB, image/jpeg)
2019-01-30 14:34 UTC, Bill Gianopoulos
no flags Details

Description Bill Gianopoulos 2018-11-27 13:08:41 UTC
I have a system I consider to be a guest system.  It runs both Windows and Linux and uses Grub2 as the bootloader.  I have always configured it using /boot/grub2/custom.cfg to specify "set default='Windows 10 (on/dev/sda1)'".  This makes the system work normally for my guests but allows me to run Linux when I wish.

This no longer works under rawhide, seemingly because of the blscfg support.  It seems whatever version blscfg decides is the latest version is what is booted regardless of the setting of default in custom.cfg.  This is unacceptable.

Comment 1 Bill Gianopoulos 2018-11-28 14:52:11 UTC
Some googling revealed that the new way to do this is via the command:

  grub2-set-default 'Windows 10 (on/dev/sda1)'

unfortunately this method fails as well.

Comment 2 Javier Martinez Canillas 2019-01-30 09:27:15 UTC
This works for me in Rawhide:

$ grub2-set-default "Windows Boot Manager (on /dev/sda1)"
$ grub2-editenv list | grep saved_entry
saved_entry=Windows Boot Manager (on /dev/sda1)

On reboot GRUB chooses by default the Windows boot option.

Comment 3 Bill Gianopoulos 2019-01-30 11:24:54 UTC
(In reply to Javier Martinez Canillas from comment #2)
> This works for me in Rawhide:
> 
> $ grub2-set-default "Windows Boot Manager (on /dev/sda1)"
> $ grub2-editenv list | grep saved_entry
> saved_entry=Windows Boot Manager (on /dev/sda1)
> 
> On reboot GRUB chooses by default the Windows boot option.

This does not work for me.  Although I get this result from the above:

$ grub2-editenv list | grep saved_entry
saved_entry=Windows 10 (on /dev/sda1)

and the menuentry line form my grub.cfg says 'Windows 10 (on /dev/sda1)'  it still defaults tothe first item in the list.

I wonder if this is because my fedora rawhide system, and hence the grub environment being used is on an external USB drive and the Windows install is on an internal SATA drive.

Comment 4 Javier Martinez Canillas 2019-01-30 13:33:16 UTC
(In reply to Bill Gianopoulos from comment #3)
> (In reply to Javier Martinez Canillas from comment #2)
> > This works for me in Rawhide:
> > 
> > $ grub2-set-default "Windows Boot Manager (on /dev/sda1)"
> > $ grub2-editenv list | grep saved_entry
> > saved_entry=Windows Boot Manager (on /dev/sda1)
> > 
> > On reboot GRUB chooses by default the Windows boot option.
> 
> This does not work for me.  Although I get this result from the above:
> 
> $ grub2-editenv list | grep saved_entry
> saved_entry=Windows 10 (on /dev/sda1)
> 
> and the menuentry line form my grub.cfg says 'Windows 10 (on /dev/sda1)'  it
> still defaults tothe first item in the list.
> 

Can you please share your complete grub.cfg file?

Also, can you please check what is the value of the default grub variable? (you can do this by entering into the grub prompt and executing the set command that list the env vars).

Comment 5 Bill Gianopoulos 2019-01-30 14:11:43 UTC
Created attachment 1525042 [details]
my /etc/grub2.cfg file

Comment 6 Bill Gianopoulos 2019-01-30 14:14:12 UTC
Created attachment 1525044 [details]
All of my grub environment variables

Comment 7 Javier Martinez Canillas 2019-01-30 14:20:50 UTC
Thanks for the info. I didn't ask for the grubenv though but rather for the "default" variable value, since that's used by grub to choose the boot option to be set as default.

As mentioned you could press Ctrl+c on the grub menu to get into the prompt and then execute the set command to see all the variables and their values.

What version of the package do you have installed? Also, this is a BIOS install, right? Can you please make sure that the latest version is installed by running grub2-install /dev/sda (or whatever block device where your grub is installed).

Comment 8 Javier Martinez Canillas 2019-01-30 14:22:11 UTC
(In reply to Javier Martinez Canillas from comment #7)
> Thanks for the info. I didn't ask for the grubenv though but rather for the
> "default" variable value, since that's used by grub to choose the boot
> option to be set as default.
> 
> As mentioned you could press Ctrl+c on the grub menu to get into the prompt
> and then execute the set command to see all the variables and their values.

Err, I meant just to press c above.

Comment 9 Bill Gianopoulos 2019-01-30 14:34:56 UTC
Created attachment 1525046 [details]
output from set from grub

Comment 10 Bill Gianopoulos 2019-01-30 14:45:34 UTC
Oh and I should mention that the grub config file was regenerated today by me rerunning /sbin/grub2-mkconfig

Comment 11 Javier Martinez Canillas 2019-01-30 14:49:31 UTC
(In reply to Bill Gianopoulos from comment #9)
> Created attachment 1525046 [details]
> output from set from grub

default is correctly set to Windows 10 (on /dev/sda1) so that's not the problem. Did you update to the latest version with grub2-install as I mentioned in Comment 7?

Comment 12 Bill Gianopoulos 2019-01-30 14:59:32 UTC
Thank you so much!

I did a:

  sudo /sbin/grub2-install /dev/sdb

and now everything works as intended.

Comment 13 Javier Martinez Canillas 2019-01-30 15:02:40 UTC
Glad that it's working, we can close this bug then.


Note You need to log in before you can comment on or make changes to this bug.