On Mar 4, 2009, at 9:10 AM, Seewer Philippe <philippe.seewer@xxxxxx>
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
