[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 the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c1 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby@suse.com, | |martin.wilck@suse.com, | |msuchanek@suse.com Flags| |needinfo?(msuchanek@suse.co | |m), | |needinfo?(martin.wilck@suse | |.com) --- Comment #1 from Jiri Slaby <jslaby@suse.com> --- @Michal: I do not immediately see why we do: Requires(post): mkinitrd in rpm/kernel-binary.spec.in? Should we simply remove it as suse-module-tools have the proper Requires? @Martin: suse-module-tools are now fully aware of dracut, right? (kernel-obs-build.spec.in needs mkinitrd only on SLE11.) -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c2 --- Comment #2 from Jiri Slaby <jslaby@suse.com> --- 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? -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c3 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(msuchanek@suse.co | |m) | --- Comment #3 from Michal Suchanek <msuchanek@suse.com> --- (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? (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 the assignee 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 <msuchanek@suse.com> --- (In reply to Michal Suchanek from comment #3)
(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 the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c5 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |SHIP_STOPPER? --- Comment #5 from Jiri Slaby <jslaby@suse.com> ---
(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 the assignee 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 <jslaby@suse.com> --- (In reply to Jiri Slaby from comment #5)
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 the assignee 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 <martin.wilck@suse.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c8 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dimstar@opensuse.org Flags| |needinfo?(dimstar@opensuse. | |org) --- Comment #8 from Martin Wilck <martin.wilck@suse.com> --- Dominique, can you confirm comment 7? -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c9 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(martin.wilck@suse | |.com) | --- Comment #9 from Martin Wilck <martin.wilck@suse.com> --- clearing needinfo on myself for now -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|SHIP_STOPPER? |SHIP_STOPPER- -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|SHIP_STOPPER- | -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c12 Dominique Leuenberger <dimstar@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dimstar@opensuse. | |org) | --- Comment #12 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Martin Wilck from comment #7)
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 the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c13 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |antonio.feijoo@suse.com Flags| |needinfo?(antonio.feijoo@su | |se.com) --- Comment #13 from Martin Wilck <martin.wilck@suse.com> --- (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? -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c14 Antonio Feijoo <antonio.feijoo@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(antonio.feijoo@su | |se.com) | --- Comment #14 from Antonio Feijoo <antonio.feijoo@suse.com> --- (In reply to Martin Wilck from comment #13)
(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 the assignee 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 <dimstar@opensuse.org> --- 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 IIRC, those macros were later (~2019) moved to rpm-config-SUSE -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c16 --- Comment #16 from Antonio Feijoo <antonio.feijoo@suse.com> --- (In reply to Dominique Leuenberger from comment #15)
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 the assignee 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 <jslaby@suse.com> --- 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 ? Another question: should we add Requires(post): suse-module-tools at all (instead of Requires(post): mkinitrd), provided we already have: Requires(pre): suse-kernel-rpm-scriptlets Requires(postun): suse-kernel-rpm-scriptlets ? -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c18 --- Comment #18 from Jiri Slaby <jslaby@suse.com> --- (In reply to Jiri Slaby from comment #17)
I'm not a bit confused.
Scratch the "not". -- You are receiving this mail because: You are the assignee 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 <msuchanek@suse.com> --- (In reply to Jiri Slaby from comment #17)
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 the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c20 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(martin.wilck@suse | |.com) --- Comment #20 from Jiri Slaby <jslaby@suse.com> --- Maybe Martin can answer comment 17 & 19? -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c21 --- Comment #21 from Antonio Feijoo <antonio.feijoo@suse.com> --- (In reply to Martin Wilck from comment #13)
(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 the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c22 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(martin.wilck@suse | |.com) | --- Comment #22 from Martin Wilck <martin.wilck@suse.com> --- (In reply to Jiri Slaby from comment #20)
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 the assignee 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 <msuchanek@suse.com> --- (In reply to Martin Wilck from comment #22)
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 the assignee 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 <martin.wilck@suse.com> --- (In reply to Michal Suchanek from comment #23)
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 the assignee 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 <martin.wilck@suse.com> --- Perhaps we need something like patterns-base-kernel, which would pull in everything that's necessary for ordinary management of the kernel, it's modules, and initramfs, like real PCs and VMs. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c26 --- Comment #26 from Martin Wilck <martin.wilck@suse.com> --- Note that s-m-t is required by A LOT of packages. All these would implicitly depend on dracut, too. The crucial dependency here is apparently this: suse-module-tools is needed by (installed) kmod-30-1.1.x86_64 Not sure why we have that; maybe because of modrobe.d? kmod is of course required by many packages. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c27 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@suse.com Flags| |needinfo?(lnussel@suse.com) --- Comment #27 from Martin Wilck <martin.wilck@suse.com> --- Meanwhile, we've got https://build.opensuse.org/request/show/1001373 @Ludwig, I'd prefer that we discuss how we want to proceed rather than just making changes. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c28 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(lnussel@suse.com) | --- Comment #28 from Ludwig Nussel <lnussel@suse.com> --- so what's the needinfo aobut? I wasn't aware of the discussion here. Anyway doesn't make sense to sit on my changes so there you are. Feel free to discuss. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c29 --- Comment #29 from Martin Wilck <martin.wilck@suse.com> --- For now: - why do you call the scriptlets "legacy"? What are you preparing instead? - is this just Factory/ALP material, or also for SLE? Anyway this bug is probably not the right place to discuss an overhaul of the kernel installation method. I just wanted to create a link here. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c30 --- Comment #30 from Martin Wilck <martin.wilck@suse.com> --- (In reply to Martin Wilck from comment #22)
(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 the assignee 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 <antonio.feijoo@suse.com> --- ping ALP is moving forward and we need to get rid of mkinitrd. What's the status of this task? -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c33 --- Comment #33 from Michal Suchanek <msuchanek@suse.com> --- So what is the situation? Kernel depends on mkinitrd bude never uses it: doc/README.SUSE: an initrd for the new kernel as well (see ``mkinitrd -h''). rpm/kernel-binary.spec.in:# packages to install/update. Likewise, this is true for mkinitrd. rpm/kernel-binary.spec.in:Requires(post): mkinitrd rpm/kernel-binary.spec.in:# Require a mkinitrd that can handle usbhid/hid-generic built-in (bnc#773559) rpm/kernel-binary.spec.in:Requires(post): mkinitrd >= 2.7.1 rpm/kernel-binary.spec.in:# Do not install p-b and mkinitrd for the install check, the %post script is rpm/kernel-binary.spec.in:#!BuildIgnore: perl-Bootloader mkinitrd distribution-release rpm/kernel-binary.spec.in:Requires(post): mkinitrd rpm/kernel-binary.spec.in:Requires(post): mkinitrd suse-module-tools use mkinitrd: kernel-scriptlets/rpm-script: # run depmod and mkinitrd kernel-scriptlets/rpm-script: echo "$wm2 does not exist, please run depmod and mkinitrd manually" >&2 suse-module-tools.spec:# "/usr/lib/module-init-tools" name hardcoded in KMPs, mkinitrd, etc. weak-modules: if [ -x /sbin/mkinitrd ]; then weak-modules: /sbin/mkinitrd -k /boot/$image-$krel -i /boot/initrd-$krel weak-modules: echo "Please run mkinitrd as soon as your system is complete." >&2 Also there is a couple of places where mkinitrd is mentioned in documentation. Since SLE15 SP4 mkinitrd is in a separate package so we cannot s/mkinitrd/dracut/ in kernel dependencies because that will potentially break on SP4 when suse-module-tools tries to call mkinitrd when building the kernel ramdisk. s/mkinitrd/suse-module-tools/ won't work either because s-m-t itself does not depend on mkinitrd. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c34 --- Comment #34 from Martin Wilck <martin.wilck@suse.com> ---
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 the assignee 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 <martin.wilck@suse.com> --- https://github.com/openSUSE/suse-module-tools/pull/69 -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c36 --- Comment #36 from Michal Suchanek <msuchanek@suse.com> --- With that it's clear that nothing should invoke mkinitrd, and s/mkinitrd/dracut/ should work. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c37 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #37 from Michal Suchanek <msuchanek@suse.com> --- Should be done here although packages may take time to get through Factory. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c46 --- Comment #46 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2023:1609-1: An update that solves 17 vulnerabilities and has 44 fixes can now be installed. Category: security (important) Bug References: 1177529, 1193629, 1197534, 1197617, 1198438, 1200054, 1202353, 1202633, 1203200, 1203331, 1204363, 1204993, 1205544, 1205846, 1206103, 1206232, 1206492, 1206493, 1206824, 1206935, 1207051, 1207270, 1207529, 1207560, 1207845, 1207846, 1208179, 1208212, 1208420, 1208449, 1208534, 1208541, 1208542, 1208570, 1208598, 1208599, 1208601, 1208605, 1208607, 1208628, 1208700, 1208741, 1208759, 1208776, 1208777, 1208784, 1208787, 1208816, 1208837, 1208843, 1208848, 1209008, 1209159, 1209188, 1209256, 1209258, 1209262, 1209291, 1209436, 1209457, 1209504 CVE References: CVE-2022-3523, CVE-2022-38096, CVE-2023-0461, CVE-2023-0597, CVE-2023-1075, CVE-2023-1076, CVE-2023-1078, CVE-2023-1095, CVE-2023-1118, CVE-2023-22995, CVE-2023-22998, CVE-2023-23000, CVE-2023-23004, CVE-2023-23559, CVE-2023-25012, CVE-2023-26545, CVE-2023-28328 Sources used: openSUSE Leap 15.4 (src): kernel-source-rt-5.14.21-150400.15.18.1, kernel-syms-rt-5.14.21-150400.15.18.1 SUSE Linux Enterprise Live Patching 15-SP4 (src): kernel-livepatch-SLE15-SP4-RT_Update_5-1-150400.1.3.1 SUSE Real Time Module 15-SP4 (src): kernel-source-rt-5.14.21-150400.15.18.1, kernel-syms-rt-5.14.21-150400.15.18.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c47 --- Comment #47 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2023:1608-1: An update that solves 24 vulnerabilities and has 112 fixes can now be installed. Category: security (important) Bug References: 1166486, 1177529, 1193629, 1197534, 1197617, 1198438, 1200054, 1202353, 1202633, 1203200, 1203331, 1203332, 1204363, 1204993, 1205544, 1205846, 1206103, 1206224, 1206232, 1206459, 1206492, 1206493, 1206640, 1206824, 1206877, 1206878, 1206880, 1206881, 1206882, 1206883, 1206884, 1206886, 1206894, 1206935, 1207036, 1207050, 1207051, 1207125, 1207270, 1207328, 1207529, 1207560, 1207588, 1207590, 1207591, 1207592, 1207593, 1207594, 1207603, 1207605, 1207606, 1207608, 1207609, 1207613, 1207615, 1207617, 1207618, 1207619, 1207620, 1207621, 1207623, 1207624, 1207625, 1207626, 1207630, 1207631, 1207632, 1207634, 1207635, 1207636, 1207638, 1207639, 1207640, 1207641, 1207642, 1207643, 1207644, 1207645, 1207646, 1207647, 1207648, 1207649, 1207650, 1207651, 1207652, 1207653, 1207768, 1207770, 1207771, 1207773, 1207795, 1207845, 1207875, 1208149, 1208153, 1208179, 1208183, 1208212, 1208290, 1208420, 1208428, 1208429, 1208449, 1208534, 1208541, 1208542, 1208570, 1208598, 1208599, 1208601, 1208605, 1208607, 1208628, 1208700, 1208741, 1208759, 1208776, 1208777, 1208784, 1208787, 1208816, 1208829, 1208837, 1208843, 1208848, 1209008, 1209159, 1209188, 1209256, 1209258, 1209262, 1209291, 1209436, 1209457, 1209504, 1209572 CVE References: CVE-2022-3523, CVE-2022-36280, CVE-2022-38096, CVE-2023-0045, CVE-2023-0122, CVE-2023-0461, CVE-2023-0590, CVE-2023-0597, CVE-2023-1075, CVE-2023-1076, CVE-2023-1078, CVE-2023-1095, CVE-2023-1118, CVE-2023-22995, CVE-2023-22998, CVE-2023-23000, CVE-2023-23001, CVE-2023-23004, CVE-2023-23454, CVE-2023-23455, CVE-2023-23559, CVE-2023-25012, CVE-2023-26545, CVE-2023-28328 Sources used: openSUSE Leap 15.4 (src): kernel-syms-azure-5.14.21-150400.14.40.1, kernel-source-azure-5.14.21-150400.14.40.1 Public Cloud Module 15-SP4 (src): kernel-syms-azure-5.14.21-150400.14.40.1, kernel-source-azure-5.14.21-150400.14.40.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c49 --- Comment #49 from Maintenance Automation <maint-coord+maintenance-robot@suse.de> --- SUSE-SU-2023:1710-1: An update that solves 19 vulnerabilities and has 111 fixes can now be installed. Category: security (important) Bug References: 1166486, 1177529, 1193629, 1197534, 1197617, 1198438, 1202353, 1202633, 1203200, 1203331, 1203332, 1204363, 1204993, 1205544, 1205846, 1206103, 1206224, 1206232, 1206459, 1206492, 1206493, 1206640, 1206824, 1206876, 1206877, 1206878, 1206880, 1206881, 1206882, 1206883, 1206884, 1206885, 1206886, 1206889, 1206894, 1206935, 1207051, 1207270, 1207328, 1207529, 1207560, 1207588, 1207589, 1207590, 1207591, 1207592, 1207593, 1207594, 1207603, 1207605, 1207606, 1207607, 1207608, 1207609, 1207610, 1207613, 1207615, 1207617, 1207618, 1207619, 1207620, 1207621, 1207623, 1207624, 1207625, 1207626, 1207628, 1207630, 1207631, 1207632, 1207634, 1207635, 1207636, 1207638, 1207639, 1207641, 1207642, 1207643, 1207644, 1207645, 1207646, 1207647, 1207648, 1207651, 1207653, 1207770, 1207773, 1207845, 1207875, 1208149, 1208153, 1208179, 1208183, 1208212, 1208290, 1208420, 1208428, 1208429, 1208449, 1208534, 1208541, 1208570, 1208598, 1208599, 1208601, 1208603, 1208605, 1208607, 1208628, 1208700, 1208741, 1208759, 1208776, 1208777, 1208784, 1208787, 1208816, 1208837, 1208843, 1208848, 1209008, 1209159, 1209188, 1209256, 1209258, 1209262, 1209291, 1209436, 1209457, 1209504 CVE References: CVE-2022-3523, CVE-2022-36280, CVE-2022-38096, CVE-2023-0045, CVE-2023-0461, CVE-2023-0597, CVE-2023-1075, CVE-2023-1076, CVE-2023-1078, CVE-2023-1095, CVE-2023-1118, CVE-2023-22995, CVE-2023-22998, CVE-2023-23000, CVE-2023-23004, CVE-2023-23559, CVE-2023-25012, CVE-2023-26545, CVE-2023-28328 Sources used: openSUSE Leap Micro 5.3 (src): kernel-default-base-5.14.21-150400.24.55.3.150400.24.22.7 openSUSE Leap 15.4 (src): kernel-obs-qa-5.14.21-150400.24.55.1, kernel-syms-5.14.21-150400.24.55.1, kernel-source-5.14.21-150400.24.55.2, kernel-default-base-5.14.21-150400.24.55.3.150400.24.22.7, kernel-obs-build-5.14.21-150400.24.55.3 SUSE Linux Enterprise Micro for Rancher 5.3 (src): kernel-default-base-5.14.21-150400.24.55.3.150400.24.22.7 SUSE Linux Enterprise Micro 5.3 (src): kernel-default-base-5.14.21-150400.24.55.3.150400.24.22.7 SUSE Linux Enterprise Micro for Rancher 5.4 (src): kernel-default-base-5.14.21-150400.24.55.3.150400.24.22.7 SUSE Linux Enterprise Micro 5.4 (src): kernel-default-base-5.14.21-150400.24.55.3.150400.24.22.7 Basesystem Module 15-SP4 (src): kernel-source-5.14.21-150400.24.55.2, kernel-default-base-5.14.21-150400.24.55.3.150400.24.22.7 Development Tools Module 15-SP4 (src): kernel-source-5.14.21-150400.24.55.2, kernel-syms-5.14.21-150400.24.55.1, kernel-obs-build-5.14.21-150400.24.55.3 SUSE Linux Enterprise Live Patching 15-SP4 (src): kernel-livepatch-SLE15-SP4_Update_10-1-150400.9.3.7 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply＠suse.com