Bugzilla – Bug 1226122
TW installation with bootloader not managed leaves /boot/ empty when suse-module-tools-scriptlets not installed instead of sdbootutil-rpm-scriptlets
Last modified: 2024-07-20 18:51:15 UTC
Created attachment 875388 [details] 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.
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
Created attachment 875394 [details] 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.
I forgot to mention, the rpm kernel-longterm installation complained there was no ESP - same thing on two separate lines.
(In reply to Mario Guzman from comment #0) > 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. It's a design change because if you need something in /boot and what depends on the selected bootloader. grub2 needs something in /boot, grub2-bls and systemd-boot need something in /boot/EFI and nothing in /boot. And if you use full disk encryption with TPM or FIDO2 key, a kernel in /boot will not help you at all, as the bootloader cannot decrypt /boot to read the kernel, so you need the kernel in /boot/EFI.
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?
(In reply to Felix Miata from comment #5) > 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. The installer does not copy the kernel or initrd into /boot, this are the bootloader scripts. Letting the installer do this wouldn't make any sense because you want to update this files with the next update, too. And if you have no bootloader, nothing is copying the kernel, because nothing which could do it get's installed. See my previous comment, the kernel must be in the location where the selected bootloader needs it, not in a random place. I'm afraid you need to create your own scripts for your bootloader, as that is not shipped with openSUSE.
(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.
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.
Are you saying /boot is always empty now?
Josef, can you please take a look at this? Does it work as designed? I don't see any change in yast2-bootloader that would be relevant. If anything then only those changes for systemd-boot. Is this even anything for us?
Mario, it would be great to have YaST logs from the installation, see https://en.opensuse.org/openSUSE:Report_a_YaST_bug for details, libzypp history is really not enough.
OK here is YAST logs. I had no idea YAST was involved during initial installation.
Created attachment 875411 [details] YAST log directory
Created attachment 875412 [details] zypper.log if it helps
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.
Created attachment 875413 [details] 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!
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.
(In reply to Lukas Ocilka from comment #10) > Josef, can you please take a look at this? Does it work as designed? I don't > see any change in yast2-bootloader that would be relevant. If anything then > only those changes for systemd-boot. Is this even anything for us? Well, Yast as installer does not copy anything anywhere. It just calls other binaries and writes configs. For no bootloader no config is written beside /etc/sysconfig/bootloader. And also we do not call anything as possible use case for none bootloader can be also to load kernel from network and having just minimal system. Mario: what you can try to make it work is: 1. call on installed system `dracut --all --regenerate-all` if it generates files for you. 2. if you can boot installation env as legacy, it can possibly fill /boot as it is common location on legacy. You boot it as EFI, which writes stuff into ESP partition ( and nowhere in your case as no bootloader script is called )
Created attachment 875425 [details] 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.
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:~
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.
The last change in suse-module-tools-scriptlets * Wed May 22 14:00:00 2024 Martin Wilck <mwilck@suse.com> - Update to version 16.0.44: * Include unblacklist in initramfs (bsc#1224320) * regenerate-initrd-posttrans: run update-bootloader --refresh for XEN (bsc#1223278)
Just a guess: The problem is probably not in the script. It's the fact the script does not get installed.
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.
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.
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.
(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.
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.
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", but if you select "Systemd Boot", then it should really select the package you wish and use systemd.
From the latest TW full media: sdbootutil Supplements: (systemd-boot and shim)
well, I would say it is not installer fault that it stop working. We do not directly require those packages, especially if no bootloader is selected. What installer did in that case is basically nothing, just install other packages. 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. Lets just reassign to Martin Wilck to double check that the change caused by adding sdbootutil-rpm-scriptlets are intentional.
(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
(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.
(In reply to Felix Miata from comment #33) > 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. I guess this needs to be solved on the distro level, not Installer. By (our) definition (and it's there since its initial implementation), not managed means no bootloader. There's even a warning for that if you are selecting that option. If it worked till now, something else got broken in such scenario.
(In reply to Felix Miata from comment #32) > > 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! 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.
There's a pending PR to integrate sdbootutil-rpm-scriptlets back into suse-module-tools (https://github.com/openSUSE/suse-module-tools/pull/103). I believe that PR would have prevented the issue, at least if sdbootutil was not in the set of packages to install. It might cause other issues, though. Adding Alberto to shed some light on this, and making him aware of the issue. @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? I think Felix and Lukas nailed the problem in comment 28 and 30. kernel-default requires suse-kernel-rpm-scriptlets. This is provided by sdbootutil-rpm-scriptlets and suse-module-tools-scriptlets. sdbootutil-rpm-scriptlets has the "Supplements" shown in comment 30. But suse-module-tools-scriptlets has nothing of the kind. I wonder if adding something like Supplements: (shim unless sdbootutil) would have fixed the issue. Probably not unless shim was in the transaction set. Maybe this? Supplements: (kernel unless sdbootutil) Anyway, integrating the two scriptlets packages into one, while keeping this issue in mind, is probably the best way to move forward here.
(In reply to Martin Wilck from comment #36) > There's a pending PR to integrate sdbootutil-rpm-scriptlets back into > suse-module-tools (https://github.com/openSUSE/suse-module-tools/pull/103). > I believe that PR would have prevented the issue, at least if sdbootutil was > not in the set of packages to install. It might cause other issues, though. Just to confirm that this is correct. Making sdbootutil-rpm-scriplets to fade out is the right approach here (PR#103). This also fix a conflict with Grub2. Both issues comes from the same place: %package rpm-scriptlets Summary: Scripts to create boot entries on kernel updates Requires: sdbootutil >= %{version}-%{release} # make sure to not replace scriptlets with nops on systems that # use grub2 Conflicts: grub2 Conflicts: suse-kernel-rpm-scriptlets Provides: suse-kernel-rpm-scriptlets Obsoletes: %{name}-filetriggers < %{version} The sdbootutil-rpm-scriptlets are replacing suse-kernel-rpm-scriptlets, and if no bootloader is installed, seems that sdbootutil-rpm-scriptlets is preferred by the solver.
(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 [details]. (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.
(In reply to Felix Miata from comment #38) > > 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. [...] No idea what you mean. I was not talking about the installer nor the bootloader. If the user installs a kernel, suse-module-tools-scriplets will be required too. It is required by the %pre, %post et al. from the kernel spec file. It does not matter what bootloader was chosen, nor if there is a bootloader or not. The issue is that now there is a new provider for suse-module-tools-scriptlets (sdbootutil-rpm-scriptlets). So when the user installs a kernel, libsolv has two options to choose. Seems that if there is no bootloader selected, it favors sdbootutil-rpm-scriptlets to be installed, as the "Conflict: grub2" is not forbidding the installation. Note also that in this situation the installer is also irrelevant. But really, I did not understood your point.
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.
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.
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). I am asking because this is what I used to do on the multiboot systems I administered in the past. It roughly corresponds to the choice to not install grub into the MBR (or active partition) but some other partition for legacy systems. That's at the core of it IMO: on multiboot systems, you may or may not have a bootloader installed in any of the distros. But you ususally just want _one_ installation to manage the system-wide boot options (MBR for DOS, EFI boot menu, ...). In my experience it makes sense to have a system-wide boot menu that lets you select between installations, followed by an installation-specific boot menu giving you the option to select kernels and boot options for the previously selected OS. With grub, that's easily achieved using "configfile" or "chainloader" directives. On EFI systems, there are actually more options. You can have multiple ESPs, one for each OS. You can also have a single ESP with multiple directories (unfortunately the directory path under /boot/efi/EFI is more or less hard-coded). All this can be (relatively) comfortably administered with efibootmgr. Having no ESP at all for linux on an EFI system, as in Mario's case, it unusual at least (not saying that it's wrong). Meanwhile, I'll work with Alberto to merge the two packages.
I have never used rEFInd, but I suppose in the previous comment you could just s/efibootmgr/rEFInd/.
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.
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.
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.
(In reply to Felix Miata from comment #46) > I've spent the past nearly 3 hours composing a reply to comment #39. 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.
(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.
(In reply to Felix Miata from comment #48) > 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. Once the scripts are merged and I want to test this issue, I need to: 1) Install TW from YaST and try to not choose a boot manager 2) Check that the kernel and initrd are placed in /boot Is this accurate?
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.
(In reply to Mario Guzman from comment #45) > 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. This isn't true. The "BOOTX64" requirement is only for the "fallback" mechanism, which is only activated when there are no regular entries in the EFI boot manager. At least this is how it ought to be, of course there are broken BIOSes out there. And disclaimer still standing, I have zero clue about rEFInd. Anyway, I understand that neither you nor Felix like my suggestion from comment 42, and that's fine. It's a matter of taste. Please understand that from the distro architect PoV, not installing a bootloader at all is a highly unusual setup. Also, looking into the future, 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.
(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.
(In reply to Felix Miata from comment #52) > It's neither KISS nor green, having bootloaders on every installation I am hearing you. You don't need to convince me. Your concept of KISS is different from mine. You've got your preferences, that's fine. You just can't take for granted that the people who design the distribution do it with your preferences in mind. > These are all pleasurably booting from 13.1's grub-0.97-194.1.2 You're kind of lucky. I have frequently seen issues trying to boot recent distros with old GRUB versions. 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.
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!
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.
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
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.
(In reply to Mario Guzman from comment #57) > After reading up on sdbootutil I see it would be very bad for multi boot > environments such as mine. I cannot help with the installer, but I think I can help with sdbootutil. I am not a multiboot user, so I am lacking a lot of insight here too. I have some initial questions: 1) What is particularly bad about sdbootutil in multiboot environments? It takes care of installing the boot loader (that must be user commanded) and creating the entries for the distribution. 2) In a multiboot system, who is expected to create the boot entries? sdbootutil is doing this because it is not easy to decide the snapshot that should be used to extract the kernel from 3) How can sdbootutil help?
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.
The rationale for sd-boot and rEFInd are very different. sd-boot is tailored at Linux-only systems, with an emphasis on simplicity and support for secure boot and hardware-assisted disk encryption, whereas rEFInd has its strengths in multi-boot environments such as yours, with many different OSes. sd-boot comes from the systemd developers, which means that no distro can seriously ignore it. sdbootutil is (open)SUSE's addition for snapshot support; being able to boot from btrfs snapshots flawlessly is one of (open)SUSE's primary features. rEFInd, on the contrary, is obviously not a first-class citizen in most Linux distros, although it seems to be open source (I couldn't find concise information about its licensing, which looks like a mixed bag). There's a PPA for Ubuntu and some users have actually packaged it for openSUSE too, but no major distribution seems to ship it as an official package, or even support it officially as a boot loader. I am afraid this won't change any time soon, despite rEFInd's impressive feature set. rEFInd is good at detecting different OSes. I assume that the rEFInd maintainer is aware of sd-boot, and will work on enabling sd-boot detection by rEFInd. After all, it can't be more difficult than supporting various binary boot loaders of different proprietary OSes, no? If there are specific requirements from rEFInd's perspective regarding the partitioning layout or whatnot, they should be communicated to distribution architects, preferrably through the distributions' mailing lists. Q: can rEFInd boot openSUSE snapshots? If yes, how does it work? Q: Does reEFInd support secure boot and any kind of preboot measurement using the TPM or other hardware?
(In reply to Mario Guzman from comment #59) > I have detailed the issues in my comments above. Here is a summary of some > of the items I mentioned above: Thanks for the summary. I will keep it. > 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. That is only for Tumbleweed right? Because this would not possible work for MicroOS in any case. > 1. sdboot (and grub) is useless to me. After reading it I understand that sdbootutil cannot help in any way. IIUC what you want is that the installed does not install any bootloader. In this case sdbootutil should not be installed either. Sorry again for my lack of context. Does that means that when you install Tumbleweed without bootloader sdbootutil was installed?
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.
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.
(In reply to Mario Guzman from comment #62) > Years ago I entered an > Opensuse enhancement to include refind but didn’t think it would go > anywhere. Was not really needed anyway. A package would streamline the process. We could even sign rEFInd with our OBS key, so that no tedious MOK management would be necessary for people with Secure boot. (open)SUSE will almost certainly not adopt rEFInd as a first-class bootloader option in the foreseeable future. But if anybody had an interest that it did (hint!), providing a proper package would be a mandatory first step. > 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. Hm, too bad. I expected these guys to want to support as many OSes as possible. But so far sd-boot's market share is arguably very low. It's going to rise though, I think. > 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. That means you forego one of the main selling points of openSUSE. If you had a chain-loading setup (use rEFInd to boot into openSUSE's grub), you could get snapshot support, as well as support for othe SUSE boot options (failsafe mode, alternative kernels, etc). That's what I meant in comment 42. > 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 That document explains how to deplay rEFInd in a secureboot-enabled system. But it doesn't say anything about the later, TPM-based features which we can offer with sd-boot.
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-10092556 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.
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.