Forwarding, per Takashi's suggestion. Let's keep the discussion here.
-------- Forwarded Message --------
Subject: Re: Heads up: sunsetting mkinitrd
Date: Tue, 18 May 2021 17:46:03 +0200
From: Takashi Iwai <tiwai(a)suse.de>
To: Daniel Molkentin <dmolkentin(a)suse.de>
CC: factory(a)lists.opensuse.org, packaging(a)lists.opensuse.org
On Tue, 18 May 2021 17:21:20 +0200,
Daniel Molkentin wrote:
> with the pending submission of Dracut 054, which removes mkinitrd from
> the upstream sources, it's time to finally remove mkinitrd in Factory,
> Changes starting with 054
> - mkinitrd will temporarily live in its own dracut-mkinitrd-deprecated
> package. It will still be installed when requiring "mkinitrd" and
> requires dracut, so nothing changes here.
> - If you only required dracut, but meant to require mkinitrd, you need
> to change this temporarily or change your scripts to directly call dracut.
> mkinitrd has always been a rather mediocre wrapper that claimed to keep
> compatibility with the SLES 11 implementation. However:
> - it has a lot of bugs, quite some documented (!) flags have never
> worked, others are marked unimplemented or will say so only if invoked.
> I see little point in doing that given
> - it adds little value over just using plain Dracut
> Differences in calling dracut over calling mkinitrd:
> - Dracut only updates the initrd for the currently running kernel,
> unless either a kernel version or --regenerate-all is called
> - mkinitrd updates the bootloader by default. Dracut has no such option.
> Then again, those are two different concerns that are only merged into a
> single command for convenience. Usually this should be invoked from the
> kernel install script.
> - mkinitrd parses the no longer existing /etc/sysconfig/kernel file.
> - mkinitrd handles xen-specific modules. I have not enough understanding
> of the state of Xen in Factory to judge whether this is still required.
> If so, it should be handled in a dracut module. However, judging by the
> fact that the default is sourced from the defunc'ed kernel sysconfig
> file, this is probably also dead.
> - mkinitrd has slightly different semantics on how to specify a boot
> device for NFS & Co.
> Point of Contact
> If you have concerns how this affects your package, please let us (me,
> Thomas Blume or Neil) know. For the Kernel and other packages that are
> definitely impacted once mkinitrd would go away (e.g. YaST), we will
> reach out separately and / or file bugzilla issues.
I believe that the more suitable place to post would have been
In anyway, two biggest breakages would be the kernel packages
themselves and suse-module-tools package. There can be a few KMP
packages that have dependency on mkinitrd, but they could be fixed
since the dependency should be superfluous.
For the kernel packages, at least two things, AFAIK:
* kernel-* binary packages have dependency on mkinitrd
* kernel-obs-build explicitly creates the initrd with mkinitrd.
Both are relatively easy to fix, I suppose.
However, the major pains would be rather for the scripts in
suse-module-tools package. Better to ask Martin Wilck about that.