[Bug 1220276] New: Multiboot installation using Agama (?) does not boot TW by default
https://bugzilla.suse.com/show_bug.cgi?id=1220276 Bug ID: 1220276 Summary: Multiboot installation using Agama (?) does not boot TW by default Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers@suse.de Reporter: locilka@suse.com QA Contact: jsrain@suse.com Target Milestone: --- Found By: --- Blocker: --- Created attachment 872963 --> https://bugzilla.suse.com/attachment.cgi?id=872963&action=edit Booting menu I've used a real bare-metal HW Beelink Mini Pro 12S in its default configuration. I've removed everything with fdisk and installed Fedora. Then I used Agama to install TW next to Fedora. Installation was successful, but when the system boots, it goes directly to Fedora. I can press F7 when booting and choose between Fedora/openSUSE, but it's not the default behavior. I'm not sure if this is the Agama (Storage) problem or TW problem in general or the HW is the problem. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c2 --- Comment #2 from Lukas Ocilka <locilka@suse.com> --- Created attachment 872966 --> https://bugzilla.suse.com/attachment.cgi?id=872966&action=edit Fedora mount points -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c3 --- Comment #3 from Ancor Gonzalez Sosa <ancor@suse.com> --- The big question here is whether this is specific to using Agama. I wonder if the same happens if TW is installed via YaST. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c4 Ancor Gonzalez Sosa <ancor@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ancor@suse.com --- Comment #4 from Ancor Gonzalez Sosa <ancor@suse.com> --- As far as I understand, this is not as much about mount points (I assume both distros are sharing the same EFI partition) as about EFI entries. If I'm not mistaken, neither YaST or Agama fiddle with efibootmgr these days to sort the EFI entries, I think that's delegated to the Grub2 package. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c5 --- Comment #5 from Lukas Ocilka <locilka@suse.com> --- Created attachment 872967 --> https://bugzilla.suse.com/attachment.cgi?id=872967&action=edit openSUSE mount points -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c6 --- Comment #6 from Lukas Ocilka <locilka@suse.com> --- If you compare, Fedora uses partition 1 as /boot/efi partition 2 as /boot openSUSE uses partition 1 as /boot/efi And BTW, openSUSE does not list Fedora anymore. I can try with plain TW. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 Lukas Ocilka <locilka@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mchang@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c7 --- Comment #7 from Lukas Ocilka <locilka@suse.com> --- Created attachment 872968 --> https://bugzilla.suse.com/attachment.cgi?id=872968&action=edit YaST logs from YaST-based Tumbleweed installation It behaves the same independently on Agama / YaST, Fedora boots automatically. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 Lukas Ocilka <locilka@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Installation |Bootloader QA Contact|jsrain@suse.com |qa-bugs@suse.de Assignee|yast2-maintainers@suse.de |screening-team-bugs@suse.de -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c8 --- Comment #8 from Lukas Ocilka <locilka@suse.com> --- Created attachment 872969 --> https://bugzilla.suse.com/attachment.cgi?id=872969&action=edit Screenshot - YaST Bootloader The option "Probe foreign OS" is on, but it still does not find the other system when openSUSE is being started. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 Chenzi Cao <chcao@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |bootloader-maintainers@suse | |.de -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c9 Gary Ching-Pang Lin <glin@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glin@suse.com --- Comment #9 from Gary Ching-Pang Lin <glin@suse.com> --- Could you paste the output of 'efibootmgr -v'? So that we can check the current bootorder. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c10 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |locilka@suse.com Flags| |needinfo?(locilka@suse.com) --- Comment #10 from Michael Chang <mchang@suse.com> --- I suspect that the issue arises from Fedora's use of BLS (Boot Loader Specification) in its grub.cfg for the linux boot entry, deviating from the native `menuentry'. Consequently, the parsing process encounters a challenge with /usr/lib/linux-boot-probes/mounted/40grub2, as BLS is not universally supported in grub. Fedora takes a unique approach by not utilizing /boot/efi for the fragments, further complicating the situation. Essentially, even systemd-boot fails to detect and multiboot it. To verify this hypothesis, could you please execute the following commands with root permissions:
since=$(date +"%Y-%m-%d %H:%M:%S") export OS_PROBER_ENABLE_DEBUG=y; grub2-mkconfig -o /dev/null journalctl --since="$since" > /tmp/os-prober.log
Kindly attach the os-prober.log file here for further analysis. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c11 Lukas Ocilka <locilka@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(locilka@suse.com) | --- Comment #11 from Lukas Ocilka <locilka@suse.com> --- Created attachment 873339 --> https://bugzilla.suse.com/attachment.cgi?id=873339&action=edit OS Prober log -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c12 --- Comment #12 from Lukas Ocilka <locilka@suse.com> --- Created attachment 873340 --> https://bugzilla.suse.com/attachment.cgi?id=873340&action=edit efibootmgr -v -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c13 --- Comment #13 from Lukas Ocilka <locilka@suse.com> --- Created attachment 873341 --> https://bugzilla.suse.com/attachment.cgi?id=873341&action=edit The currnet openSUSE Boot Menu -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c14 --- Comment #14 from Michael Chang <mchang@suse.com> --- (In reply to Lukas Ocilka from comment #11)
Created attachment 873339 [details] OS Prober log
As anticipated, the utilization of blscfg [1] is causing os-prober to be unable to extract the menu entry. Even if it were able to do so, our grub cannot currently handle it, given that the bls patch is currently specific to Fedora. The situation is further complicated when bls fragments are placed in a private partition from a different source. It's worth noting that this is not a bug but rather a missing feature. [1]
Mar 08 09:16:49 localhost.localdomain 40grub2[25288]: debug: parsing: ### BEGIN /etc/grub.d/10_linux ### Mar 08 09:16:49 localhost.localdomain 40grub2[25289]: debug: parsing: insmod part_gpt Mar 08 09:16:49 localhost.localdomain 40grub2[25290]: debug: parsing: insmod ext2 Mar 08 09:16:49 localhost.localdomain 40grub2[25291]: debug: parsing: search --no-floppy --fs-uuid --set=root 6e49bf93-019b-454b-a5f3-8c8d52193323 Mar 08 09:16:49 localhost.localdomain 40grub2[25292]: debug: parsing: insmod part_gpt Mar 08 09:16:49 localhost.localdomain 40grub2[25293]: debug: parsing: insmod fat Mar 08 09:16:49 localhost.localdomain 40grub2[25294]: debug: parsing: search --no-floppy --fs-uuid --set=boot 963E-202E Mar 08 09:16:49 localhost.localdomain 40grub2[25295]: debug: parsing: Mar 08 09:16:49 localhost.localdomain 40grub2[25296]: debug: parsing: # This section was generated by a script. Do not modify the generated file - all changes Mar 08 09:16:49 localhost.localdomain 40grub2[25297]: debug: parsing: # will be lost the next time file is regenerated. Instead edit the BootLoaderSpec files. Mar 08 09:16:49 localhost.localdomain 40grub2[25298]: debug: parsing: # Mar 08 09:16:49 localhost.localdomain 40grub2[25299]: debug: parsing: # The blscfg command parses the BootLoaderSpec files stored in /boot/loader/entries and Mar 08 09:16:49 localhost.localdomain 40grub2[25300]: debug: parsing: # populates the boot menu. Please refer to the Boot Loader Specification documentation Mar 08 09:16:49 localhost.localdomain 40grub2[25301]: debug: parsing: # for the files format: https://systemd.io/BOOT_LOADER_SPECIFICATION/. Mar 08 09:16:49 localhost.localdomain 40grub2[25302]: debug: parsing: Mar 08 09:16:49 localhost.localdomain 40grub2[25303]: debug: parsing: # The kernelopts variable should be defined in the grubenv file. But to ensure that menu Mar 08 09:16:49 localhost.localdomain 40grub2[25304]: debug: parsing: # entries populated from BootLoaderSpec files that use this variable work correctly even Mar 08 09:16:49 localhost.localdomain 40grub2[25305]: debug: parsing: # without a grubenv file, define a fallback kernelopts variable if this has not been set. Mar 08 09:16:49 localhost.localdomain 40grub2[25306]: debug: parsing: # Mar 08 09:16:49 localhost.localdomain 40grub2[25307]: debug: parsing: # The kernelopts variable in the grubenv file can be modified using the grubby tool or by Mar 08 09:16:49 localhost.localdomain 40grub2[25308]: debug: parsing: # executing the grub2-mkconfig tool. For the latter, the values of the GRUB_CMDLINE_LINUX Mar 08 09:16:49 localhost.localdomain 40grub2[25309]: debug: parsing: # and GRUB_CMDLINE_LINUX_DEFAULT options from /etc/default/grub file are used to set both Mar 08 09:16:49 localhost.localdomain 40grub2[25310]: debug: parsing: # the kernelopts variable in the grubenv file and the fallback kernelopts variable. Mar 08 09:16:49 localhost.localdomain 40grub2[25311]: debug: parsing: if [ -z "${kernelopts}" ]; then Mar 08 09:16:49 localhost.localdomain 40grub2[25312]: debug: parsing: set kernelopts="root=UUID=9bdb61d9-f5d8-4154-95bc-7c3f12f66b9a ro rootflags=subvol=root rhgb quiet " Mar 08 09:16:49 localhost.localdomain 40grub2[25313]: debug: parsing: fi Mar 08 09:16:49 localhost.localdomain 40grub2[25314]: debug: parsing: Mar 08 09:16:49 localhost.localdomain 40grub2[25315]: debug: parsing: insmod blscfg Mar 08 09:16:49 localhost.localdomain 40grub2[25316]: debug: parsing: blscfg Mar 08 09:16:49 localhost.localdomain 40grub2[25317]: debug: parsing: ### END /etc/grub.d/10_linux ### -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c15 --- Comment #15 from Lukas Ocilka <locilka@suse.com> --- Michael, I've just reproduced the problem without Fedora, but it will be the same also in a typical scenario: 1st disk: Windows 2nd disk: openSUSE. My system has three disks: 1. NVME 2. SSD 3. USB - When I install the first system the installed GRUB obviously sees only that first system only, this will be the case with Windows - When I install another system, be it openSUSE TW onto the second disk, then GRUB at the second disk will see both, the system on the first disk and the system on the second disk - The same with installing on the third disk, that one sees all three The problem is that the boot disk is always the first disk (NVME) and then it always automatically boots only from the first disk making selecting other system impossible. The only way is to manually change the booting disk in BIOS, I do that while booting. I was using Agama for these tests, but that one uses YaST Bootloader under the hood. Each installation has their own /boot/efi by default. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c16 --- Comment #16 from Ancor Gonzalez Sosa <ancor@suse.com> --- A couple of remarks, just for completeness. 1) This behavior is not Agama-specific. YaST does the same. 2) In the past, YaST tried to share the existing EFI in the system, even if it was not in the system in which (open)SUSE was being installed. At some point we decided to change that and create a new EFI partition in the target disk. That was advised by Raymund Will. See https://github.com/yast/yast-storage-ng/pull/877 and other links there. Some of the relevant content for (2) is at a Trello card. So let's me paste it here (with the poor formatting capabilities of Bugzilla):
What SLE-15-GA and SLE-15-SP1 do? ---------------------------------
When reusing an existing ESP, we prefer to use a partition in the root_disk. But if there is none there, we also accept reusing an ESP partition from another disk.
Is that right? --------------
I (Ancor) am not sure. The current implementation assumes (or seems to assume) that an EFI-compliant firmware will look for the ESP partition in any disk. So even with a multi-disk setup, there should be just one ESP in the system shared by all the operating systems, no matter in which disk(s) each operating system actually resides. But I'm not sure whether that is actually true or whether the real expectation should be that every disk should contain its own ESP shared only by the operating systems that reside in that particular disk.
What to do for SP2? -------------------
Steffen Winterfeld discussed this with Raymund Will and they agreed that ESP should only be reused if it is in the disk used for installation. That applies also to other boot-related partitions like bios_boot, PReP and Zipl. That is, never use any other disk. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c17 --- Comment #17 from Ancor Gonzalez Sosa <ancor@suse.com> --- Another remark (although this is in the area of yast2-bootloader in which I'm not the biggest authority). YaST (or Agama, for the discussed case) does not explicitly call efibootmgr or any similar tool to ensure the system boots from the installation disk on next boot. That's delegated to the corresponding command used to install Grub. See https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/grub_... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c18 Ancor Gonzalez Sosa <ancor@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rw@suse.com --- Comment #18 from Ancor Gonzalez Sosa <ancor@suse.com> --- (In reply to Ancor Gonzalez Sosa from comment #16)
That was advised by Raymund Will.
Adding him to CC, since I mentioned him. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1220276 https://bugzilla.suse.com/show_bug.cgi?id=1220276#c19 --- Comment #19 from Michael Chang <mchang@suse.com> --- I believe the issue Lukas encountered could be avoided if the system always reused an existing EFI system partition, even when installing on separate disks. However, I still prefer not to reuse an ESP that isn't on one of the target disks where the new system will be installed. This makes the setup easier to maintain since the boot disk is directly associated with the system, allowing for easier movement between systems. I also think Lukas's problem was partly due to odd firmware behavior. During grub2-install or shim-install, a new boot entry is registered to point to the new ESP and its bootloader. Additionally, this process reorders the BootOrder to prioritize the new entry, making the system boot the latest installation upon the next reboot. However, something disrupted the BootOrder, and I suspect it was the Fast Boot feature in UEFI. Fast Boot only initializes the subsystems needed for the top boot disk in the order. It seems the new boot entry was ignored because the boot disk order settings overrule the BootOrder settings. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com