Sorry I just discovered, that this thread isn't relayed (?!?) to the usenet newsgroup, so I wasn't aware of theses messages. I'm replying in just one message.
> > > > Does anyone know if the fs in Grub allows the kernel to load his > > > > necessary fs as modules? I.e. if Grub contains a an ext2 fs, can the > > [...] > > > Both the kernel and grub don't care about each other, in fact, both > > > don't no a thing about the other end [1]. So, yes, you still need > > > compiled-in kernel support for both the root fs and the disk type this > > > fs is on. And, if you want to use other filesystems or disk types after > > > booting the kernel, you either need kernel support compiled-in or as a > > > module. > > > > > Bad luck, so it never will be possible to have a fully modularized kernel. > > Sure you can ... use an initrd. I quote: "initrd is mainly designed to allow system startup to occur in two phases, where the kernel comes up with a minimum set of compiled-in drivers, and where additional modules are loaded from initrd" I think initrd is not meant to be used as a helper for for a kernel without built-in fs and drivers in general. It looks (IMHO) more like a hack in cases where space requirement enforces it. But how about if the root-fs of initrd resides on the boot track on the disk instead loaded into ram disk? The purpose of such an arrangement is not only to have a fully modularized kernel, it's more that the kernel can access any volume without having the necessary support already built-in. I envision a solution where the kernel can access a volume containing an fs which wasn't known when the kernel was compiled. ---------------------------------------------------------------------------- > Err, not so fast! I think HURD actually provides this, and grub has > hooks to load a specific module set for the HURD. It won't use that > module itself though. > Fine this could be the first real reason (for me) to switch to Hurd. O. Wyss