Dracut on different distros?

Dracut on different distros?

[Seewer Philippe]

Hello all

...I'm starting a new subject on this for the sake of my brain. Mixing 
patches and important discussions always gets me heavily confused...


First of all, please remember that Debian has a certain policy and even 
though we should make Dracut work on Debian, Debian itself certainly 
won't adopt Dracut until at least the next full release. Which we all 
know will be released when its ready.


Second I have to ask how far Dracut needs (and wants) to go with the 
"One initrd to rule them all". The different distros will need to 
customize the initrd anyway. Think in terms of splash-screens, different 
versions of utilities and configs or just plain 'crazy and convoluted'...

So why not just go the way of 'as generic as possible', provide the 
common denominator and let the Distros sort out the rest?

An example: As Kay pointed out, we can never know if the provided rules 
really are the right ones. Getting to root might work but what about 
after that? Some stored information in /dev/.udev might be horribly 
incompatible. Best leave it to the Distro or local maintainer to tell 
Dracut which udev parts are the "good" ones.

Another example: As seen, we need to load a keymap for say, cryptroot. 
But which keymap? And where is it stored? Leave that to the Distro if it 
wants to load one.

And another example: Yes, Debian and Ubuntu don't provide 
modules.{block,net,...} Can we really find a way of finding all block 
drivers? Certainly stupid me can't think of a way to be sure we "really 
really" have all block drivers without including every single .ko. Leave 
it to the user to specifically set drivers or the Distro to tell Dracut 
which drivers to include.


I'm thinking of a debootstrappish system of suite/target (or 
topic/flavour) where Dracut specifically delegates those tasks away it 
cannot solve on its own. We might even provide some simple things like 
just including all drivers for testing purposes or as a fallback solution.


Regards,
Philippe

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut on different distros?

[Victor Lowther]

On Mar 4, 2009, at 9:10 AM, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>  
wrote:

> Hello all
>
> ...I'm starting a new subject on this for the sake of my brain.  
> Mixing patches and important discussions always gets me heavily  
> confused...
>
>
> First of all, please remember that Debian has a certain policy and  
> even though we should make Dracut work on Debian, Debian itself  
> certainly won't adopt Dracut until at least the next full release.  
> Which we all know will be released when its ready.
>
>
> Second I have to ask how far Dracut needs (and wants) to go with the  
> "One initrd to rule them all". The different distros will need to  
> customize the initrd anyway. Think in terms of splash-screens,  
> different versions of utilities and configs or just plain 'crazy and  
> convoluted'...

I would have the goal of making dracut be able to generate a working  
no-frills initramfs with minimal (preferably no) distro customization,  
and have a hook structure that allows the distros to customize the  
initrams without having to patch things.

>
> So why not just go the way of 'as generic as possible', provide the  
> common denominator and let the Distros sort out the rest?

That is my goal, at least.

>
> An example: As Kay pointed out, we can never know if the provided  
> rules really are the right ones. Getting to root might work but what  
> about after that? Some stored information in /dev/.udev might be  
> horribly incompatible. Best leave it to the Distro or local  
> maintainer to tell Dracut which udev parts are the "good" ones.

Based on what Kay has said, it seems like Debian is the odd man out  
here - other distros just use the upstream udev rules to the extent  
feasible.

>
> Another example: As seen, we need to load a keymap for say,  
> cryptroot. But which keymap? And where is it stored? Leave that to  
> the Distro if it wants to load one.

Yep.

>
> And another example: Yes, Debian and Ubuntu don't provide modules. 
> {block,net,...} Can we really find a way of finding all block drivers?

Nope. I have a workaround that will work as long as the directory  
structure under /lib/modules/ stays reasonable, but there is no  
reasonable way to enforce that it will always work.

> Certainly stupid me can't think of a way to be sure we "really  
> really" have all block drivers without including every single .ko.  
> Leave it to the user to specifically set drivers or the Distro to  
> tell Dracut which drivers to include.

Indeed.

> I'm thinking of a debootstrappish system of suite/target (or topic/ 
> flavour) where Dracut specifically delegates those tasks away it  
> cannot solve on its own. We might even provide some simple things  
> like just including all drivers for testing purposes or as a  
> fallback solution.

Let's see how the current modules/hooks mechanism works for now. We  
can extend or scrap it if it turns out to not suit our needs.

>
> Regards,
> Philippe
>
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs"  
> in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut on different distros?

[Thiago Galesi]

>
>> Certainly stupid me can't think of a way to be sure we "really really"
>> have all block drivers without including every single .ko. Leave it to the
>> user to specifically set drivers or the Distro to tell Dracut which drivers
>> to include.
>
> Indeed.
>

Isn't this two different things?

I mean, it's one thing to have a "generic" initrd for, I dunno, live
CDs, etc and another thing to generate for a specific
computer/installation. And even installation triggers run mkinitrd (or
similar), no?

Thiago Galesi
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut on different distros?

[Seewer Philippe]

Thiago Galesi wrote:
>>> Certainly stupid me can't think of a way to be sure we "really really"
>>> have all block drivers without including every single .ko. Leave it to the
>>> user to specifically set drivers or the Distro to tell Dracut which drivers
>>> to include.
>> Indeed.
>>
> 
> Isn't this two different things?
> 
> I mean, it's one thing to have a "generic" initrd for, I dunno, live
> CDs, etc and another thing to generate for a specific
> computer/installation. And even installation triggers run mkinitrd (or
> similar), no?

It entirely depends on your point of view. The contents of the actually 
generated initrd might be very different. At least the contained modules 
could differ, the rest of the initrd could actually be the same.

And how we generate those images might not differ from use-case to the 
next at all.


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut on different distros?

[Seewer Philippe]

Victor Lowther wrote:
[snip]
>> Second I have to ask how far Dracut needs (and wants) to go with the 
>> "One initrd to rule them all". The different distros will need to 
>> customize the initrd anyway. Think in terms of splash-screens, 
>> different versions of utilities and configs or just plain 'crazy and 
>> convoluted'...
> 
> I would have the goal of making dracut be able to generate a working 
> no-frills initramfs with minimal (preferably no) distro customization, 
> and have a hook structure that allows the distros to customize the 
> initrams without having to patch things.

Yes, that's why I suggested Fallbacks (or maybe we should call them 
"sane defaults").
I see a few problems with the modules/hook structure though: If, for 
example, we provide a generic find-modules and the distro wants 
completely other functionality, that part of Dracut would have to be 
changed/disabled. That's a "patch" for me.


[snip]
>> I'm thinking of a debootstrappish system of suite/target (or 
>> topic/flavour) where Dracut specifically delegates those tasks away it 
>> cannot solve on its own. We might even provide some simple things like 
>> just including all drivers for testing purposes or as a fallback 
>> solution.
> 
> Let's see how the current modules/hooks mechanism works for now. We can 
> extend or scrap it if it turns out to not suit our needs.

I was thinking a bit along the line of what should be included on a 
netboot initrd. Personally I wouldn't want to see hooks for cryptsetup 
or lvm in it. Hence the idea of suite/target to select maybe a distro 
(could be 'dracut' for generic) and different targets (might be netboot 
or a combination of block,crypt,lvm).

But well... I guess I'm violating list rules again. Patches speak more 
than words, I'll see what I can cook up.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut on different distros?

[Victor Lowther]

On Mar 4, 2009, at 10:40 AM, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>  
wrote:

> Victor Lowther wrote:
> [snip]
>>> Second I have to ask how far Dracut needs (and wants) to go with  
>>> the "One initrd to rule them all". The different distros will need  
>>> to customize the initrd anyway. Think in terms of splash-screens,  
>>> different versions of utilities and configs or just plain 'crazy  
>>> and convoluted'...
>> I would have the goal of making dracut be able to generate a  
>> working no-frills initramfs with minimal (preferably no) distro  
>> customization, and have a hook structure that allows the distros to  
>> customize the initrams without having to patch things.
>
> Yes, that's why I suggested Fallbacks (or maybe we should call them  
> "sane defaults").
> I see a few problems with the modules/hook structure though: If, for  
> example, we provide a generic find-modules and the distro wants  
> completely other functionality, that part of Dracut would have to be  
> changed/disabled. That's a "patch" for me.

Hmmm... I am not seeing the difficulty here. Perhaps a code snippet or  
a more detailed use case would help.

>
>
> [snip]
>>> I'm thinking of a debootstrappish system of suite/target (or topic/ 
>>> flavour) where Dracut specifically delegates those tasks away it  
>>> cannot solve on its own. We might even provide some simple things  
>>> like just including all drivers for testing purposes or as a  
>>> fallback solution.
>> Let's see how the current modules/hooks mechanism works for now. We  
>> can extend or scrap it if it turns out to not suit our needs.
>
> I was thinking a bit along the line of what should be included on a  
> netboot initrd. Personally I wouldn't want to see hooks for  
> cryptsetup or lvm in it. Hence the idea of suite/target to select  
> maybe a distro (could be 'dracut' for generic) and different targets  
> (might be netboot or a combination of block,crypt,lvm).

That can be handled by having an /etc/dracut.conf that contains a  
dracutmodules="my modules here" line. The default is "all", which  
loads all the modules on initramfs creation. Extending that  
functionality should not be a problem to define some defaults other  
than including everything.

>
> But well... I guess I'm violating list rules again. Patches speak  
> more than words, I'll see what I can cook up.

I look forward to them. :)
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut on different distros?

[Harald Hoyer]

Victor Lowther wrote:
> On Mar 4, 2009, at 10:40 AM, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org> 
> wrote:
> 
>> Victor Lowther wrote:
>> [snip]
>>>> Second I have to ask how far Dracut needs (and wants) to go with the 
>>>> "One initrd to rule them all". The different distros will need to 
>>>> customize the initrd anyway. Think in terms of splash-screens, 
>>>> different versions of utilities and configs or just plain 'crazy and 
>>>> convoluted'...
>>> I would have the goal of making dracut be able to generate a working 
>>> no-frills initramfs with minimal (preferably no) distro 
>>> customization, and have a hook structure that allows the distros to 
>>> customize the initrams without having to patch things.
>>
>> Yes, that's why I suggested Fallbacks (or maybe we should call them 
>> "sane defaults").
>> I see a few problems with the modules/hook structure though: If, for 
>> example, we provide a generic find-modules and the distro wants 
>> completely other functionality, that part of Dracut would have to be 
>> changed/disabled. That's a "patch" for me.
> 
> Hmmm... I am not seeing the difficulty here. Perhaps a code snippet or a 
> more detailed use case would help.

Well, you could specify which modules to use in dracut.conf. Just add your 
modules and leave out the modules you don't want. No "patch" involved.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dracut on different distros?

[Dave Jones]

On Wed, Mar 04, 2009 at 04:10:10PM +0100, Seewer Philippe wrote:
 
 > And another example: Yes, Debian and Ubuntu don't provide 
 > modules.{block,net,...} Can we really find a way of finding all block 
 > drivers? Certainly stupid me can't think of a way to be sure we "really 
 > really" have all block drivers without including every single .ko. Leave 
 > it to the user to specifically set drivers or the Distro to tell Dracut 
 > which drivers to include.
 
It's not really that difficult.
Those files are created in Fedora by the kernel rpm %post, which does this..

    find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f >modnames

    fgrep /drivers/ modnames | xargs --no-run-if-empty nm -upA |
    sed -n 's,^.*/\([^/]*\.ko\):  *U \(.*\)$,\1 \2,p' > drivers.undef

    collect_modules_list()
    {    
      sed -r -n -e "s/^([^ ]+) \\.?($2)\$/\\1/p" drivers.undef |
      LC_ALL=C sort -u > $RPM_BUILD_ROOT/lib/modules/$KernelVer/modules.$1
    }    

    collect_modules_list networking \
                         'register_netdev|ieee80211_register_hw|usbnet_probe'
    collect_modules_list block \
                         'ata_scsi_ioctl|scsi_add_host|blk_init_queue|register_mtd_blktrans|scsi_esp_register'


This looks complicated, but it really boils down to
"create a list of modules that use these symbols"

Rather than add this to every distros kernel packages though, it could
be done as part of depmod, and moved to module-init-tools.

	Dave

-- 
http://www.codemonkey.org.uk
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html