[Beowulf] cloning issue, hidden module dependency
Bogdan.Costescu at iwr.uni-heidelberg.de
Mon Dec 8 14:40:35 PST 2008
On Mon, 8 Dec 2008, David Mathog wrote:
> The straw that broke this particular camel's back was a decision
> (presumably by Mandriva, maybe by RedHat) to change in the kernel
> config BLK_DEV_IDE and BLK_DEV_IDEDISK from y to m, similarly,
> DEV_AMD74XX (and etc.) also changed from y to m.
You were just lucky previously that Red Hat engineers found a good
idea to put those into the kernel. How would you have felt if you were
booting an all-SCSI (to stay with old tech) system, where the IDE
drivers present in the kernel would not have helped ?
> As a consequence, they went from a system where a simple initrd
> would boot anywhere (as all the needed drivers were built into the
> kernel) to one where a much more complex initrd ended up being
> highly machine specific.
Sorry to disapoint you... the initrd was always machine specific. All
Red Hat docs specify that after modifying /etc/modules.conf or
/etc/modprobe.conf the initrd should be regenerated via mkinitrd so
that the next boot will use the proper drivers/settings.
As to the complexity of initrd: my current method choice for setting
up compute nodes is to sync a root FS from the master server during
the initrd, which means that I have to build an initrd. As I already
know what hardware components are in the node (which is also the case
f.e. when I run mkinitrd), it's easy to just add these modules to the
initrd archive and insert a few 'insmod module.ko' in the proper order
in the init script.
Having a monolithic kernel that "just works" on a large variety of
hardware means answering "y" to most drivers; the kernel itself would
then grow as large as the "immense initrd" that you mention. How would
that be better ?
IWR, University of Heidelberg, INF 368, D-69120 Heidelberg, Germany
Phone: +49 6221 54 8240, Fax: +49 6221 54 8850
E-mail: bogdan.costescu at iwr.uni-heidelberg.de
More information about the Beowulf