Jon, let's forget about YaST as a tool for everything, please, rather tell us what do you actually need to have solved? What is your use-case? What do you need to configure? The description does not contain much info.

Kernel packages are some of the very few multi-version packages that we provide. You can select more than one in the YaST software module; see the "Versions" tab in the lower right of the screen.

Of course, that will only get you an additional kernel on the machine. You'll also have to make decisions like which of them to boot by default. And that is where some manual interaction with config files will become necessary.

But other aspects are handled automatically, like dependency resolution, i.e. what additional kernel packages you need for that particular kernel base package. Kernel packages have very specific RPM dependencies based on SHAs (or similar) to ensure that you'll always get the matching packages.

Dracut will handle building an initrd for every installed kernel, and Grub2 will add a boot menu entry for each one.

So, what else are you missing?

(In reply to Lukas Ocilka from comment #1)
> Jon, let's forget about YaST as a tool for everything, please, rather tell
> us what do you actually need to have solved? What is your use-case? What do
> you need to configure? The description does not contain much info.

I didn't have a clue what the 'shim signature' was or how to obtain it. I ended up reverting to the old kernel. It's a complicated process, and I thought streamlining it into a module would be helpful.

Reverting to a previous system state is a lot easier with Btrfs and snapshots; that's why this is our default storage setup during installation.

Do I understand you correctly that this was what caused you the most trouble, and what you'd want to improve with that YaST kernel management module? Or was there anything else?

(In reply to Stefan Hundhammer from comment #4)
> Reverting to a previous system state is a lot easier with Btrfs and
> snapshots; that's why this is our default storage setup during installation.
> 
> Do I understand you correctly that this was what caused you the most
> trouble, and what you'd want to improve with that YaST kernel management
> module? Or was there anything else?

The signature was the biggest obstacle, but the process is spread all over. Editing zypp.conf; adding repositories; importing the sig; I'm sure I'm leaving something out. I gave up for now, it wasn't clear how to import the sig from the blue screen. I used the mokutil and it didn't help.

First of all, YaST is on its way out; the new Agama installer will take over. And Agama will be purely an installer. Unlike YaST, it will not include dozens of configuration modules for all kinds of subsystems.

Some things will be available via other Open Source tools like Cockpit, others will be delegated to the desktops (KDE Plasma, GNOME etc.) which already bring their own tools for many desktop-related tasks (printer management, network (GUIs for NetworkManager), language and keyboard selection etc.).

Other sysadmin tasks will be left to command line tools and (mostly for corporate environments) to centralized configuration management tools like SUSE Manager, SaltStack, Ansible etc.

The emphasis for server tasks (web server, DNS server, DHCP server etc.) will also be on workloads in containers that are largely already preconfigured.


It would make no sense at all to invest heavily into yet another YaST module.

(In reply to Jon Cosby from comment #5)
> The signature was the biggest obstacle, but the process is spread all over.
> Editing zypp.conf; adding repositories; importing the sig; I'm sure I'm
> leaving something out. I gave up for now, it wasn't clear how to import the
> sig from the blue screen. I used the mokutil and it didn't help.

You must be either hitting some bug or doing something unexpected. Here's some old post with "bad shim signature" https://www.reddit.com/r/openSUSE/comments/idh5n7/cant_boot_kernel_latest_leap_update_bad_shim/ maybe that helps.

Honestly, I still don't see how YaST could help here anyway. IMO all needs to be done/signed during the build time and just work by installing a multi-version Kernel.

What we can and do offer already is installing one of the other kernels that are provided and supported for the distribution and release that you installed: Those you can already install from the YaST software manager.

AFAIK that also includes kernels that are available from OBS (openSUSE Build System) repositories, from OBS projects (often backed by SUSE developer teams) as well as openSUSE community users who build and publish kernel packages there.


But when it comes to third-party (non-OBS) packages, it becomes increasingly difficult; not only for users like you, also for us as SUSE, or, more specifically, us as the YaST team.

Where would that end? Would users also expect us to take a tarball of kernel sources, build them, give them our blessing with the OBS build keys, and then install them? And how about secure boot signatures, as you mentioned? And what if the build was not successful?


Also, people using any such a YaST module (even if it wouldn't support building a kernel from source) would of course - like they have ALWAYS been doing - write bug reports against YaST (not the kernel!) for every possible problem, and would insist on us debugging their specific setup.

That alone is reason enough to not even think about offering such a YaST module.


If a YaST module is there for any purpose, users start experimenting with it, testing its limits. That already offers enough potential for disaster with modules like the YaST software manager, the partitioner, the bootloader configuration. A kernel management module would open up a whole new dimension of  problems; that is nothing to use casually. But I am very sure that users would start doing just that.

It's not only an issue of product warranty, there is also considerable risk of ruining the reputation of SUSE Linux products in general.


So, thank you for your input, but sorry, no, we are not going down that road. There be dragons.