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

Anssi Hannula anssi at mageia.org
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


More information about the Mageia-dev mailing list