Keith Owens wrote:
> On Wed, 28 Mar 2001 10:40:49 -0500 (EST),
> Dave Sill <ds-linux-xfs@xxxxxxxxxxxxxxxxx> wrote:
> >I checked out the current kernel source using CVS, copied over a
> >.config file provided by Eric Sandeen, configured in the IRIX
> >partition support, then did:
> >
> > make dep
> > make bzImage
> > make modules
> > make modules_install
> > make install
> > mkinitrd /boot/initrd-2.4.2-XFS.img 2.4.2-XFS
>
> Unless you are building a kernel that has to run on multiple machines
> with different hardware (i.e. a distribution) I strongly recommend that
> you do not use mkinitrd. Build your root driver and filesystem into
> the kernel, load other objects as modules after boot and forget initrd.
> It is good for distributors but a pain in the neck for everybody else.
I run almost all my system with XFS and the scsi drivers as modules loaded via
initrd
and have very few problems with the setup. The only drawback is that on RH
systems it
does take a bit of time to load each module, most of my systems are Mandrake
systems
and they load modules almost instantly... I have no idea what the differences
might be.
But Keith is correct if your building custom kernels it's easier to just
compile
everything in.
>
>
> >Everything seemed to go pretty smoothly during the build. When I boot
> >the new kernel, it's unable to load any modules. For example, if I
> >try:
> >
> ># insmod /lib/modules/2.4.2-XFS/kernel/drivers/block/loop.o
> >/lib/modules/2.4.2-XFS/kernel/drivers/block/loop.o: unresolved symbol dput
> >/lib/modules/2.4.2-XFS/kernel/drivers/block/loop.o: unresolved symbol
> >register_disk
>
> Use modprobe loop, not insmod /full/path/name.o. modprobe is a high
> level command which automatically loads any other modules that are
> required to satisfy missing symbols, insmod is a low level command
> which does exactly what you say and no more.
--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.
|