Dracut on different distros?
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · 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'...
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.
Quoted 2 lines
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.
Quoted 2 lines
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/.udevmight 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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 1 line
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.
Quoted 8 lines
Regards,
Philippe--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 0227279C-8C23-4501-B163-04470D0C0F35-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Quoted 8 lines
Quoted 5 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 82ecf08e0903040820t42775dd8s56e32d9d5dd53c36-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 7 lines · Thiago Galesi
Quoted 6 lines
Quoted 4 lines
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.
Quoted 6 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Victor Lowther wrote:
[snip]
Quoted 3 lines
Quoted 1 line
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]
Quoted 3 lines
Quoted 1 line
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Seewer Philippe
Victor Lowther wrote:
[snip]Quoted 2 lines
Quoted 1 line
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.
Quoted 7 lines
[snip]
Quoted 2 lines
Quoted 1 line
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.
Quoted 2 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 14BAD8D9-B114-4979-B9CE-BA20CEEF768D-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Quoted 11 lines · Victor Lowther
Quoted 7 lines · Seewer Philippe
Victor Lowther wrote:
[snip]Quoted 2 lines
Quoted 1 line
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Seewer Philippe
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
Signature · 5 lines
http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html