I don't have GRUB installed because I'm using systemd-boot.

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This affects all Fedora release.
Can we please get this fixed? This warning is very visible and annoying.

Sorry to know the warning is very annoying. kexec-tools depends on grubby and it used to Requires grubby and only Recommends grubby now at the request of CoreOS. So except for the case of CoreOS, grubby should be installed. I wonder what's this use-case of removing all grub-related packages? Is it because users want to use systemd-boot?

The first problem is that kexec-tools merges two unrelated bits of functionality:
kexec as such, and the crash kernel creation. Even when kexec is requested via
systemd (e.g. 'systemctl kexec'), kexec-tools are still used. People might want
to use this functionality but not the crash kernel.

The second problem is that kexec-tools is very tightly bound to grubby (and grub2).
There are other boot loaders: sd-boot, refind, maybe some arch-specific stuff,
but also systems without a boot loader: direct kernel boot via qemu, UKIs loaded
by UEFI, etc.

Packaging should be flexible enough to allow independent parts of functionality
to be installed independently, and when some other component is missing, to not
generate errors or warnings.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> The first problem is that kexec-tools merges two unrelated bits of
> functionality:
> kexec as such, and the crash kernel creation. Even when kexec is requested
> via
> systemd (e.g. 'systemctl kexec'), kexec-tools are still used. People might
> want
> to use this functionality but not the crash kernel.

Thanks for pointing out the problem! I think kexec-tools is mostly used for kdump (crash dump). If now there are a growing user base for kexec reboot, I'll be happy to separate the two features maybe by splitting current kexec-tools into two subpackages kexec-tools which merely provides /usr/sbin/kexec for loading the kernel and kdump-tools which is responsible for building the kdump initrd to collect a crash dump. I'll bring this topic to my team for discussion. Btw, I think `systemd kexec` actually depends on /usr/sbin/kexec to load a kernel so it has to use kexec-tools.

> 
> The second problem is that kexec-tools is very tightly bound to grubby (and
> grub2).
> There are other boot loaders: sd-boot, refind, maybe some arch-specific
> stuff,
> but also systems without a boot loader: direct kernel boot via qemu, UKIs
> loaded
> by UEFI, etc.

For the second problem, this is because we have limited resource and prioritize on grubby and grub2. Sorry for that other boot loaders are not supported now. Btw, sd-boot is an experimental feature now thanks for the effort from ARM's Jeremy [1][2].

> 
> Packaging should be flexible enough to allow independent parts of
> functionality
> to be installed independently,

I agree this is a good idea.

> and when some other component is missing, to
> not
> generate errors or warnings.

I don't think it's a good idea to not generate a warning if a dependent component is missing. 

[1] https://copr.fedorainfracloud.org/coprs/jlinton/sdubby/
[2] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/thread/S7G7VDFNIA2BIB2BSYLHKMUZFOCMZAC7/

> I think kexec-tools is mostly used for kdump (crash dump).
'systemctl kexec' has been around for a long time and has some users
(it's hard to gauge how many). Also, there's some talk about using kexec to switch
between kernel versions. There's been more interest recently, I think
it's fair to say that there's a growing user base, or at least renewed interest.

> I'll be happy to separate the two features maybe by splitting current kexec-tools into two subpackages kexec-tools which merely provides /usr/sbin/kexec for loading the kernel and kdump-tools which is responsible for building the kdump initrd to collect a crash dump.
That'd be great.

> For the second problem, this is because we have limited resource and prioritize on grubby and grub2.
Yes, that is fine. I only wanted to say that people _do_ use kexec-tools without grub2
or grubby. It's OK if you don't actively support this, but it should still be possible.

> Btw, sd-boot is an experimental feature now thanks for the effort from ARM's Jeremy [1][2].
That work is about support for sd-boot in Anaconda. I'd love to see this finalized,
so more users can experiment with sd-boot. But it's fairly easy to install sd-boot
on existing systems, some users do this.

> I don't think it's a good idea to not generate a warning if a dependent component is missing.
Once kdump-tools is split out, it's fine if it warns like this.
Right now the warning is problematic because (as discussed), there are scenarios
in which grubby is very much not wanted.

(In reply to Coiby from comment #4)
> I wonder what's this use-case of removing all grub-related packages?
> Is it because users want to use systemd-boot?

In my case, yes. I like the simplicity of systemd-boot.
I hate the way GRUB 2 is configured.
I don't know how to update the GRUB configuration by heart.
I always have to search for the documentation.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #7)
> > I think kexec-tools is mostly used for kdump (crash dump).
> 'systemctl kexec' has been around for a long time and has some users
> (it's hard to gauge how many). Also, there's some talk about using kexec to
> switch
> between kernel versions. There's been more interest recently, I think
> it's fair to say that there's a growing user base, or at least renewed
> interest.
> 
> > I'll be happy to separate the two features maybe by splitting current kexec-tools into two subpackages kexec-tools which merely provides /usr/sbin/kexec for loading the kernel and kdump-tools which is responsible for building the kdump initrd to collect a crash dump.
> That'd be great.

I've brought the topic to my team for a discussion. We think it's a good idea to split current kexec-tools into two packages despite the maintenance overhead. I wonder if there is a procedure I need to go through to apply for this change and how can I announce this change to minimize the impact? I was about to ask for help on devel.org but notice you are the most active poster so maybe it's a better idea to ask you first:)


> > Btw, sd-boot is an experimental feature now thanks for the effort from ARM's Jeremy [1][2].
> That work is about support for sd-boot in Anaconda. I'd love to see this
> finalized,
> so more users can experiment with sd-boot. But it's fairly easy to install
> sd-boot
> on existing systems, some users do this.

Btw [1] provides a replacement of grubby which is also needed by current kexec-tools.

(In reply to Cristian Ciupitu from comment #8)
> (In reply to Coiby from comment #4)
> > I wonder what's this use-case of removing all grub-related packages?
> > Is it because users want to use systemd-boot?
> 
> In my case, yes. I like the simplicity of systemd-boot.
> I hate the way GRUB 2 is configured.
> I don't know how to update the GRUB configuration by heart.
> I always have to search for the documentation.

Thanks for sharing your use case! I'm curious to ask do you install kexec-tools for the kdump feature or simply need the kexec executable?

> I've brought the topic to my team for a discussion. We think it's a good idea to split current kexec-tools into two packages despite the maintenance overhead. I wonder if there is a procedure I need to go through to apply for this change and how can I announce this change to minimize the impact?

I assume that you'd just build two or more subpackages from the single source package. This doesn't require any announcements or other external inputs. If you wish, this split could be announced to fedora-devel to raise awareness.

When the package is split, make sure to use self-obsoletes, so that the both children are installed on upgrades [https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages#(n:1)_Many-to-one_replacement].

> Btw [1] provides a replacement of grubby which is also needed by current kexec-tools.

Yeah. I'm not happy with sdubby, I think it's unnecessary and just repeats the same obsolete patterns that grubby implemented.

kernel-install is the primary way to install kernels, and kdump kernels should be installed using some kernel-install plugin. If something is missing from kernel-install, or it's not clear how to achieve something, please let us know, and we'll try to figure out a solution.

(In reply to Coiby from comment #10)

I don't use the kexec feature, I'm an ordinary user.
I think it was installed because ABRT depends on it.

# dnf erase kexec-tools
Dependencies resolved.
===============================================================================
 Package              Arch      Version              Repository           Size
===============================================================================
Removing:
 kexec-tools          x86_64    2.0.26-3.fc38        @fedora             1.3 M
Removing dependent packages:
 abrt-cli             x86_64    2.16.1-1.fc38        @updates-testing      0  
 abrt-desktop         x86_64    2.16.1-1.fc38        @updates-testing      0  
Removing unused dependencies:
 abrt-addon-ccpp      x86_64    2.16.1-1.fc38        @updates-testing    296 k
 abrt-addon-vmcore    x86_64    2.16.1-1.fc38        @updates-testing     37 k
 abrt-tui             noarch    2.16.1-1.fc38        @updates-testing     84 k
 libreport-fedora     x86_64    2.17.10-1.fc38       @updates-testing     53 k

Transaction Summary
===============================================================================
Remove  7 Packages

I would suggest the piece your missing in in the sdubby package here: https://copr.fedorainfracloud.org/coprs/jlinton/sdubby/

where the shell script there that fixes up the command line parms following an anaconda install also provides the switches needed by kdumpctl to setup the crashkernel.

IMHO, the grubby shim isn't that big of a deal, and the largest use of grubby is BLS entry manipulations by 3rd party programs that don't themselves want to clutter up their code finding the entries and adding/removing kernel boot parameters. This code in grubby is fairly complex due to all the cases its trying to solve, particularly when compared with the script in sdubby which is a few dozen lines because it depends on bootctl to find them, and sed to add/remove options from the specified entry.

AKA: 99% of the functionality can be described as add or strip an text string from a line in a text file.

So, for systemd-boot it seems more like something that bootctl could be doing natively, but ideally if its going to do that it should be smart enough to understand that there is an existing "standard" for manipulating the BLS entries provided by grubby, so understanding those switches if called as grubby would duplicate the functionality and remove much of the need for sdubby.

I'm closing this, because this should be working in F39+ if its installed with `inst.sdboot`. Otherwise, manually installing the sdubby package corrects the problem.

No issues indeed even without those packages:

# dnf --enablerepo='*-testing' -y install abrt-desktop abrt-cli
Last metadata expiration check: 0:04:04 ago on Fri 22 Dec 2023 06:25:15 PM EET.
Dependencies resolved.
===============================================================================
 Package                  Architecture  Version         Repository        Size
===============================================================================
Installing:
 abrt-cli                 x86_64        2.17.1-3.fc39   fedora           9.4 k
 abrt-desktop             x86_64        2.17.1-3.fc39   fedora           9.4 k
Installing dependencies:
 abrt-addon-ccpp          x86_64        2.17.1-3.fc39   fedora           106 k
 abrt-addon-vmcore        x86_64        2.17.1-3.fc39   fedora            28 k
 abrt-tui                 noarch        2.17.1-3.fc39   fedora            49 k
 kexec-tools              x86_64        2.0.27-4.fc39   updates-testing  490 k
 libreport-fedora         x86_64        2.17.11-3.fc39  fedora            21 k

Transaction Summary
===============================================================================
Install  7 Packages

Total size: 714 k
Installed size: 1.7 M
Downloading Packages:
[SKIPPED] abrt-addon-ccpp-2.17.1-3.fc39.x86_64.rpm: Already downloaded                                                                                                                      
[SKIPPED] abrt-addon-vmcore-2.17.1-3.fc39.x86_64.rpm: Already downloaded                                                                                                                    
[SKIPPED] abrt-cli-2.17.1-3.fc39.x86_64.rpm: Already downloaded                                                                                                                             
[SKIPPED] abrt-desktop-2.17.1-3.fc39.x86_64.rpm: Already downloaded                                                                                                                         
[SKIPPED] abrt-tui-2.17.1-3.fc39.noarch.rpm: Already downloaded                                                                                                                             
[SKIPPED] libreport-fedora-2.17.11-3.fc39.x86_64.rpm: Already downloaded                                                                                                                    
[SKIPPED] kexec-tools-2.0.27-4.fc39.x86_64.rpm: Already downloaded                                                                                                                          
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                    1/1 
  Installing       : abrt-addon-ccpp-2.17.1-3.fc39.x86_64               1/7 
  Running scriptlet: abrt-addon-ccpp-2.17.1-3.fc39.x86_64               1/7 
Created symlink /etc/systemd/system/multi-user.target.wants/abrt-journal-core.service → /usr/lib/systemd/system/abrt-journal-core.service.

  Installing       : libreport-fedora-2.17.11-3.fc39.x86_64             2/7 
  Installing       : abrt-tui-2.17.1-3.fc39.noarch                      3/7 
  Installing       : kexec-tools-2.0.27-4.fc39.x86_64                   4/7 
  Running scriptlet: kexec-tools-2.0.27-4.fc39.x86_64                   4/7 
  Installing       : abrt-addon-vmcore-2.17.1-3.fc39.x86_64             5/7 
  Running scriptlet: abrt-addon-vmcore-2.17.1-3.fc39.x86_64             5/7 
Created symlink /etc/systemd/system/multi-user.target.wants/abrt-vmcore.service → /usr/lib/systemd/system/abrt-vmcore.service.

  Installing       : abrt-cli-2.17.1-3.fc39.x86_64                      6/7 
  Installing       : abrt-desktop-2.17.1-3.fc39.x86_64                  7/7 
  Running scriptlet: abrt-addon-ccpp-2.17.1-3.fc39.x86_64               7/7 
  Running scriptlet: kexec-tools-2.0.27-4.fc39.x86_64                   7/7 
  Running scriptlet: abrt-addon-vmcore-2.17.1-3.fc39.x86_64             7/7 
  Running scriptlet: abrt-desktop-2.17.1-3.fc39.x86_64                  7/7 
  Verifying        : abrt-addon-ccpp-2.17.1-3.fc39.x86_64               1/7 
  Verifying        : abrt-addon-vmcore-2.17.1-3.fc39.x86_64             2/7 
  Verifying        : abrt-cli-2.17.1-3.fc39.x86_64                      3/7 
  Verifying        : abrt-desktop-2.17.1-3.fc39.x86_64                  4/7 
  Verifying        : abrt-tui-2.17.1-3.fc39.noarch                      5/7 
  Verifying        : libreport-fedora-2.17.11-3.fc39.x86_64             6/7 
  Verifying        : kexec-tools-2.0.27-4.fc39.x86_64                   7/7 

Installed:
  abrt-addon-ccpp-2.17.1-3.fc39.x86_64  abrt-addon-vmcore-2.17.1-3.fc39.x86_64
  abrt-cli-2.17.1-3.fc39.x86_64         abrt-desktop-2.17.1-3.fc39.x86_64
  abrt-tui-2.17.1-3.fc39.noarch         kexec-tools-2.0.27-4.fc39.x86_64
  libreport-fedora-2.17.11-3.fc39.x86_64   

Complete!
# rpm -q -a | grep grub
# rpm -q -a | grep sdub
#