[Bug 1101756] New: enable specification of custom GRUB_DISTRIBUTOR= in UEFI bootloader installation
http://bugzilla.opensuse.org/show_bug.cgi?id=1101756 Bug ID: 1101756 Summary: enable specification of custom GRUB_DISTRIBUTOR= in UEFI bootloader installation Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: x86-64 OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers@suse.de Reporter: mrmazda@earthlink.net QA Contact: jsrain@suse.com Found By: --- Blocker: --- Created attachment 777382 --> http://bugzilla.opensuse.org/attachment.cgi?id=777382&action=edit 15.0 y2logs from host ab250 YaST2 currently offers no opportunity to specify a custom name to facilitate multiboot hosts. It needs one. Because it does not, e.g. when installation of Leap follows installation of Tumbleweed, the previous UEFI configuration is destroyed. The BIOS boot manager may or may not accommodate a proper selection of the preferred choice from the EFI/ESP partition. In the Leap follows TW case I just tried with an Asus B250M-C/CSM Kaby Lake motherboard with AMI BIOS version 1205 of 2018-05-11, the BIOS did not. As I normally do during installation, I deselected probe foreign OS. In attempting to avoid this overwrite, during installation of 15.0 I used vi to edit /mnt/etc/default/grub to include GRUB_DISTRIBUTOR="opensuse150". Actual bootloader installation at the end of overall installation changed it to GRUB_DISTRIBUTOR=, with the result that next boot only offered 15.0 to the exclusion of TW's /boot/grub2/custom.cfg which contains the custom stanzas for the other installed distros. I was forced to "choose" only 15.0 at next boot. I did work around that by using e on the 15.0 stanza to specify the TW kernel and initrd. Current EFI boot configuration: # efibootmgr BootCurrent: 0000 BootOrder: 0000,0001,0002 Boot0000* opensuse Boot0001* debian Boot0002* UEFI OS Expected EFI boot configuration subsequent to 15.0 installation was: # efibootmgr BootCurrent: 0000 BootOrder: 0000,0001,0002,0003,0004 Boot0000* opensuseTW Boot0001* debian Boot0002* ubuntu Boot0003* opensuse150 Boot0004* UEFI OS -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101756 http://bugzilla.opensuse.org/show_bug.cgi?id=1101756#c1 Neil Rickert <nwr10cst-oslnx@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nwr10cst-oslnx@yahoo.com --- Comment #1 from Neil Rickert <nwr10cst-oslnx@yahoo.com> --- I'll just add some history of this, to the best of my recollection. This is based on my experience. With openSUSE 12.3, the distributor could be set in Yast bootloader. But it did not work in an installation. The installer only used "opensuse". I could use Yast bootloader on the installed system to change the distributor, and that worked. I think the "/etc/default/grub" that is saved during install did not use what was set for distributor during install. In 13.1, I think it worked for install. But I'm not completely sure of that. And it might have been 13.2. Some time later, probably during the 13.2 cycle, the distributor field was removed from Yast bootloader. There's probably an earlier bug report where I complained about that. You had to directly edit "/etc/default/grub" to change it. Using "distributor" would probably not work with Ubuntu. Although I have not tested it, I am under the impression that the Ubuntu "shim" is hard coded to use the directory "\EFI\ubuntu" in the EFI partition. Hmm, I actually have tested it. I currently have "deepin" installed for testing. It used the Ubuntu shim (in "\EFI\deepin"). But that Ubuntu shim depends on the files "grubx64.efi" and "grub.cfg" that are in "\EFI\ubuntu". For myself, I am now doing things in a way that does not depend on using distributor. However, I'm expecting your bug report to not get much traction. You should be able to create the "opensuse150" entry that you want by manually editing "/etc/default/grub" and setting GRUB_DISTRIBUTOR . And then make some small change in Yast bootloader (maybe a timeout change), and it should reinstall as you want. But I think the last that I tested this was when running Leap 42.1. For completeness, here's some output: # efibootmgr BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0002,0005,0008,000B,0001,0003,000F,000E,000A,0006,0007,0009 Boot0000* opensuse-secureboot Boot0001* ubuntu Boot0002* betasuse-secureboot Boot0003* deepin Boot0005* UEFI OS Boot0006* Generic Usb Device Boot0007* CD/DVD Device Boot0008* mageia Boot0009* Generic Usb Device Boot000A* CD/DVD Device Boot000B* systemd-boot Boot000E* UEFI OS Boot000F* ubuntu Both of those "ubuntu" entries boot to "deepin", because the "deepin" install put some of its boot files in the "ubuntu" directory. If I restore the original ubuntu boot files, then booting to the "deepin" entry will boot ubuntu. The "betasuse-secureboot" entry was created with manual editing of "/etc/default/grub" and then using Yast bootloader. It currently boots to 42.3, but with a menu that allows me to boot other systems. It's my backup in case the main boot entry fails. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101756 http://bugzilla.opensuse.org/show_bug.cgi?id=1101756#c2 --- Comment #2 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Neil Rickert from comment #1)
You should be able to create the "opensuse150" entry that you want by manually editing "/etc/default/grub" and setting GRUB_DISTRIBUTOR .
This bug is about not needing to do so (which I did do, no other choice), to not need to either F8/F12/F?? UEFI boot or edit a stanza at runtime on first boot subsequent to openSUSE installation, to have exactly the expected boot configuration from custom.cfg front and center immediately. The current situation produces the same result as installing Windows, usurping the existing boot configuration as a consequence of adding an OS to a multiboot system. To avoid this currently all but demands that install no bootloader be selected, then when booted, edit GRUB_DISTRIBUTOR and install bootloader either manually (vexing) or using YaST2, the only YaST2 difference being including the desired GRUB_DISTRIBUTOR instead of the generic template. What I have ATM: # efibootmgr BootCurrent: 0000 Timeout: 1 seconds BootOrder: 0000,0001,0004,0002,0005 Boot0000* opensusetw Boot0001* debian10 Boot0002* UEFI OS Boot0004* opensuse150 Boot0005* tubuntu Choosing 2 or 5 from the BIOS UEFI menu produces only a grub> prompt. The others produce functional grub menus. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101756 http://bugzilla.opensuse.org/show_bug.cgi?id=1101756#c3 --- Comment #3 from Neil Rickert <nwr10cst-oslnx@yahoo.com> ---
This bug is about not needing to do so ...
Yes. But that's hopeless. Too much depends on the firmware. On the box that I referred to above, the firmware changes the boot order unless I go into firmware settings and set the order there. And if I delete a UEFI boot entry, the firmware puts it back unless I also delete the associated ".efi" files. What I do is use "/etc/grub.d/40_custom" to make sure that every system can boot every other system. I usually do this via a grub "configfile" command, so it just uses the native grub configuration for that other system.
Choosing 2 or 5 from the BIOS UEFI menu produces only a grub> prompt.
You should be able to change what happens for 2 (the UEFI OS entry). That just boots with "\EFI\Boot\bootx64.efi". So copy to the boot files from your preferred system to "\EFI\Boot" in the EFI partition. When you install openSUSE, it will put its boot files there if it sees that no other system is using that directory. Otherwise openSUSE doesn't touch it. However, Ubuntu, deepin and Solus all ignore what is there and put there own boot files there regardless. What it amounts to, is that UEFI is a mess. There's no consistency between vendors or between operating systems. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101756 http://bugzilla.opensuse.org/show_bug.cgi?id=1101756#c5 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mrmazda@earthlink | |.net) | --- Comment #5 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Josef Reidinger from comment #4)
Well, we consider this "expert" option. We already discussed it in past and problem is during upgrade to refresh it properly, which e.g. for opensuse does not work well with tumbleweed
What's the problem just using it if user has modified GRUB_DISTRIBUTOR= to anything that has never been in a /etc/default/grub.rpmnew file? As it is fairly common for TW users to also be Leap users, maybe TW should have a different default GRUB_DISTRIBUTOR= than Leap, at least on UEFI installations?
or when using zypper dup for leap switch.
As an expert option, I should think sufficient a relnote that the multibooter admin needs to address this. Multibooters do expect some foibles due to configurations that QA can't test programmatically.
So because it is expert option, what should be possible to do, is to set it manually and then yast2 will ( should ) respect it and keep it as it was done by manual edit.
Does it make sense?
Depends on your meaning of manual I suppose. Simple presence of a non-standard GRUB_DISTRIBUTOR= on the target ought to be sufficient if it's an upgrade. If a new install, have linuxrc accept cmdline parameter e.g. GRUB_DISTRIBUTOR=os151p11 to incorporate in Grub2 installation, and/or as I tried, using vtty2 while installation proceeds, or even before installation to already formatted / starts, to put GRUB_DISTRIBUTOR=os151p11 in the target's /etc/default/grub for incorporation. Adding an input box on the bootloader options tab that defaults to opensuse and rejects any string that is found as a directory name on a current ESP partition root, unless it matches GRUB_DISTRIBUTOR= in /etc/default/grub if an upgrade, I would think doable as well. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101756 http://bugzilla.opensuse.org/show_bug.cgi?id=1101756#c6 Josef Reidinger <jreidinger@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #6 from Josef Reidinger <jreidinger@suse.com> --- I worry that working with ESP partition is done a layer lower then yast2-bootloader. Yast2 just checks that there is ESP partition, but do not modify it. It only calls grub2-install and grub2-mkconfig. But I agree that this change of GRUB_DISTRIBUTOR is a bug that should be fixed. So your manual edit of default/grub should be respected. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101756 http://bugzilla.opensuse.org/show_bug.cgi?id=1101756#c7 Felix Miata (offline until ???) <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Leap 15.1 |Leap 15.3 --- Comment #7 from Felix Miata (offline until ???) <mrmazda@earthlink.net> --- Try again for next Leap release: -> 15.3 (and TW). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101756 http://bugzilla.opensuse.org/show_bug.cgi?id=1101756#c8 --- Comment #8 from Neil Rickert <nwr10cst-oslnx@yahoo.com> --- This issue may be indirectly related to bug 1175906 and I'll add a comment to that this week (and switch it to 15.3). It is looking as if Leap 15.3 will be using the SUSE shim instead of the openSUSE shim. In my experiments, I have an EFI boot entry for "opensuse" that is used for 15.3, and an entry for "tumbleweed" that is used for Tumbleweed. This allows me to select which "shim" I am using for booting. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1101756 http://bugzilla.opensuse.org/show_bug.cgi?id=1101756#c9 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Leap 15.3 |Leap 15.4 --- Comment #9 from Felix Miata <mrmazda@earthlink.net> --- Updating to 15.4, since this didn't make it into 15.3. -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com