@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.)

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?

(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.

(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?

> (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...

(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.

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.

Dominique, can you confirm comment 7?

clearing needinfo on myself for now

(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)

(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?

(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:Factory:bsc1202353/dracut

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

(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

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
?

(In reply to Jiri Slaby from comment #17)
> I'm not a bit confused.

Scratch the "not".

(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

Maybe Martin can answer comment 17 & 19?

(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

(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.

(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?

(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 :-)

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.

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.

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.

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.

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.

(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.

This is an autogenerated message for OBS integration:
This bug (1202353) was mentioned in
https://build.opensuse.org/request/show/1038933 Factory / suse-module-tools

ping

ALP is moving forward and we need to get rid of mkinitrd. What's the status of this task?

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.

> 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.

https://github.com/openSUSE/suse-module-tools/pull/69

With that it's clear that nothing should invoke mkinitrd, and s/mkinitrd/dracut/ should work.

Should be done here although packages may take time to get through Factory.

This is an autogenerated message for OBS integration:
This bug (1202353) was mentioned in
https://build.opensuse.org/request/show/1072149 Factory / suse-module-tools