[Bug 1226122] New: TW installation leaves /boot empty
https://bugzilla.suse.com/show_bug.cgi?id=1226122 Bug ID: 1226122 Summary: TW installation leaves /boot empty Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Installation Assignee: yast2-maintainers@suse.de Reporter: mario_bz@mgtech.com QA Contact: jsrain@suse.com Target Milestone: --- Found By: --- Blocker: --- Created attachment 875388 --> https://bugzilla.suse.com/attachment.cgi?id=875388&action=edit zypp log from installation Installing TW from June 7 image. I select not to install any boot manager because I use Refind on Mac. Note I have installed Opensuse and TW this way for 15 years on multiple macs, leaving Grub out. In all cases installation always worked fine and booted, the last fresh TW install 2 years ago is still good. I decided to do a clean install of TW to check on other problems I am having. However, although the kernel is placed in /usr/lib/modules, the/boot directory is left empty except for the kernel cleanup script. I tried: 1. Copying my working kernel from a TW to /boot and /usr/lib/modules. I was able to boot that kernel. While booted I did a force installation of the kernel in YAST, but again, nothing was put into /boot. 2. I reinstalled using both btrf which I normally use, and xfs to see if btrfs was the issue. No change. I searched for hours trying to find this issue and found someone had the same thing after updating, that was a couple of years ago and they just added symlinks. I my case, I could not do that because initrd modules were missing which are not symlinks. Since I cant find anyone having this issue recently, I am assuming it's related to the fact I selected not to install boot manager. At this point I can't get a new install working. Some people really need to install without a boot manager, Opensuse and TW made it easy. I assume it's not a design change since it would make no sense to leave /boot empty. If you want any logs, please let me know where they are, I could not find an installation log. I attached the zypp log I found. It does not have a reference to /boot anywhere. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 Mario Guzman <mario_bz@mgtech.com> changed: What |Removed |Added ---------------------------------------------------------------------------- OS|Other |openSUSE Tumbleweed -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c1 --- Comment #1 from Mario Guzman <mario_bz@mgtech.com> --- I found this line in the zypp log attached: # modprobe: FATAL: Module dm_multipath not found in directory /usr/lib/modules/6.9.3-1-default -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c2 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrmazda@earthlink.net --- Comment #2 from Felix Miata <mrmazda@earthlink.net> --- Created attachment 875394 --> https://bugzilla.suse.com/attachment.cgi?id=875394&action=edit y2logs from host ab560 I just did a minimal NET basic-based detailed package selection installation of 20240607 selecting no bootloader and no filesystems to mount other than /dev/nvme0n1p26 /, and nothing was put in /boot/ to go along with the 6.9.3 kernel in /usr/lib/modules. I chrooted into it and rpm installed longterm 6.6.32 kernel, and all I could find happened was a do_purge_kernels landed in /boot/, and /usr/lib/modules/6.6.32-2-longterm was populated. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c3 --- Comment #3 from Felix Miata <mrmazda@earthlink.net> --- I forgot to mention, the rpm kernel-longterm installation complained there was no ESP - same thing on two separate lines. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c5 --- Comment #5 from Felix Miata <mrmazda@earthlink.net> --- The installer needs to be adapted to receive input related to "not managed" and what the results of kernel and dracut installation should include, such as radio buttons or checkboxes for /boot/, /boot/efi/, neither, discrete filesystem, etc. handled through /etc/alternatives or /etc/sysconfig. What caused do_purge_kernels to land in /boot/ when rpm installed kernel-longterm? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c7 --- Comment #7 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Thorsten Kukuk from comment #6)
the kernel must be in the location where the selected bootloader needs it, not in a random place.
Indeed. Since sometime last century, kernels and initrds have somehow managed to be installed to a standard location without necessity of having a bootloader installed. Added standard location(s?) haven't changed that. It's simply necessary now to declare which standard location in which to locate kernel and initrd when installed. Bootloader dedicated to a single OS isn't any more necessary now than historically. Installing sans bootloader is not reason to install no initrd anywhere. If the installation system isn't yet equipped to accept input WRT boot files location, then it should default to the traditional location. "Not managed" shouldn't be taken to mean don't put any anywhere that the existing bootloader on a multiboot system can find them. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c8 --- Comment #8 from Mario Guzman <mario_bz@mgtech.com> --- I don't think I made myself clear. My Tumbleweed installs from July 2022 all have /boot populated. Some symlinks to /usr/lib/modules/... They update just fine. I installed them the exact same way I tried this time. Each time the partitions were reformatted. I am doing the exact install I have done for many years. All without a boot manager during installation. Now, nothing is in /boot so it's no longer bootable. And no where is there an initrd, not even in /usr/lib/modules.. Either some major layout change occurred since July 2022 which I cannot find info about, or there is something wrong with the installation process. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c9 --- Comment #9 from Mario Guzman <mario_bz@mgtech.com> --- Are you saying /boot is always empty now? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c12 --- Comment #12 from Mario Guzman <mario_bz@mgtech.com> --- OK here is YAST logs. I had no idea YAST was involved during initial installation. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c13 --- Comment #13 from Mario Guzman <mario_bz@mgtech.com> --- Created attachment 875411 --> https://bugzilla.suse.com/attachment.cgi?id=875411&action=edit YAST log directory -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c14 --- Comment #14 from Mario Guzman <mario_bz@mgtech.com> --- Created attachment 875412 --> https://bugzilla.suse.com/attachment.cgi?id=875412&action=edit zypper.log if it helps -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c15 --- Comment #15 from Mario Guzman <mario_bz@mgtech.com> --- Thank you for looking into this. I can't stress enough I had started with Opensuse 20 years ago and used Grub. Then about 15 years ago switched from Grub to Refind for multiboot Linux/Mac and since always installed Opensuse/Tumbleweed with no boot manager and never had this problem. /boot always contained modules and not empty. Last full clean TW install was July 2022 and I did not have this problem. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c16 --- Comment #16 from Mario Guzman <mario_bz@mgtech.com> --- Created attachment 875413 --> https://bugzilla.suse.com/attachment.cgi?id=875413&action=edit y2logs All except the y2logs were accessed from a different system while the problem TW was not booted. They are from the problem TW system so they are correct. Since save_y2logs must be run in the system with the logs, I booted problem TW using copied system kernel 6.8 which does not match the TW kernel 6.9.3 in usr/lib/modules/. Hopefully this is not an issue, if it is there is no way to get those logs since the 6.9.3 kernel wont boot since nothing for it is on /boot. Hope that makes sense. Thanks again! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c17 --- Comment #17 from Felix Miata <mrmazda@earthlink.net> --- I had no problem getting kernels installed, as this installation like all mine is in a multiboot environment, precisely why no bootloader is wanted. Current state: # rpm -qa | egrep 'nel-def|nel-lon|grub|boot|tlets' | sort efibootmgr-18-1.6.x86_64 kernel-default-6.9.3-1.1.x86_64 kernel-longterm-6.6.32-2.1.x86_64 ruby3.3-rubygem-cfa_grub2-2.0.0-1.22.x86_64 suse-module-tools-scriptlets-16.0.44-1.1.x86_64 systemd-boot-255.7-2.1.x86_64 yast2-bootloader-5.0.10-1.1.x86_64 # ls -gGl /boot/ total 117304 -rw------- 1 22703918 Jun 10 03:27 .initrd-6.6.32-2-longterm1 -rw------- 1 22916356 Jun 10 14:02 .initrd-6.9.3-1-default1 lrwxrwxrwx 1 22 Jun 10 14:04 initrd -> initrd-6.9.3-1-default -rw------- 1 22703918 Jun 10 03:27 initrd-6.6.32-2-longterm -rw------- 1 22916356 Jun 10 14:02 initrd-6.9.3-1-default lrwxrwxrwx 1 22 Jun 10 14:04 initrd-cur -> initrd-6.9.3-1-default lrwxrwxrwx 1 24 Jun 10 03:28 initrd-lt -> initrd-6.6.32-2-longterm lrwxrwxrwx 1 23 Jun 10 14:04 vmlinuz -> vmlinuz-6.9.3-1-default -rw-r--r-- 1 14248304 May 25 13:52 vmlinuz-6.6.32-2-longterm -rw-r--r-- 1 14625136 May 30 04:00 vmlinuz-6.9.3-1-default lrwxrwxrwx 1 23 Jun 10 14:04 vmlinuz-cur -> vmlinuz-6.9.3-1-default lrwxrwxrwx 1 25 Jun 10 03:25 vmlinuz-lt -> vmlinuz-6.6.32-2-longterm # Installing kernels with rpm via chroot was simple enough, but I had to run dracut manually for both kernels, and put vmlinuz and symlinks in /boot/ manually. I've changed /etc/sysconfig/bootloader' LOADER_TYPE="none" from none to grub, but done nothing yet I might anticipate it affecting. ATM on 6.6.32, uptime is 12:25. I forgot to shut it down before I left the house for 10 hours. I suspect, but haven't made plans to test yet, that the default installation selections by including sdbootutil-rpm-scriptlets and sdbootutil and not including suse-module-tools-scriptlets, and me not addressing those selections/deselection, that the system selected an alternate-to-traditional booting environment that requires nothing in boot, and having found no ESP selected for mounting, had nowhere to put anything outside /usr/lib/modules/, and may be the reason why the situation described in comment #3. I suspect absent ESP in UEFI installation possibly the only significant difference between mine and Mario's. Maybe next up here I should do another fresh installation that includes suse-module-tools-scriptlets and not sdbootutil-rpm-scriptlets or sdbootutil. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c19 --- Comment #19 from Mario Guzman <mario_bz@mgtech.com> --- Created attachment 875425 --> https://bugzilla.suse.com/attachment.cgi?id=875425&action=edit dracut and ls -l /boot log For #1, the --all parm is not valid, see the attached dracutlog file. Also, it would not do anything unless I added --force. Then it created initrd for 6.9.3 and left the previous items I manually added in /boot for 6.9.3. But still, it would not find 6.9.3 to boot, but still found 6.8.8 which I had previously added 2 days ago. /boot is at the bottom of the log, look at the dates. Only 2 were added by the dracut command. For #2, I don't know hot to boot legacy (I looked) and I don't think it's possible on a mac since they are UEFI only. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c20 --- Comment #20 from Mario Guzman <mario_bz@mgtech.com> --- Doing the same commands, I noticed suse-module-tools-scriptlets-16.0.44-1.1.x86_64 is missing. localhost:~ # rpm -qa | egrep 'nel-def|nel-lon|grub|boot|tlets' | sort efibootmgr-18-1.6.x86_64 kernel-default-6.9.3-1.1.x86_64 ruby3.3-rubygem-cfa_grub2-2.0.0-1.22.x86_64 sdbootutil-1+git20240514.56dc89c-1.1.x86_64 sdbootutil-rpm-scriptlets-1+git20240514.56dc89c-1.1.x86_64 sdbootutil-snapper-1+git20240514.56dc89c-1.1.x86_64 systemd-boot-255.7-2.1.x86_64 yast2-bootloader-5.0.10-1.1.x86_64 localhost:~ # ls -gGl /boot/ total 85508 lrwxrwxrwx 1 82 Jun 8 13:36 .vmlinuz-default.hmac-6.9.3-1-default -> /run/media/mario/Tumbleweed3/usr/lib/modules/6.9.3-1-default/.vmlinuz-default.hmac lrwxrwxrwx 1 82 Jun 8 13:38 .vmlinuz.hmac -> /run/media/mario/Tumbleweed3/usr/lib/modules/6.9.3-1-default/.vmlinuz-default.hmac -rw-r--r-- 1 7607956 Jun 8 13:50 System.map-6.8.8-1-default lrwxrwxrwx 1 71 Jun 8 13:16 System.map-6.9.3-1-default -> /run/media/mario/Tumbleweed3/usr/lib/modules/6.9.3-1-default/System.map -rw-r--r-- 1 279823 Jun 8 13:50 config-6.8.8-1-default lrwxrwxrwx 1 67 Jun 8 13:10 config-6.9.3-1-default -> /run/media/mario/Tumbleweed3/usr/lib/modules/6.9.3-1-default/config lrwxrwxrwx 1 55 Jun 8 13:45 initrd -> /run/media/root/Tumbleweed3/boot/initrd-6.9.3-1-default -rw------- 1 32648549 Jun 11 06:25 initrd-6.8.8-1-default -rw------- 1 32523394 Jun 11 06:25 initrd-6.9.3-1-default -rw-r--r-- 1 569 Jun 8 13:50 sysctl.conf-6.8.8-1-default lrwxrwxrwx 1 72 Jun 8 13:15 sysctl.conf-6.9.3-1-default -> /run/media/mario/Tumbleweed3/usr/lib/modules/6.9.3-1-default/sysctl.conf -rw-r--r-- 1 14457200 Jun 8 13:50 vmlinuz-6.8.8-1-default lrwxrwxrwx 1 68 Jun 8 13:17 vmlinuz-6.9.3-1-default -> /run/media/mario/Tumbleweed3/usr/lib/modules/6.9.3-1-default/vmlinuz localhost:~ -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c21 --- Comment #21 from Mario Guzman <mario_bz@mgtech.com> --- I finally got it to boot but there is obviously something missing in the installation that leaves /boot empty. Just a guess, but I think it's related to a missing suse-module-tools-scriptlets. I looked at Yast and found system-modules-tools is installed but not system-module-tools-scriplets. I needed your dracut command to create the initrd. I thought it would create all /boot modules but it only creates one file per kernel. None of the symlinks. In the logs above I noticed the my manually added links from /boot to /usr/lib/modules were wrong. These symlinks were the ones I manually added since the install left /boot empty. Once I fixed them, along with the new dracut generated file, it booted. What I am concerned about is if a kernel update will process correctly. I don't think so because it would not create one when I did a force update in Yast. Let me know what you would like next. Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c23 --- Comment #23 from Mario Guzman <mario_bz@mgtech.com> --- Just a guess: The problem is probably not in the script. It's the fact the script does not get installed. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c24 --- Comment #24 from Mario Guzman <mario_bz@mgtech.com> --- If suse-module-tools-scriptlets is required, I think I found the issue. I booted the installer on another machine and looked at what software programs are automatically selected. When a boot manager is selected, suse-module-tools-scriptlets IS checked. When a boot manager is not installed, suse-module-tools-scriptlets is NOT checked. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c25 --- Comment #25 from Mario Guzman <mario_bz@mgtech.com> --- I am pretty sure now the missing suse-module-tools-scriptlets is the problem. I went ahead and continued installing with the following: * Set boot manager to "NOT MANAGED" so no boot manager. * In software selection I located and added/checked suse-module-tools-scriptlets, this resulted in MANY dependencies added, including several YAST modules. Installation finished and booted normally! Although the machines are different they are both Macs, first one I was installing on has NVME SSD internal, the other normal internal SSD and HD. I don't think that makes any difference here although I will install this way on the first machine in a few hours just to make sure. So I think TW/OS has a problem when not installing boot manager (and no EFI partition specified?). This was not a problem in 2022 and prior. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c26 --- Comment #26 from Mario Guzman <mario_bz@mgtech.com> --- It is for sure the missing the missing suse-module-tools-scriptlets. I tested back on the first machine. I also adding a mount for /boot/efi to the efi partition. It made no difference. So boot manager not managed prevents the scriptets from being installed. On both systems I manually checked suse-module-tools-scriptlets during install and it added many more programs. Both now boot fine. So this is a problem with the installer when boot not managed is selected. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c27 --- Comment #27 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Felix Miata from comment #17)
next up here I should do another fresh installation that includes suse-module-tools-scriptlets and not sdbootutil-rpm-scriptlets or sdbootutil.
I did, with success. /boot/ fully populated with files for 6.6.32 and 6.9.3. y2logs available on request. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c28 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|TW installation leaves |TW installation with |/boot empty |bootloader not managed | |leaves /boot/ empty when | |suse-module-tools-scriptlet | |s not installed instead of | |sdbootutil-rpm-scriptlets --- Comment #28 from Felix Miata <mrmazda@earthlink.net> --- The following two packages conflict: sdbootutil-rpm-scriptlets suse-module-tools-scriptlets sdbootutil-rpm-scriptlets also conficts with grub2-x86_64-efi and grub2-i386-pc. In a bootloader not managed installation, without something selected from within the installer to specify which, first in alphabet is the apparent winner. Right now that something appears to be only using detailed package selection, and any of suse-module-tools, grub2-x86_64-efi or grub2-i386-pc selected. It seems to me the Boot detail page ought to have a type subselection for not managed that provides a way to select which kernel installation scripts need to be provided. That might be deleting not managed and adding two to replace it, a Boot Loader Specification style utility set (sdbootutil) and a traditional (grub) boot style utility set, which, like existing selections, are mutually exclusive. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c32 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mrmazda@earthlink | |.net) | --- Comment #32 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Lukas Ocilka from comment #29)
Created attachment 875434 [details] Bootloader settings
Guys, aren't you just picking the wrong bootloader choice? As the YaST team sees it, "Not Managed" means ... "not managed",
That depends on the meaning of "manage boot" I manage boot by configuring one bootloader among 3, 13, 23 or however many distros on one machine (using custom.cfg, in which stanzas are in the order I choose, in stanza quantity per installed system I choose, with the labels I choose, among other stanzas that load binaries not intended to load an installed OS). It really doesn't matter who calls what what.
but if you select "Systemd Boot", then it should really select the package you wish and use systemd.
That one bootloader works because some bootloader is able to find boot files in an expected location on some filesystem for each installed system in the machine, most logically in a location identified as boot! Normally that meant /vmlinuz (in openSUSE and various other distros) if a discrete filesystem, or /boot/vmlinuz, 8 bytes or 13 bytes. With BLS booting, we get e.g. /usr/lib/modules/1.2.3-4-default/vmlinuz, 41 bytes, not counting initrd's proportional increase, further bloating linu lines, making it harder still to fit on one line along with UUID in an editor window, or even fullscreen, or in a mailing list archive or forum post. It poses a considerably increased opportunity for error in an admin's single bootloader multiboot configuration management. "Not managing" bootloader to me does not mean admin accidentally discovers he needs to somehow determine how to get boot files into the expected location within each of the 19 / or boot filesystems, something he did not need to do previously. There's been a process for generations that gets boot files into the boot file location even if a bootloader is not installed. That is now broken because of an alternate boot location option which cannot be accounted for in the boot setup part of the installer, while becoming an odd man out among the 23 already installed OSes. Given BLS booting is the new kid on the block, maybe the default can be reverted to traditional by changing the alphabetic sort result by changing package names to e.g.: scriptlets-bl-aged scriptlets-bl-newer -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c33 --- Comment #33 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Josef Reidinger from comment #31)
If it is needed to have tools-scriptlets installed in that case it should be manually selected as installer cannot know what is needed in case no bootloader is required.
Bootloader not [managed,required] is not the same as boot is not required. We now have multiple possible boot paths that conflict each other. A boot path needs to be selected during the installation process. It shouldn't be hidden in detailed package selection. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c38 --- Comment #38 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Martin Wilck from comment #35)
(In reply to Felix Miata from comment #32)
That one bootloader works because some bootloader is able to find boot files in an expected location on some filesystem for each installed system in the machine, most logically in a location identified as boot!
Sorry, I am not getting this. Do you mean systemd-boot with "that one boot loader"? Did you select systemd-boot or not? And if yes, why? AFAICT systemd-boot abandons /boot, which is exactly what you rant about in the rest of your comment.
That one bootloader on my legacy booters is openSUSE's grub 0.9x (usually pre-Leap) using gfxboot with penguin=100, not grub2. On UEFI systems it is TW's grub2-x86-64-efi. I selected neither grub nor systemd-boot. I selected bootloader not manged, and efibootmgr, not knowing I also needed to make some additional selection necessary to be able to find kernel & initrd in a tradtional location. IIRC, I made no selection of anything else that I knew had anything to do with booting except for efibootmgr. Maybe if it needs to be known, all I selected can be determined from attachment 875394. (In reply to Alberto Planas Dominguez from comment #37)
if no bootloader is installed, seems that sdbootutil-rpm-scriptlets is preferred by the solver.
Again, installing neither grub components nor BLS-spec components does not equate to absence of files in some co-location necessary /to/ boot. As long as the error reported here remains substantially likely for any multibooter (or anyone who pre-partitions to his desires 100% supported, BTW), the boot selection portion of the installer's job is incomplete. "Not Managed" can no longer be allowed to equate no /bootloader/ is installed, regardless of intent to transition default to BLS location. It's not managed alright - it's random. The "Boot Loader Settings" page boils down to does a bootloader need to be installed, and if so which, not do we need linux and initrd installed somewhere when kernels are installed. The "Boot Loader" select list, or elsewhere in the "Boot Code Options", or radio buttons, or select list, or a novel tab, needs inclusion to somehow take into account where these two files need to go when neither GRUB2 nor GRUB2 for EFI nor Systemd Boot are selected, unless under the covers the scripts, "distro level", as Lukas wrote, can reliably determine the right choice reliably. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c40 --- Comment #40 from Mario Guzman <mario_bz@mgtech.com> --- In response to @Martin Wilck: @Mario, I reckon you didn't install systemd-boot and/or sdbootutil on the failing system? Do you have shim installed? I reckon /boot/efi did not exist on your system? No systemd-boot No sdbootutil No shim No /boot/efi directory in any linux, although there is an efi partition: I have an efi partition on the internal and external SSDs. Can boot from either using the Option key at startup (mac feature). They ONLY contain REFIND, and REFIND PLUS which provides a fantastic multiboot system that currently boots: * 4 Tumbleweed BTRFS partitions (for Virtualbox VM etc.) * Elementary OS (linux) * linux utility partition * 4 macOS partitions (for FreeSwitch development, I wrote the macOS wiki) * I have tested other linux distros for years using this layout. None of these systems are allowed to put anything into the EFI partition nor have a need to access an EFI. Thank you all, and Felix for the RPM command which provided me a starting point to find 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=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c41 --- Comment #41 from Mario Guzman <mario_bz@mgtech.com> --- Forgot to mention my other machine is similar but I also have Opencore, I can boot from refind or OC as needed. Tumbleweed boots from refind plus for years. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c44 --- Comment #44 from Mario Guzman <mario_bz@mgtech.com> --- I can’t have anything put into the efi other than what I put there. If any systems boot module were put there it would break the ability to boot anything from anywhere. Refind does not require any configuration about the systems it’s booting. I have had over 10 systems on internal and external and refind can be booted from internal or external and its finds everything and can boot them. This is fantastic for recovery and booting flexibility. This works so well because none of the OSs have anything in the efi. You can make a boot volume and move it between machines and boot anything anytime. None of the systems are dependent on the efi. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c45 --- Comment #45 from Mario Guzman <mario_bz@mgtech.com> --- There’s more, the executable can be called anything like refind on the internal, which can be set as a default boot. But on an external or internal you need to use the option key for, it must be BOOTX64 named, and the machine will find all of them. That prevents using s/efibootmgr. Requiring a system paired with an efi partition would be a disaster for me loosing all this flexibility and ease of recovery. These two machines are for development and so always serve multiple OSs. I am sure I’m not the only one since I work with the refind plus developer and know others have similar needs. If Linux needs to stop using /boot then a standard location should be established that contains all required boot modules in one place so boot managers like refind can accommodate them. Just nothing in efi required for booting. Hope this clears up what I am doing. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c46 --- Comment #46 from Felix Miata <mrmazda@earthlink.net> --- I've spent the past nearly 3 hours composing a reply to comment #39. I have no idea how long it will take to finish. This reply is a mental change of pace and sidetrack needed due to shortage of sleep since I discovered this bug report, and no sleep in the past 24. (In reply to Martin Wilck from comment #42) It's a workaround I don't like. It's not KISSing. Messing with selections, to see what actually occurs as a result of a given mouse click on the installer boot screen with a mouse that moves the pointer as any button is clicked has a propensity to make the screen reinitialize itself, re-enabling update NVRAM. The real issue is only one bootloader and one ESP is needed per computer. Allowing write access to an ESP, and even more to NVRAM, has a remarkable propensity to fubar a previously perfectly working boot system. Not KISS having multiple NVRAM entries. It seems no two UEFI BIOS are alike, except that they misfeature too many of the same bugs. Keeping the ESP inaccessible by not mounting it is insurance. When I want an irregular boot, I edit the regular stanza. When a system won't boot at all, I boot something else to access logs and proceed with repair. I don't not have an ESP on UEFI systems. I have one ESP on each UEFI computer (on normal boots). I just don't mount it to /boot/efi/ except on the boot control OS. Merging sounds like good plan. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c48 --- Comment #48 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Alberto Planas Dominguez from comment #47)
(In reply to Felix Miata from comment #46)
I've spent the past nearly 3 hours composing a reply to comment #39.
With the two scriptlet packages merged, I don't expect the results we observed would be reproduced, and so there wouldn't be anything needing changing in the installer. In the meantime, those privy to this report know the issues and workaround, and those that aren't should be able to find this with a /boot/ empty or equivalent search if necessary.
Oh ... I did not mean to sound rude in my comment. Did it read as rude?
When I meant that I did not understood your comment I was referring that I was failing to see the connection between what I saw as a bug in the new scriptlets package and your answer. I am assuming that is lack of context from my side.
Given the length of this report, it's understandable that some context may be or have been missed. I'm scrapping my reply to comment #39 as moot, for the reasons stated above. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c50 --- Comment #50 from Felix Miata <mrmazda@earthlink.net> --- As far as it goes. I always select generic role and detailed package selection, and deselect recommends before customizing selections. I got bit some time ago using this sequence with an installation that omitted zypper, libzypp or one or more of their requires that made zypper useless. So since then I always check that *zyp* and various personal necessities are selected, and taboo a few I wish omitted that would otherwise come from various patterns, like fonts I never want to see. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c52 --- Comment #52 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Martin Wilck from comment #51)
Anyway, I understand that neither you nor Felix like my suggestion from comment 42 ... note that with systemd-boot the ESP will be a much more important piece of the Linux installation, and not mounting it under Linux at all just won't work, AFAIU.
I don't expect to live long enough to see grub2-efi no longer supported. (In reply to Martin Wilck from comment #42)
Mario/Felix, have you considered to install just any bootloader but leave the option "Update NVRAM entry" switched off? I think this might just do what you want (not certain though).
It's neither KISS nor green, having bootloaders on every installation in multiboot environments. Multiple bootloaders offer an unnecessary avenue for a spontaneous appearance of some bug that causes a heap of hurt and lost time fo fix, meanwhile wasting bandwidth and media write cycles. Mine are not just PCs, but also, in a fashion, archives. Many installations are kept bootable well beyond their support lives, e.g.: # lsblk -o NAME,LABEL,MOUNTPOINT NAME LABEL MOUNTPOINT sda ├─sda1 ├─sda2 ├─sda3 boot03i256 /disks/boot ├─sda4 ├─sda5 05swapi256 [SWAP] ├─sda6 ├─sda7 ├─sda8 s131p08i256 /disks/s131 ├─sda9 home09i256 /home ├─sda10 s423p10i256 /disks/s423 ├─sda11 pub11i256 /pub ├─sda12 ulcl12i256 /usr/local ├─sda13 i256trixie ├─sda14 i256p14f40 /disks/f40 ├─sda15 mga6p15i256 ├─sda16 s123p16i256 ├─sda17 s122p17i256 ├─sda18 mga9p18i256 /disks/mga9 ├─sda19 i256p19sslo ├─sda20 i256p20f38 ├─sda21 s114p21i256 /disks/s114 ├─sda22 s132p22i256 ├─sda23 sTWp23i256 /disks/stw ├─sda24 i256bookworm ├─sda25 i256bullseye ├─sda26 ub22p26i256 ├─sda27 s155p27i256 /disks/s155 ├─sda28 s154p28i256 ├─sda29 i256p29f39 ├─sda30 s153p30i256 ├─sda31 ub20p31i256 ├─sda32 mga8p32i256 ├─sda33 ub24p33i256 /disks/ub24 ├─sda34 mga7p34i256 ├─sda35 s151p35i256 /disks/s151 ├─sda36 s156p36i256 / ├─sda37 fedovar ├─sda38 isos-i256 ├─sda39 rootantiX16 ├─sda40 antiX-i256 ├─sda41 s121i256 /disks/s121 └─sda42 mga4i256 /disks/mga4 # These are all pleasurably booting from 13.1's grub-0.97-194.1.2 with penguin=100 gfxboot, same as my numerous other PCs that continue legacy booting. What ain't broke don't need fixin. :) My UEFI's all boot via TW's EFI grub, though with a much less attractive and convenient grub menu. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c54 --- Comment #54 from Mario Guzman <mario_bz@mgtech.com> --- I know that there must be some rational for the changes, and since I multi boot, I may not be the “normal” user who installs Linux much like Windows where the system assumes it’s the only thing on the computer. However, Linux is used for much more such as development. In those cases multiboot is much more common, I sometimes have 10 OSs on one machine. For the past many years, since SUSE 7, I have had no trouble using it as my primary Linux. This is largely due to it not interfering with other systems. It installed easy, and could boot from other boot managers. I may have a more complex need since I boot MacOS and Linux natively. I only boot Windows under Linux Virtualbox rarely. I don’t use Grub since it’s a pain to maintain and the following ways I boot are much easier for me: • Refind Plus on internal SSD to boot multiple Linux and distributions on multiple Mac internal SSDs. It also allows booting macOS. • Refind Plus on external SSD to boot multiple Linux and distributions on multiple Mac internal and external SSDs. It also allows booting macOS. This REQUIRES the boot name to be BOOTX64 (Next item). • Using the builtin Mac booter holding Option at boot: It will find all internal and external macOS systems, as well as any partition containing BOOTX64 • I boot Opencore to allow running unsupported macOSs on old Macs. I can either boot Refind to OC to macOS, or OC to Refind to macOS or any Linux. I can’t image the work that would be added if OpenSUSE required 2 partitions per system, one to contain EFI and code unique to that system. Because that’s what I have have to do, and external support would be a mess. Through the years, everything needed to boot Opensuse was kept in one partition and that makes multi boot much easier. Some people here said I could do other things, well, been there done that (or most of them) over the years. What I have now is super simple to maintain and add Linux and macOS systems to. Having an EFI for each Linux OS would be a mess. The macOS systems are easy because they share a container (multiple macOSs in a sine partition!). Linux on the other hand requires a partition, requiring an EFI for each would be a mess of maintenance. Since I was able to fix the problem by simply checking the needed boot script during install, why not keep it like it is, if no boot manager is selected, default to the original script so that /boot is loaded and the system is bootable, continue to allow missing /boot/efi as just a warning. If the new boot manager is selected I don’t know what is needed. If the long term plan is to remove Grub, please consider the above and provide a mechanism to boot from /boot and not require a /boot/efi. Finally, I want to thank you all so much for all your hard work. I have used Opensuse and Tumbleweed and have setup multiple friends, most non-technical with Opensuse and they are happy. Would love to keep using it and always look forward to what’s next! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c55 --- Comment #55 from Mario Guzman <mario_bz@mgtech.com> --- Forgot to mention, all the things above I have with zero configuration. When a macOS or Opensuse updates the kernel, there is nothing I have to do, Refind finds the symlink in /boot and boots. I can even select alternate kernels if available during the boot start. The only thing I ever have to do is for booting Refind on an external from the Mac Option key, requires the module renamed to BOOTX64. So I have simple and very flexible booting systems with nothing to do but installing the boot managers (Refind and Opencore), then can install operating systems and boot them with no configuration. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c56 --- Comment #56 from OBSbugzilla Bot <bwiedemann+obsbugzillabot@suse.com> --- This is an autogenerated message for OBS integration: This bug (1226122) was mentioned in https://build.opensuse.org/request/show/1185245 Factory / suse-module-tools -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c57 --- Comment #57 from Mario Guzman <mario_bz@mgtech.com> --- After reading up on sdbootutil I see it would be very bad for multi boot environments such as mine. So I have a suggestion to think about that may ease the pain for multi boot users: The installer currently has options for Grub, bootutil, or none. The none option now prevents /boot from being populated with the needed modules. How about adding another option called "compatibility" (or whatever name) that is basically like selecting none, except it populates /boot as it has always been doing in the past. /boot gets populated as before and the firmware is not changed. Obviously this may result in some limitations such as the enhancements planned for sdbootutil like boot snapshots, disk encryption, but it would allow multiboot to continue on. I have been following the links above to see how far things are progressing so I can test but it looks like some work to complete. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c59 --- Comment #59 from Mario Guzman <mario_bz@mgtech.com> --- I have detailed the issues in my comments above. Here is a summary of some of the items I mentioned above: First, this is all solved by simply implementing a legacy/compatibility option for booting in the installer. Keep /boot as is for people who want need it. It's been working all these year so why not allow it as an option. 1. sdboot (and grub) is useless to me. I am not just multi booting multiple Opensuses, but multiple type of operating systems. One my main development system I have three Opensuse and two other Linux systems, and 3 macOS systems. sdboot is only for a specific instance of linux. 2. On some older systems I use the Open Core Legacy Patcher booter to allow newer macOSs to run on unsupported systems. OLCP resides along side Refind Plus perfectly. sdboot is useless in this case. 3. sdboot requires an ESP partition to put the kernel AND a configuration file for EACH kernel. So if I want to keep everything completely independent I need an ESP partition for EACH Opensuse. I had five at one time, so that would require 10 partitions for five Opensuse systems! Partitioning becomes a nightmare. It seems sdboot assumes people will have one and only one OS, like Windows! 4.sdboot requires a configuration file for each linux. Wow, Refind requires nothing, I can install Opensuse without a boot manager, and immediately boot it with no configuration. Simplifies new installs AND nothing to do when the kernel is updated. Refind finds everything automagically. So in my case, sdboot would do nothing but get in the way and prevent multi boot of various systems, and add work since it needs configuration changes for every kernel update. It sounds like Refind may boot into sdboot is possible, then chain to linux. But why add the maintenance of configuration file and slow down boot when all we need for simple multi boot systems is to keep /boot populated as it is now. Please, just add a compat/legace option to load /boot and not install a boot manager. I know it's easy because I just added the missing boot installer script and everything works as before. Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c62 --- Comment #62 from Mario Guzman <mario_bz@mgtech.com> --- Martin, my best answers: What I may have not made clear since I didn’t think it would make a difference is that I use Refind and Refind Plus. Some info on refind: The original (upstream) refind information is at: https://www.rodsbooks.com/refind/ I use it to install refind plus which greatly enhances refind: https://github.com/dakanji/RefindPlus The license info should be in those websites. Years ago I entered an Opensuse enhancement to include refind but didn’t think it would go anywhere. Was not really needed anyway. The Refind and Refind Plus maintainers was not aware of sdboot, I pointed both of them to this issue. But probably nothing will happen unless needed to. Q: can rEFInd boot openSUSE snapshots? If yes, how does it work? I am sure the answer is no, even though macOS has bootable snapshots. But I am assuming based on not being info about snapshots in refind. Q: Does reEFInd support secure boot and any kind of preboot measurement using the TPM or other hardware? Yes, see here: https://www.rodsbooks.com/refind/secureboot.html Alberto, my best answers: Yes only needed for Tumbleweed since it is most likely used for development on multi boot systems. For your last question, if I set TW to not install a boot manager it installs nothing and leaves /boot empty. However, if during install I got into software section and check suse-module-tools-scriptlets, no boot manager is installed but /boot is properly populated to allow booting. Same as it always had. Thank you both for taking a serious interest in this delima. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c63 --- Comment #63 from Mario Guzman <mario_bz@mgtech.com> --- I was going to try installing with sdboot, but there is no checkmark to prevent "NVRAM update" like in the grub2 options. I assume that means install a booter but do NOT touch the actual nvram boot options. I was going to see how far if at all refind would find things. I created a root partition and EFI for /boot/efi/. I really think sdboot needs the option to install sdboot without actually messing up the nvram. In this case it would break refind and opencore booting. I ask if possible add the option to sdboot to install itself without actually updating the nvram so any existing boot managers will be retained and booted after the install. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c65 --- Comment #65 from Mario Guzman <mario_bz@mgtech.com> --- Martin, based on the comments from RefindPlus today, it seems refind should work. However, the sdboot installer option is missing an option to "Not modify nvram" so it can install sdboot but not modify the actual booter in nvram, Grub2 has that option. Not having that option would overwrite the nvram and cause a lot of extra work reinstalling Refind, RefindPlus, and OpenCore each time TW/OS is installed. The RefindPlus maintainer make some interesting comments saying not only should it work but I didn't know refind is already in other linux distributions, please see his comments and links here: https://github.com/dakanji/RefindPlus/discussions/183#discussioncomment-1009... Based on what he says this may not be too big an issue requiring an option to not overwrite NVRAM, and an extra ESP for each TW for multiboot systems. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c66 --- Comment #66 from Mario Guzman <mario_bz@mgtech.com> --- After a few days testing I got RefindPlus to boot Systemd-boot into Tumbleweed. The most important change needed to Tumbleweed systemd-boot is to provide an option to not update nvram/mbr as Grub2 has. The following three methods booted from RefindPlus with no RP configuration required: 1. Install TW - systemd-boot I created an ESP partition for each TW OS partition. TW installed boot code into the new ESP and TW booted normally. This method requires a separate ESP since it would overwrite the active ESP boot code, that’s acceptable since I understand it’s needed to support snapshots, encryption, etc. By having a separate ESP for each OS system multiboot can be maintained with not too much extra effort, just an extra partition for each linux OS. This method left /boot empty but booted fine so empty /boot was fine. However, I had to use efibootmgr -o to reset the default boot loader. That would not be required if TW had the option to not modify nvram/mbr. The good news is that since the original ESP containing RefindPlus and OpenCore managers was not touched, the efibootmgr command was all that was needed to get back to normal booting. 2. Install TW - Grub2 Exactly the same as systemd-boot except I had the options to turn off update nvram/mbr. That meant after TW installed Refind was still intact as the default boot manager. This method populated /boot. 3. Install TW - No Boot Manager This can be done but adding “suse-module-tools-scriptlets” to the software selection. This will populate /boot to make it bootable. I understand this is not the future though. So it if systemd-boot is the future and it can be booted from a different boot manager, we need the option to not update nvram/mbr to make the installation simpler. Hope you consider that since it seems more compatible with the future of removing /boot. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c67 --- Comment #67 from Mario Guzman <mario_bz@mgtech.com> --- Martin, Alberto, Felix, Lukas, etc. Half way there: I tested the July 26 snapshot which includes the change to suse-module-tools-scriptlets 16.0.48-1.1. I ran tests 1 and 3 above. Test 3 which is installing with no boot manager selected, it now works as it did before. Populates /boot and does not modify nvram. AOK! Test 1 selecting sdboot still does not provide an option to not modify nvram and mbr. Do you want this issue to remain open until that is fixed, or do you want me to close this issue and open another for the missing nvram/mbr options for sdboot installation? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c68 --- Comment #68 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Martin Wilck from comment #53)
Out of curiosity, if any of these many distros get a kernel update, you'll have to adapt the "main" distro's grub.cfg. I suppose you use some custom scripting for that purpose? This is one of the reasons I prefer using "configfile", it allows me to update each individual distro's config separately to keep in sync with updates.
The primary bootloader's stanzas include no kernel versions. Booting is done entirely with symlinks to kernels and initrds. e.g.: # ls -gGlh vmlinuz-??? vmlinuz initrd initrd-??? lrwxrwxrwx 1 22 Jul 1 08:44 initrd -> initrd-6.7.9-1-default lrwxrwxrwx 1 22 Jul 1 08:44 initrd-cur -> initrd-6.7.9-1-default lrwxrwxrwx 1 24 Jun 5 19:55 initrd-prv -> initrd-6.6.32-2-longterm lrwxrwxrwx 1 23 Jul 1 08:44 vmlinuz -> vmlinuz-6.7.9-1-default lrwxrwxrwx 1 23 Jul 1 08:44 vmlinuz-cur -> vmlinuz-6.7.9-1-default lrwxrwxrwx 1 25 Jun 5 19:55 vmlinuz-prv -> vmlinuz-6.6.32-2-longterm # Anytime I wish to boot prior kernel, it's a simple matter to edit the applicable Grub stanza. AFAICT, my methodology rules out any booting system that requires hosting kernel and initrd on an ESP, unless FAT32 somehow gains symlink support. Even if it did, I wouldn't want to see kernels & initrds from multiple installations sharing one ESP, while one ESP per PC is my strong preference. (In reply to Mario Guzman from comment #67)
Do you want this issue to remain open until that is fixed, or do you want me to close this issue and open another for the missing nvram/mbr options for sdboot installation?
Missing nvram/mbr options would seem to be a distinct issue worthy of its own bug. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c69 --- Comment #69 from Mario Guzman <mario_bz@mgtech.com> --- I will leave this issu open since it sounds like there may be additional possible work outstanding. However, it is fixed for me. I have created #1228595 for missing nvram option: https://bugzilla.opensuse.org/show_bug.cgi?id=1228595 Felix per your comment, FYI: "Anytime I wish to boot prior kernel, it's a simple matter to edit the applicable Grub stanza." Refind requires no configuration for kernels, and when presented on the menu, a function key will bring up all older kernels found in the directory as an option to boot. Saves a lot of time when testing something that requires kernel changes. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c73 --- Comment #73 from Mario Guzman <mario_bz@mgtech.com> --- (In reply to Martin Wilck from comment #70)
(In reply to Mario Guzman from comment #66)
Am I understanding correctly that rEFInd will not chain-load sd-boot, but will detect and boot the kernel(s) installed by sd-boot directly?
No, it appears that Refind DID find sd-boot, and I tested it. So far so good.
How does rEFIind handle secure boot? For secure boot to do what it's supposed to, rEFInd should refuse to load any kernel (or other EFI binary)
I don't have secure boot and can't answer this questions authoritavely. I will ask the dev for answers.
Why do you say that a separate ESP is necessary for every TW installation?
There is the case where you don't want one installation to touch anything another Linux does. So the only way it to have separate ESPs. However, in my case I found to keep the main ESP untouched, I could simply create another one and use that for multiple TW, etc. So really only 2 ESPs are needed to keep the main one (in my case with RefindPlus and OpenCore) untouched. So a minimum of 2 ESPs, or go wild with one per linux to ensure they don't mess with each other. Although I was initially concerned about this, having 2 is fine with me and no longer an issue. Keep in mind that if no boot manager is installed, you don't even need the one extra. This is now how the current TW works when saying NO boot manager. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1226122 https://bugzilla.suse.com/show_bug.cgi?id=1226122#c74 --- Comment #74 from Mario Guzman <mario_bz@mgtech.com> --- (In reply to Martin Wilck from comment #72)
(In reply to Mario Guzman from comment #69)
Also, I'm wondering about the kernel command line, which is ususally configured in /etc/default/grub. Does rEFInd have some logic to obtain the command line suitable for the given distribution from the distro's config files, or does it use the same command line for all kernels it finds?
Will get more from RefindPlus dev. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com