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

[Colin Guthrie]

'Twas brillig, and Anssi Hannula at 15/12/11 13:07 did gyre and gimble:
> 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.

Yeah I guess it would be good to have the this cached into some kind of
matrix, but that might be a bit tricky in sh...

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/