[Bug 1202353] New: kernel: replace mkinitrd wrapper with native dracut
https://bugzilla.suse.com/show_bug.cgi?id=1202353 Bug ID: 1202353 Summary: kernel: replace mkinitrd wrapper with native dracut Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: antonio.feijoo@suse.com QA Contact: qa-bugs@suse.de Blocks: 1202351 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1202351 +++ Upstream support removed in March 2021 (https://github.com/dracutdevs/dracut/commit/43df4ee2) and deprecation announcement on factory mailing list in May 2021 (https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/G...). ALP will not ship the mkinitrd wrapper, so it's better to get rid of it in Tumbleweed first. Affected packages that need to be updated before (at least): # zypper se --requires mkinitrd Loading repository data... Reading installed packages... S | Name | Summary | Type ---+---------------------+----------------------------------------------------+-------- | kernel-debug | A Debug Version of the Kernel | package i+ | kernel-default | The Standard Kernel | package | kernel-default-base | The Standard Kernel - base modules | package | kernel-kvmsmall | The Small Developer Kernel for KVM | package | kernel-pae | Kernel with PAE Support | package | kernel-vanilla | The Standard Kernel - without any SUSE patches | package i | mdadm | Utility for configuring "MD" software RAID devices | package -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c1
Jiri Slaby
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c2
--- Comment #2 from Jiri Slaby
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c3
Michal Suchanek
On the same note, we do this in rpm/kernel-binary.spec.in: !BuildIgnore: perl-Bootloader mkinitrd distribution-release
Should this be changed to dracut?
Perhaps it should be added instead? (In reply to Jiri Slaby from comment #1)
@Michal: I do not immediately see why we do: Requires(post): mkinitrd
Yes, s-m-t should pull in whatever it required to build the ramdisk, the kernel does not do it anymore. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c4
--- Comment #4 from Michal Suchanek
(In reply to Jiri Slaby from comment #2)
On the same note, we do this in rpm/kernel-binary.spec.in: !BuildIgnore: perl-Bootloader mkinitrd distribution-release
Should this be changed to dracut?
Perhaps it should be added instead?
Actually, if we pull in s-m-t, and the kernel gets installed during install test will it fail with dracut missing? Why do we even BuildIgnore mkinitrd in the first place? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c5
Jiri Slaby
(In reply to Jiri Slaby from comment #1)
@Michal: I do not immediately see why we do: Requires(post): mkinitrd
Yes, s-m-t should pull in whatever it required to build the ramdisk, the kernel does not do it anymore.
Ugh, it apparently doesn't: $ rpm -q suse-module-tools --requires |sort -u /bin/bash /bin/sh coreutils findutils (kmod(sg.ko) if kernel) rpm rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 rpmlib(RichDependencies) <= 4.12.0-1 systemd-rpm-macros /usr/bin/grep /usr/bin/gzip /usr/bin/perl /usr/bin/sed (In reply to Michal Suchanek from comment #4)
Actually, if we pull in s-m-t, and the kernel gets installed during install test will it fail with dracut missing?
It should handle it gracefully (regenerate-initrd-posttrans): : ${DRACUT:=/usr/bin/dracut} if [ ! -x "$DRACUT" ]; then echo "${0##*/}: dracut is not installed, not rebuilding the initrd" >&2 exit 0 fi ... if ! [ -f /etc/fstab -a ! -e /.buildenv -a -x "$DRACUT" ] ; then echo "Please run \"$DRACUT -f --regenerate-all\" as soon as your system is complete." >&2 rm "$dir"/* exit 0 fi
Why do we even BuildIgnore mkinitrd in the first place?
Maybe to avoid dependency loops and avoid creating an initrd during the build (to speed it up), but who knows... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c6
--- Comment #6 from Jiri Slaby
Why do we even BuildIgnore mkinitrd in the first place?
Maybe to avoid dependency loops and avoid creating an initrd during the build (to speed it up), but who knows...
It comes from bug 215218. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c7
--- Comment #7 from Martin Wilck
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c8
Martin Wilck
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c9
Martin Wilck
https://bugzilla.suse.com/show_bug.cgi?id=1202353
Jiri Slaby
https://bugzilla.suse.com/show_bug.cgi?id=1202353
Jiri Slaby
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c12
Dominique Leuenberger
s-m-t has "Recommends: dracut". The comments says
+# Use weak dependencies for mkinitrd and kmod in order to +# keep Ring0 lean. In normal deployments, these packages +# will be available anyway.
This goes back to a discussion between dimstar and myself in 2019. I suppose this constraint can be removed now, because s-m-t is no longer part of Ring 0.
That was indeed the issue back then, when s-m-t was still in ring0. Requiring 'kmod' should be no problem. Requiring dracut might turn into a cycle though as dracut buildrequires s-m-t, and if that one depends on dracut, dracut depends on itself to build, making it impossible to bootstrap (BuildIgnore dracut in dracut.spec could help) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c13
Martin Wilck
Requiring dracut might turn into a cycle though as dracut buildrequires s-m-t, and if that one depends on dracut, dracut depends on itself to build, making it impossible to bootstrap (BuildIgnore dracut in dracut.spec could help)
I don't remember why dracut buildrequires s-m-t. Antonio, can you tell? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c14
Antonio Feijoo
(In reply to Dominique Leuenberger from comment #12)
Requiring dracut might turn into a cycle though as dracut buildrequires s-m-t, and if that one depends on dracut, dracut depends on itself to build, making it impossible to bootstrap (BuildIgnore dracut in dracut.spec could help)
I don't remember why dracut buildrequires s-m-t. Antonio, can you tell?
Good question, unfortunately I can't find the reason documented anywhere... It looks like this build requirement was added in SLE-12:Update, since if was not present in GA (year 2015). Also, I can't find any explicit reference to anything provided by the s-m-t package that would be needed to build dracut. Maybe we can get rid of this, I'll try to build dracut removing it to see what happens: https://build.opensuse.org/package/show/home:afeijoo:branches:openSUSE:Facto... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c15
--- Comment #15 from Dominique Leuenberger
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c16
--- Comment #16 from Antonio Feijoo
In Factory, it was added with
https://build.opensuse.org/package/rdiff/openSUSE:Factory/ dracut?linkrev=base&rev=67
That seems to imply that back then, then macro regenerate_initrd_post might have been defined in s-m-t
Yes, you're right. At least systemd documented it in its spec file.
# regenerate_initrd_post macro is expanded during build, hence this # BR. Also this macro was introduced since version 12.4. BuildRequires: suse-module-tools >= 12.4
-- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c17
--- Comment #17 from Jiri Slaby
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c18
--- Comment #18 from Jiri Slaby
I'm not a bit confused.
Scratch the "not". -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c19
--- Comment #19 from Michal Suchanek
I'm not a bit confused. So can we remove Requires(post): mkinitrd from kernel spec or not? AFAIU, s-m-t does not (and won't) include that require and somehow expects working system. Or do we have to switch to something like: %if 0%{?suse_version} > XXX || 0%{?sle_version} >= YYY Requires(post): dracut %else Requires(post): mkinitrd %endif
We may not need a conditional at all: we require s-m-t that provides scriptlets, and if that s-m-t already uses dracut we can just s/mkinitrd/dracut/g -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c20
Jiri Slaby
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c21
--- Comment #21 from Antonio Feijoo
(In reply to Dominique Leuenberger from comment #12)
Requiring dracut might turn into a cycle though as dracut buildrequires s-m-t, and if that one depends on dracut, dracut depends on itself to build, making it impossible to bootstrap (BuildIgnore dracut in dracut.spec could help)
I don't remember why dracut buildrequires s-m-t. Antonio, can you tell?
Currently dracut does not "BuildRequires: suse-module-tools" in Factory, it was recently removed. See https://build.opensuse.org/package/rdiff/openSUSE:Factory/dracut?linkrev=base&rev=195 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c22
Martin Wilck
Maybe Martin can answer comment 17 & 19?
Not sure if I'm competent to answer this. Dominique should have a say in any case. Does it make sense to install a kernel without s-m-t? IMO the answer is "no". At least the modprobe.d files are necessary. (In theory we could separate them from the scriptlets, but that's yet another topic). Does it make sense to have s-m-t but not dracut? IMO the answer is "yes". But s-m-t is actually unclean today, as it calls /usr/bin/dracut unconditionally without requiring it. Does it make sense to have a kernel but not dracut? IMO yes, if you don't intend to update the kernel. So my recommendation would be: a) the kernel adds a Requires: s-m-t because of the modprobe.conf files, and drops the dependency on either dracut and mkinitrd. b) s-m-t dependencies are left as-is c) s-m-t calls dracut only if it exists, and prints a warning otherwise. Of course, this would make it possible that users shoot themselves in the foot by uninstalling dracut and then updating the kernel, but it would increase our flexibility. (In reply to Jiri Slaby from comment #17)
So can we remove Requires(post): mkinitrd from kernel spec or not?
IMO yes
Another question: should we add Requires(post): suse-module-tools at all
No, we should add Requires: suse-module-tools (for modprobe.d) and leave the kernel-rpm-scriptlets deps in place (for transaction ordering). Btw: why does the kernel use run_if_exists in %preun/%postun/%posttrans but not in %pre/%post? Wrt comment 19, I believe for released %sle_version we shouldn't change anything unless strictly necessary. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c23
--- Comment #23 from Michal Suchanek
Btw: why does the kernel use run_if_exists in %preun/%postun/%posttrans but not in %pre/%post?
Because these fix an ordering problem when 'upgrading' to a SLE release that does not have new enough s-m-t and removing the kernel that requires the external scriptlets at the same time. Then on uninstall (preun/postun) the scriptlets may not be available. They should in fact be available at posttrans because it runs only on install, not uninstall which makes it kind of useless. At installation time (pre/post) there is no reason to not order the installation correctly.
Does it make sense to have a kernel but not dracut? IMO yes, if you don't intend to update the kernel.
And the use case is what exactly? In a container you do not have a kernel at all. In an imm��table image that is replaced whole if you have the kernel you also need the ramdisk, and need to build it. What/when/how does build the ramdisk? While it's possible to build the ramdisk and remove dracut afterwards to reduce the image size do we have such fine-tuned pipeline anywhere? AFAIK even on 'transactional' systems the ramdisk is built on the target. And finally, if neither the kernel nor s-m-t pulls in dracut what does? Does potential space saving in a use case we do not have warrant enabling users of use cases we do have shooting themselves in the foot? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c24
--- Comment #24 from Martin Wilck
And the use case is what exactly?
All I know is that we've had intensive discussions in the past with some actors inside the company that use our packages to build stuff that's different from regular systems: installation images, KIWI or OBS build environments, special containers, what not. I definitely have no oversight over these projects. These people tend not to be involved on bugzillas like here, but they will complain aferwards.
In an imm��table image that is replaced whole if you have the kernel you also need the ramdisk, and need to build it. What/when/how does build the ramdisk?
I suppose the ramdisk could be built when the image is created, and dracut could be removed afterwards. Also mind you that we're discussing immutable RAM disks for FDE...
And finally, if neither the kernel nor s-m-t pulls in dracut what does?
It's currently pretty messy (deps just from my system): dracut <- kdump <- vm-install (only??) <- dracut-mkinitrd-deprecated <- mdadm (via /usr/sbin/mkinitrd) <- libbd_mdraid2 <- udisks2 (via libblockdev-mdraid) <- gnome-disk-utility <- fwupd <- plymouth-scripts <- plymouth-branding-openSUSE <- plymouth (via plymouth-branding) <- plymouth-dracut (sic?) None of these deps looks necessary IMO, except kdump's. Or at least the dependency of the kernel and s-m-t on dracut seems better justified than any of these.
Does potential space saving in a use case we do not have warrant enabling users of use cases we do have shooting themselves in the foot?
If it's consensus, I'm fine with adding Requires: dracut to s-m-t. According to comment 12 and comment 21, it should be ok for Factory. If those image folks complain later, I'm innocent :-) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c25
--- Comment #25 from Martin Wilck
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c26
--- Comment #26 from Martin Wilck
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c27
Martin Wilck
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c28
Ludwig Nussel
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c29
--- Comment #29 from Martin Wilck
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c30
--- Comment #30 from Martin Wilck
(In reply to Jiri Slaby from comment #20)
Another question: should we add Requires(post): suse-module-tools at all
No, we should add Requires: suse-module-tools (for modprobe.d) and leave the kernel-rpm-scriptlets deps in place (for transaction ordering).
Note that with Ludwig's PR (see also https://github.com/openSUSE/suse-module-tools/pull/64), suse-kernel-rpm-scriptlets will be separate from s-m-t. While in the first iteration the split-out scriptlets package will require s-m-t, that won't necessarily be the case in the future. IOW: packages that depend on other parts of s-m-t besides the scriptlets should add explicit dependencies on s-m-t. FWIW, as far as the kernel is concerned, a weak dependency might be sufficient because the kernel doesn't strictly require the default modprobe.d files. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c32
--- Comment #32 from Antonio Feijoo
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c33
--- Comment #33 from Michal Suchanek
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c34
--- Comment #34 from Martin Wilck
suse-module-tools use mkinitrd:
Only in a log message and in weak-modules, which is a remnant from ancient past and could / should be ditched. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c35
--- Comment #35 from Martin Wilck
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c36
--- Comment #36 from Michal Suchanek
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c37
Michal Suchanek
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c46
--- Comment #46 from Maintenance Automation
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c47
--- Comment #47 from Maintenance Automation
https://bugzilla.suse.com/show_bug.cgi?id=1202353
https://bugzilla.suse.com/show_bug.cgi?id=1202353#c49
--- Comment #49 from Maintenance Automation
participants (1)
-
bugzilla_noreply@suse.com