Related: https://bugzilla.redhat.com/show_bug.cgi?id=2121912
Now there is a growing user base to use the kexec reboot and it's desirable to make the kexec-tools package more modular.
This patch splits current kexec-tools into two sub-packages kexec-tools and kdump-tools. Now kexec-tools merely provides /usr/sbin/kexec and the remaining features go into kdump-tools.
"dnf repoquery --whatrequires kexec-tools" shows the following packages requires kexec-tools, - abrt-addon-vmcore - anaconda-install-env-deps - cockpit-kdump - dracut-kiwi-oem-dump - realtime-setup - retrace-server
For those packages that need kdump, the dependency needs to point to the new kdump-tools package instead.
Cc: fedora-devel@lists.fedorahosted.org Cc: Dusty Mabe dustymabe@redhat.com Cc: crash-catcher-owner@lists.fedorahosted.org CC: anaconda-devel@lists.fedoraproject.org Cc: Martin Pitt mpitt@redhat.com Cc: kiwi-images@googlegroups.com Cc: Clark Williams williams@redhat.com Cc: Matěj Grabovský mgrabovs@redhat.com Suggested-by: Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl Signed-off-by: Coiby Xu coxu@redhat.com --- kexec-tools.spec | 80 +++++++++++++++++++++++++++++------------------- 1 file changed, 48 insertions(+), 32 deletions(-)
diff --git a/kexec-tools.spec b/kexec-tools.spec index 360b6c5d..6e78f6d3 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -5,9 +5,10 @@
Name: kexec-tools Version: 2.0.26 -Release: 7%{?dist} +Release: 8%{?dist} License: GPLv2 Summary: The kexec/kdump userspace component +Obsoletes: kexec-tools < 2.0.26-8
Source0: http://kernel.org/pub/linux/utils/kernel/kexec/%%7Bname%7D-%%7Bversion%7D.ta... Source1: kdumpctl @@ -56,33 +57,6 @@ Source109: dracut-early-kdump-module-setup.sh Source200: dracut-fadump-init-fadump.sh Source201: dracut-fadump-module-setup.sh
-%ifarch ppc64 ppc64le -Requires(post): servicelog -Recommends: keyutils -%endif -Requires(pre): coreutils sed zlib -Requires: dracut >= 058 -Requires: dracut-network >= 058 -Requires: dracut-squash >= 058 -Requires: ethtool -Requires: util-linux -# Needed for UKI support -Recommends: binutils -Recommends: grubby -Recommends: hostname -BuildRequires: make -BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison flex lzo-devel snappy-devel libzstd-devel -BuildRequires: pkgconfig intltool gettext -BuildRequires: systemd-rpm-macros -BuildRequires: automake autoconf libtool -%ifarch %{ix86} x86_64 ppc64 ppc s390x ppc64le -Obsoletes: diskdumputils netdump kexec-tools-eppic -%endif - -%ifnarch s390x -Requires: systemd-udev%{?_isa} -%endif - #START INSERT
# @@ -117,6 +91,42 @@ normal or a panic reboot. This package contains the /sbin/kexec binary and ancillary utilities that together form the userspace component of the kernel's kexec feature.
+%package -n kdump-tools +Summary: Kernel crash dump collection tools +Obsoletes: kexec-tools < 2.0.26-8 +%ifarch ppc64 ppc64le +Requires(post): servicelog +Recommends: keyutils +%endif +Requires(pre): coreutils sed zlib +Requires: kexec-tools >= 2.0.26-8 +Requires: dracut >= 058 +Requires: dracut-network >= 058 +Requires: dracut-squash >= 058 +Requires: ethtool +Requires: util-linux +Requires: binutils +Obsoletes: kexec-tools = 2.0.26-8 +Recommends: grubby +Recommends: hostname +BuildRequires: make +BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison flex lzo-devel snappy-devel libzstd-devel +BuildRequires: pkgconfig intltool gettext +BuildRequires: systemd-rpm-macros +BuildRequires: automake autoconf libtool +%ifarch %{ix86} x86_64 ppc64 ppc s390x ppc64le +Obsoletes: diskdumputils netdump kexec-tools-eppic +%endif + +%ifnarch s390x +Requires: systemd-udev%{?_isa} +%endif +%description -n kdump-tools +kdump-tools is reponsible for collecting the crash kernel dump. It builds and +load the kdump initramfs so when a kernel crashes, the system will boot the +kdump kernel and initramfs to save the colletecd crash kernel dump to specified +target. + %prep %setup -q
@@ -261,7 +271,7 @@ chmod 755 $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99zz-fadumpini mkdir -p $RPM_BUILD_ROOT/%{dracutlibdir}/modules.d/ mv $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/* $RPM_BUILD_ROOT/%{dracutlibdir}/modules.d/
-%post +%post -n kdump-tools # Initial installation %systemd_post kdump.service
@@ -295,10 +305,10 @@ then fi
-%postun +%postun -n kdump-tools %systemd_postun_with_restart kdump.service
-%preun +%preun -n kdump-tools %ifarch ppc64 ppc64le servicelog_notify --remove --command=/usr/lib/kdump/kdump-migrate-action.sh %endif @@ -326,7 +336,7 @@ do fi done
-%posttrans +%posttrans -n kdump-tools # Try to reset kernel crashkernel value to new default value or set up # crasherkernel value for new install # @@ -342,6 +352,9 @@ fi
%files /usr/sbin/kexec +%{_mandir}/man8/kexec.8.gz + +%files -n kdump-tools %ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 /usr/sbin/makedumpfile %endif @@ -396,6 +409,9 @@ fi %endif
%changelog +* Wed Jun 14 2023 Coiby coxu@redhat.com - 2.0.26-8 +- split kexec-tools into kexec-tools and kdump-tools + * Wed Jun 14 2023 Coiby coxu@redhat.com - 2.0.26-7 - kdumpctl: Fix the matching of plus symbol by grep's EREs - kdump-lib: Evaluate the memory consumption by smmu and mlx5 separately
On Mon, Jun 19, 2023 at 03:31:27PM +0800, Coiby Xu wrote:
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2121912
Now there is a growing user base to use the kexec reboot and it's desirable to make the kexec-tools package more modular.
This patch splits current kexec-tools into two sub-packages kexec-tools and kdump-tools. Now kexec-tools merely provides /usr/sbin/kexec and the remaining features go into kdump-tools.
Maybe submit this as PR against the dist-git repo? We'll get a test build then.
+Obsoletes: kexec-tools = 2.0.26-8
I don't think strict equality can be every satisfied.
+BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison flex lzo-devel snappy-devel libzstd-devel +BuildRequires: pkgconfig intltool gettext +BuildRequires: systemd-rpm-macros +BuildRequires: automake autoconf libtool +Obsoletes: diskdumputils netdump kexec-tools-eppic
One-per-line is the usual recommended style.
-%post +%post -n kdump-tools # Initial installation %systemd_post kdump.service
This one is tricky. %systemd_post presets the service on "first installation", which is actually the first the time package is installed. I.e. it unfortunately also would execute the preset on upgrades that split out a subpackage, because as far as rpm is concerned, this is the initial installation of that subpackage.
The righteous way to solve this would be something like this:
%triggerprein -n kdump-tools -- kexec-tools < 2.0.26-8 touch %{_localstatedir}/lib/rpm-state/kexec-tools.no-preset
%post -n kdump-tools rm %{_localstatedir}/lib/rpm-state/kexec-tools.no-preset 2>/dev/null && return 0 # Initial installation %systemd_post kdump.service
A bit of a bother, but at least nobody will be suprised by kdump.service changing state.
Zbyszek
On Wed, Jun 21, 2023 at 11:38:37PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 19, 2023 at 03:31:27PM +0800, Coiby Xu wrote:
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2121912
Now there is a growing user base to use the kexec reboot and it's desirable to make the kexec-tools package more modular.
This patch splits current kexec-tools into two sub-packages kexec-tools and kdump-tools. Now kexec-tools merely provides /usr/sbin/kexec and the remaining features go into kdump-tools.
Maybe submit this as PR against the dist-git repo? We'll get a test build then.
Thanks for the suggestion! I'll submit a PR against the dist-git repo for next version.
+Obsoletes: kexec-tools = 2.0.26-8
I don't think strict equality can be every satisfied.
Oh, I meant Provides. Quoting https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-repla...,
If a package is being renamed without any functional changes, or is a compatible-enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with:
Provides: oldpackagename = $provEVR Obsoletes: oldpackagename < $obsEVR
I assume at least majority of the users install kexec-tools for the kdump feature so I kdump-tools is a compatible-enough replacement to the old kexec-tools.
+BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison flex lzo-devel snappy-devel libzstd-devel +BuildRequires: pkgconfig intltool gettext +BuildRequires: systemd-rpm-macros +BuildRequires: automake autoconf libtool +Obsoletes: diskdumputils netdump kexec-tools-eppic
One-per-line is the usual recommended style.
I'll use one-per-line for next version, thanks!
-%post +%post -n kdump-tools # Initial installation %systemd_post kdump.service
This one is tricky. %systemd_post presets the service on "first installation", which is actually the first the time package is installed. I.e. it unfortunately also would execute the preset on upgrades that split out a subpackage, because as far as rpm is concerned, this is the initial installation of that subpackage.
The righteous way to solve this would be something like this:
%triggerprein -n kdump-tools -- kexec-tools < 2.0.26-8 touch %{_localstatedir}/lib/rpm-state/kexec-tools.no-preset
%post -n kdump-tools rm %{_localstatedir}/lib/rpm-state/kexec-tools.no-preset 2>/dev/null && return 0 # Initial installation %systemd_post kdump.service
A bit of a bother, but at least nobody will be suprised by kdump.service changing state.
Thanks for catching this issue and also providing a fix! I'll apply it to next version.
Zbyszek
Hi Coiby,
On Mon, 19 Jun 2023 15:31:27 +0800 Coiby Xu coxu@redhat.com wrote:
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2121912
Now there is a growing user base to use the kexec reboot and it's desirable to make the kexec-tools package more modular.
This patch splits current kexec-tools into two sub-packages kexec-tools and kdump-tools. Now kexec-tools merely provides /usr/sbin/kexec and the remaining features go into kdump-tools.
all in all I'm in favor for this change. But for me simply splitting kexec-tools in a separate sub package is just a half-baked solution. When you look at the current kexec-tools you see that it consists of four different projects. There's upstream kexec-tools, makedumpfile and eppic as well as our Fedora tooling. The 'clean' solution would be to move each project into it's own package. Ideally each having it's own repo which would allow us to move to a source-git based work flow.
Anyway, just my 2 ct's.
"dnf repoquery --whatrequires kexec-tools" shows the following packages requires kexec-tools,
- abrt-addon-vmcore
- anaconda-install-env-deps
- cockpit-kdump
- dracut-kiwi-oem-dump
- realtime-setup
- retrace-server
For those packages that need kdump, the dependency needs to point to the new kdump-tools package instead.
Cc: fedora-devel@lists.fedorahosted.org Cc: Dusty Mabe dustymabe@redhat.com Cc: crash-catcher-owner@lists.fedorahosted.org CC: anaconda-devel@lists.fedoraproject.org Cc: Martin Pitt mpitt@redhat.com Cc: kiwi-images@googlegroups.com Cc: Clark Williams williams@redhat.com Cc: Matěj Grabovský mgrabovs@redhat.com Suggested-by: Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl Signed-off-by: Coiby Xu coxu@redhat.com
kexec-tools.spec | 80 +++++++++++++++++++++++++++++------------------- 1 file changed, 48 insertions(+), 32 deletions(-)
diff --git a/kexec-tools.spec b/kexec-tools.spec index 360b6c5d..6e78f6d3 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -5,9 +5,10 @@
Name: kexec-tools Version: 2.0.26 -Release: 7%{?dist} +Release: 8%{?dist} License: GPLv2 Summary: The kexec/kdump userspace component +Obsoletes: kexec-tools < 2.0.26-8
Source0: http://kernel.org/pub/linux/utils/kernel/kexec/%%7Bname%7D-%%7Bversion%7D.ta... Source1: kdumpctl @@ -56,33 +57,6 @@ Source109: dracut-early-kdump-module-setup.sh Source200: dracut-fadump-init-fadump.sh Source201: dracut-fadump-module-setup.sh
-%ifarch ppc64 ppc64le -Requires(post): servicelog -Recommends: keyutils -%endif -Requires(pre): coreutils sed zlib -Requires: dracut >= 058 -Requires: dracut-network >= 058 -Requires: dracut-squash >= 058 -Requires: ethtool -Requires: util-linux -# Needed for UKI support -Recommends: binutils -Recommends: grubby -Recommends: hostname -BuildRequires: make -BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison flex lzo-devel snappy-devel libzstd-devel -BuildRequires: pkgconfig intltool gettext -BuildRequires: systemd-rpm-macros -BuildRequires: automake autoconf libtool
You cannot simply remove all build requirements from kexec-tools. You'll need to keep at least make, autoconf, automake(?) and gcc (which is already missing today).
-%ifarch %{ix86} x86_64 ppc64 ppc s390x ppc64le -Obsoletes: diskdumputils netdump kexec-tools-eppic -%endif
-%ifnarch s390x -Requires: systemd-udev%{?_isa} -%endif
#START INSERT
# @@ -117,6 +91,42 @@ normal or a panic reboot. This package contains the /sbin/kexec binary and ancillary utilities that together form the userspace component of the kernel's kexec feature.
+%package -n kdump-tools +Summary: Kernel crash dump collection tools +Obsoletes: kexec-tools < 2.0.26-8 +%ifarch ppc64 ppc64le +Requires(post): servicelog +Recommends: keyutils +%endif +Requires(pre): coreutils sed zlib +Requires: kexec-tools >= 2.0.26-8 +Requires: dracut >= 058 +Requires: dracut-network >= 058 +Requires: dracut-squash >= 058 +Requires: ethtool +Requires: util-linux +Requires: binutils +Obsoletes: kexec-tools = 2.0.26-8
^ Is '=' correct here? Shouldn't it be '<' just like for kexec-tools?
+Recommends: grubby +Recommends: hostname +BuildRequires: make +BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison flex lzo-devel snappy-devel libzstd-devel +BuildRequires: pkgconfig intltool gettext +BuildRequires: systemd-rpm-macros +BuildRequires: automake autoconf libtool +%ifarch %{ix86} x86_64 ppc64 ppc s390x ppc64le +Obsoletes: diskdumputils netdump kexec-tools-eppic
diskdumputils and netdump were last used with RHEL4 and according to git kexec-tools-eppic was removed with Fedora 22. I think it is safe to simply drop this line.
Thanks Philipp
+%endif
+%ifnarch s390x +Requires: systemd-udev%{?_isa} +%endif +%description -n kdump-tools +kdump-tools is reponsible for collecting the crash kernel dump. It builds and +load the kdump initramfs so when a kernel crashes, the system will boot the +kdump kernel and initramfs to save the colletecd crash kernel dump to specified +target.
%prep %setup -q
@@ -261,7 +271,7 @@ chmod 755 $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/99zz-fadumpini mkdir -p $RPM_BUILD_ROOT/%{dracutlibdir}/modules.d/ mv $RPM_BUILD_ROOT/etc/kdump-adv-conf/kdump_dracut_modules/* $RPM_BUILD_ROOT/%{dracutlibdir}/modules.d/
-%post +%post -n kdump-tools # Initial installation %systemd_post kdump.service
@@ -295,10 +305,10 @@ then fi
-%postun +%postun -n kdump-tools %systemd_postun_with_restart kdump.service
-%preun +%preun -n kdump-tools %ifarch ppc64 ppc64le servicelog_notify --remove --command=/usr/lib/kdump/kdump-migrate-action.sh %endif @@ -326,7 +336,7 @@ do fi done
-%posttrans +%posttrans -n kdump-tools # Try to reset kernel crashkernel value to new default value or set up # crasherkernel value for new install # @@ -342,6 +352,9 @@ fi
%files /usr/sbin/kexec +%{_mandir}/man8/kexec.8.gz
+%files -n kdump-tools %ifarch %{ix86} x86_64 ppc64 s390x ppc64le aarch64 /usr/sbin/makedumpfile %endif @@ -396,6 +409,9 @@ fi %endif
%changelog +* Wed Jun 14 2023 Coiby coxu@redhat.com - 2.0.26-8 +- split kexec-tools into kexec-tools and kdump-tools
- Wed Jun 14 2023 Coiby coxu@redhat.com - 2.0.26-7
- kdumpctl: Fix the matching of plus symbol by grep's EREs
- kdump-lib: Evaluate the memory consumption by smmu and mlx5 separately
Hi Philipp,
On Thu, Jun 22, 2023 at 11:54:52AM +0200, Philipp Rudo wrote:
Hi Coiby,
On Mon, 19 Jun 2023 15:31:27 +0800 Coiby Xu coxu@redhat.com wrote:
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2121912
Now there is a growing user base to use the kexec reboot and it's desirable to make the kexec-tools package more modular.
This patch splits current kexec-tools into two sub-packages kexec-tools and kdump-tools. Now kexec-tools merely provides /usr/sbin/kexec and the remaining features go into kdump-tools.
all in all I'm in favor for this change. But for me simply splitting kexec-tools in a separate sub package is just a half-baked solution. When you look at the current kexec-tools you see that it consists of four different projects. There's upstream kexec-tools, makedumpfile and eppic as well as our Fedora tooling. The 'clean' solution would be to move each project into it's own package. Ideally each having it's own repo which would allow us to move to a source-git based work flow.
Anyway, just my 2 ct's.
Thanks for sharing your thoughts! Yes, one potential benefit is we can upgrade kexec-tools, makedumpfile and eppic alone if each package has it's own repo. I haven't decided to do that is 1) currently only users request the upstream kexec-tools to be split out and the remaining things like makedumpfile are only for kdump; 2) I don't how much work I need to create four standalone packages for example I don't what procedure I need to go through to apply for a new package. Could you list other known benefits of "moving to a source-git based workflow" so we make a decision?
Hi Coiby,
On Fri, 30 Jun 2023 18:14:34 +0800 Coiby Xu coxu@redhat.com wrote:
Hi Philipp,
On Thu, Jun 22, 2023 at 11:54:52AM +0200, Philipp Rudo wrote:
Hi Coiby,
On Mon, 19 Jun 2023 15:31:27 +0800 Coiby Xu coxu@redhat.com wrote:
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2121912
Now there is a growing user base to use the kexec reboot and it's desirable to make the kexec-tools package more modular.
This patch splits current kexec-tools into two sub-packages kexec-tools and kdump-tools. Now kexec-tools merely provides /usr/sbin/kexec and the remaining features go into kdump-tools.
all in all I'm in favor for this change. But for me simply splitting kexec-tools in a separate sub package is just a half-baked solution. When you look at the current kexec-tools you see that it consists of four different projects. There's upstream kexec-tools, makedumpfile and eppic as well as our Fedora tooling. The 'clean' solution would be to move each project into it's own package. Ideally each having it's own repo which would allow us to move to a source-git based work flow.
Anyway, just my 2 ct's.
Thanks for sharing your thoughts! Yes, one potential benefit is we can upgrade kexec-tools, makedumpfile and eppic alone if each package has it's own repo. I haven't decided to do that is 1) currently only users request the upstream kexec-tools to be split out and the remaining things like makedumpfile are only for kdump; 2) I don't how much work I need to create four standalone packages for example I don't what procedure I need to go through to apply for a new package. Could you list other known benefits of "moving to a source-git based workflow" so we make a decision?
The main benefit of the source-git based workflow I see is that you do have access to the source code as it is packaged in a human readable form. In my opinion this makes working with the package a lot easier. For example this is my workflow when backporting, say a makedumpfile patch
1) checkout the version in the upstream repo
2) apply all patches already backported in the correct order to prevent conflicts
3) make the actual backport (i.e. cherry-pick+adjust the commit(s) required, testing etc.)
4) create patches from the commit(s) created in 3)
5) move patches to dist-git and adjust the spec file
6) test again to verify that the patches were actually applied in the spec file
In a source-git based workflow all that is needed is step 3). All other steps are automated.
An other benefit I see is that reviewing backports is much easier. You simply have a diff that shows you all changes made to the code. Not a diff that adds a patch file which you then have to decode in your head. This might work for simple backports but in complex cases, when there are many conflicts with upstream, there is no other way than manually re-creating the source-git (i.e. steps 1 & 2 from above) so you can actually review.
Finally, splitting up the package even further gives us more flexibility to adjust to future developments and gives us options for optimization. Its basically the same reason what Zbigniew asked for kexec-tools but for the other tools. Say a user doesn't use makedumpfiles '--eppic' option. Why should they install eppic? Or the user uses 'scp' to dump to a remote host. Why should they install makedumpfile? That's less important for normal installations, but gets important when you build container images with mkosi [1] and want to optimize them for size.
To be fair, there are not that many backports for the package and the last argument is somewhat a bet on the future. Nevertheless, I believe it will be way less effort to split them out all at once rather than one after the other.
Thanks Philipp
On Mon, 19 Jun 2023 at 15:31, Coiby Xu coxu@redhat.com wrote:
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2121912
Now there is a growing user base to use the kexec reboot and it's desirable to make the kexec-tools package more modular.
This patch splits current kexec-tools into two sub-packages kexec-tools and kdump-tools. Now kexec-tools merely provides /usr/sbin/kexec and the remaining features go into kdump-tools.
"dnf repoquery --whatrequires kexec-tools" shows the following packages requires kexec-tools,
- abrt-addon-vmcore
- anaconda-install-env-deps
- cockpit-kdump
- dracut-kiwi-oem-dump
- realtime-setup
- retrace-server
For those packages that need kdump, the dependency needs to point to the new kdump-tools package instead.
Cc: fedora-devel@lists.fedorahosted.org Cc: Dusty Mabe dustymabe@redhat.com Cc: crash-catcher-owner@lists.fedorahosted.org CC: anaconda-devel@lists.fedoraproject.org Cc: Martin Pitt mpitt@redhat.com Cc: kiwi-images@googlegroups.com Cc: Clark Williams williams@redhat.com Cc: Matěj Grabovský mgrabovs@redhat.com Suggested-by: Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl Signed-off-by: Coiby Xu coxu@redhat.com
kexec-tools.spec | 80 +++++++++++++++++++++++++++++------------------- 1 file changed, 48 insertions(+), 32 deletions(-)
diff --git a/kexec-tools.spec b/kexec-tools.spec index 360b6c5d..6e78f6d3 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -5,9 +5,10 @@
Name: kexec-tools Version: 2.0.26 -Release: 7%{?dist} +Release: 8%{?dist} License: GPLv2 Summary: The kexec/kdump userspace component +Obsoletes: kexec-tools < 2.0.26-8
Source0: http://kernel.org/pub/linux/utils/kernel/kexec/%%7Bname%7D-%%7Bversion%7D.ta... Source1: kdumpctl @@ -56,33 +57,6 @@ Source109: dracut-early-kdump-module-setup.sh Source200: dracut-fadump-init-fadump.sh Source201: dracut-fadump-module-setup.sh
-%ifarch ppc64 ppc64le -Requires(post): servicelog -Recommends: keyutils -%endif -Requires(pre): coreutils sed zlib -Requires: dracut >= 058 -Requires: dracut-network >= 058 -Requires: dracut-squash >= 058 -Requires: ethtool -Requires: util-linux -# Needed for UKI support -Recommends: binutils -Recommends: grubby -Recommends: hostname -BuildRequires: make -BuildRequires: zlib-devel elfutils-devel glib2-devel bzip2-devel ncurses-devel bison flex lzo-devel snappy-devel libzstd-devel -BuildRequires: pkgconfig intltool gettext -BuildRequires: systemd-rpm-macros -BuildRequires: automake autoconf libtool -%ifarch %{ix86} x86_64 ppc64 ppc s390x ppc64le -Obsoletes: diskdumputils netdump kexec-tools-eppic -%endif
-%ifnarch s390x -Requires: systemd-udev%{?_isa} -%endif
#START INSERT
# @@ -117,6 +91,42 @@ normal or a panic reboot. This package contains the /sbin/kexec binary and ancillary utilities that together form the userspace component of the kernel's kexec feature.
+%package -n kdump-tools
Hi, I still can not resist adding a comment about the naming, although different distribution will not cause pkg name confliction, it still sounds strange to me.
Debian/Ubuntu use kdump-tools: https://manpages.debian.org/unstable/kdump-tools/kdump-tools.5.en.html Suse use kdumptool: (but seems the tool is really a tool instead of service related, not sure where is the initrd generating code) https://www.unix.com/man-page/suse/8/kdumptool/
So it would be better to have a name which can be easily differentiated from above two although not a must.
BTW another thing to think is probably we should split the real tooling to estimate and other stuff out of service manipulation in kdumpctl? Anyway I have no strong opinion, just leave here about the thoughts to discuss.
Thanks Dave
-
Coiby Xu -
Philipp Rudo -
RuiRui Yang -
Zbigniew Jędrzejewski-Szmek