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

Thu Dec 15 15:33:21 CET 2011

'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/
+