https://bugzilla.suse.com/show_bug.cgi?id=1202353 https://bugzilla.suse.com/show_bug.cgi?id=1202353#c1 Jiri Slaby 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 --- @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#c3 Michal Suchanek changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(msuchanek@suse.co | |m) | --- Comment #3 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? (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#c5 Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |SHIP_STOPPER? --- Comment #5 from 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 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 --- 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#c9 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(martin.wilck@suse | |.com) | --- Comment #9 from Martin Wilck --- 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 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#c13 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |antonio.feijoo@suse.com Flags| |needinfo?(antonio.feijoo@su | |se.com) --- Comment #13 from Martin Wilck --- (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#c15 --- Comment #15 from Dominique Leuenberger --- 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#c17 --- Comment #17 from Jiri Slaby --- 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#c19 --- Comment #19 from Michal Suchanek --- (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#c21 --- Comment #21 from Antonio Feijoo --- (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#c23 --- Comment #23 from Michal Suchanek --- (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#c25 --- Comment #25 from Martin Wilck --- 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#c27 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@suse.com Flags| |needinfo?(lnussel@suse.com) --- Comment #27 from Martin Wilck --- 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#c29 --- Comment #29 from Martin Wilck --- 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#c32 --- Comment #32 from Antonio Feijoo --- 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#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 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 --- 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#c46 --- Comment #46 from Maintenance Automation --- 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#c49 --- Comment #49 from Maintenance Automation --- 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.