[Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.

Thu Dec 15 14:07:23 CET 2011

On 05.12.2011 22:37, Colin Guthrie wrote:
+> 'Twas brillig, and Anssi Hannula at 02/12/11 21:17 did gyre and gimble:
+>> On 02.12.2011 15:57, Anssi Hannula wrote:
+>>> On 02.12.2011 13:28, Colin Guthrie wrote:
+>>>> Hi,
+>>>>
+>>>> Just a suggestion! Should we move wholesale to dracut?
+>>>>
+>>>> It's very easy to hack on, and Harald Hoyer has been very helpful and
+>>>> has merged some of the patches we carried locally (which I mostly copied
+>>>> from Mandriva). Not sure why they were not upstreamed before.
+>>>>
+>>>> There are still a couple patches we carry locally (soon to be less when
+>>>> Harald pushes his git repo and I rebase), but they are pretty trivial,
+>>>> understandable and easily maintainable (mostly they will be stylistic
+>>>> tweaks and naming variations - i.e. very minor).
+>>>>
+>>>> Modprobe rules are included even in the initrd so tweaks there follow
+>>>> through.
+>>>>
+>>>> I'm not necessarily against keeping mkinitrd, but I think we should take
+>>>> the time from now until the beta phase to obsolte mkinitrd and force
+>>>> everyone to use dracut in order to see if there are any issues and then
+>>>> make the call before next beta or rc.
+>>>
+>>> +1
+>>>
+>>> One thing that doesn't work with dracut yet is that it only includes the
+>>> KMS drivers into initramfs if they are loaded at the time of initramfs
+>>> creation, causing unoptimal boot screen when a) initramfs created by the
+>>> installer (I guess), and when b) user has switched a driver non-kms -> kms.
+>>>
+>>> This can probably be solved by some patching of
+>>> modules.d/50plymouth/module-setup.sh, but I haven't looked at it closely
+>>> yet.
+>>
+>> Patch attached. I guess this would remain as a Mageia specific patch as
+>> the wanted behavior is dependant on how the distribution handles driver
+>> switching etc...
+>>
+>> Shall I apply it?
+> 
+> Just to pick up on this patch, here is a conversation I just had with
+> Harald on #dracut IRC:
+> 
+> coling> haraldh, the "more interesting" question (for various values of
+> "more interesting") was about a how hostonly works.... at the moment it
+> only includes modules that are already loaded... but in some cases you
+> want to include modules that are not currently loaded but do belong on
+> the h/w in question.
+> <coling> haraldh, one of the patches (that we believe might just have to
+> be a local one for the way we do things) is here:
+> http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0508-plymouth-Include-kms-modules-even-if-they-are-not-cu.patch?revision=175507&view=markup
+> <coling> It checks the module aliases against the current h/w. We do
+> this when we generate the initrd from the installer and include the KMS
+> modules even although they are not currently loaded.
+> <coling> I'm not sure if this is a mechanism you want to consider
+> supporting? e.g. perhaps "hostonly" mode could change to do things this
+> way (via modaliases) and a new "loadedonly" mode could suppliment
+> hostonly to give the current behaviour?
+> <coling> Or perhaps you could make hostonly={no|yes|loaded|hardware}
+> where yes is just a synonym for "loaded".
+> <coling> (I didn't write that patch by the way, so i'm just picking up
+> on the general principal with a view to seeing if the general concept
+> can be upstreamed)
+> <haraldh> hostonly, hmm, yes, greping for currently used modules was the
+> easiest and fastest way
+> <haraldh> to be more correct, we should do it with the aliases like in
+> your patch
+> <haraldh> but that is costly and takes a lot of time
+> <haraldh> and also the modprobe.conf.d is something one would want
+> <haraldh> and also install possible helper tools there
+> <haraldh> so, if you want to factor that one out in a module filter
+> function, send it to the initramfs mailing list
+> <haraldh> any help in that area is appreciated and most likely merged :)
+> 
+> 
+> So if you fancy working on this, I'm sure it'll get upstreamed :)
+
+I might take a look at this.
+
+Though, as Harald says, it might prove to be slow, since we'd have to
+compare every alias of every module considered by dracut against the
+system modalias list... Well, I guess we'll see.
+
+-- 
+Anssi Hannula
+