Walt H wrote:
>
> Hello,
>
> I've been running XFS compiled as modules for months now, so I know it
> can be done. I'm not sure if this should matter, but I always use
> --preload for the pagebuf & xfs_support modules. Also, I use just the
> stock-block mkinitrd command. Below is my exact syntax, which - works
> for me (tm) :)
>
> mkinitrd -v --preload pagebuf --preload xfs_support --with=reiserfs
> /boot/initrd-2.4.6-pre3.xfs.img 2.4.6-pre3-xfs
Short related question...have you tried this with mkinitrd.xfs? And does
your lilo.conf contain anything to increase initial ramdisk size, e.g.:
append="ramdisk_size=25000"
D. Stimits, stimits@xxxxxxxxxx
>
> This works without a hitch on my end. Hope this helps,
>
> -Walt
>
> D. Stimits wrote:
>
> >Russell Cattelan wrote:
> >
> >>"D. Stimits" wrote:
> >>
> >>>Matt Ryan wrote:
> >>>
> >>>>sorry, I meant to write that to the list as well. I just wrote:
> >>>>
> >>>>gzip -dc your.img > somefile
> >>>>mount -o loop somefile somedir
> >>>>
> >>>>also, just running mkinitrd with the verbose (-v) option is pretty
> >>>>helpful too
> >>>>(not sure if you were doing that already).
> >>>>
> >>>I've done -v, and also mounted each of the initrd images since then. I
> >>>definitely have the three modules I know of which are required:
> >>>pagebuf.o
> >>>xfs.o
> >>>xfs_support.o
> >>>
> >>note the modules must load in this order
> >>pagebuf
> >>xfs_support
> >>xfs
> >>
> >
> >I carefully made certain this was the order in the mkinitrd.xfs. It
> >still fails at the point of mounting root partition (note: this is a
> >hard drive, not floppy). There must be something else? My command line
> >for mkinitrd.xfs:
> >mkinitrd.xfs \
> > --with=pagebuf \
> > --with=xfs_support \
> > --with=xfs =\
> > /boot/initrd-2.4.6-pre1-xfs-3.img \
> > 2.4.6-pre1-xfs-3
> >
> >NOTE: The /boot partition seems to be read fine, and the scsi controller
> >is detected and works fine, including apparently the read of /boot. SCSI
> >is directly compiled in.
> >
> >D. Stimits, stimits@xxxxxxxxxx
> >
> >>When specifying them on the command the order they are
> >>given is the order they are loaded.
> >>
> >>The mkinird.xfs in the source tree just added the modules to the
> >>basicmodules list rather than having to list them by hand on the command
> >>line.
> >>
> >>Note the 0.9 release of XFS installed xfs as modules using mkinitrd.xfs to
> >>build
> >>the initrd, the 0.10 and 1.0 release did not do this since boots seem to
> >>take slightly
> >>less time with xfs in the kernel.
> >>
> >>>
> >>>Perhaps there is some kind of argument or order required that I don't
> >>>have? Or, since I compiled the kernel on RH 7.1 and used kgcc, would
> >>>there be some sort of change required to the compile of mkinitrd.xfs to
> >>>make it use kgcc as well? I noticed this URL does not have mkinitrd.xfs
> >>>man page:
> >>>http://oss.sgi.com/projects/xfs/manpages.html
> >>>
> >>>...and the cvs cmd/xfsmisc/ does not seem to produce one either. My
> >>>assumption is that this and the original mkinitrd are identical
> >>>(incidentally, I turned in a report to RH bugzilla that their man page
> >>>does not match the command line option syntax of mkinitrd --help...the
> >>>latter is accurate, the former not for --preload=<module>).
> >>>
> >>>So can *anyone* verify that it really is possible to run XFS as modules?
> >>>If so, can I get a list of modules you have under lsmod? Or if you
> >>>remember, a sample of the mkinitrd.xfs line used?
> >>>
> >>>D. Stimits, stimits@xxxxxxxxxx
> >>>
> >>>>Matt
> >>>>
> >>>>>While I'm convinced that this is the basic problem, I can't figure out
> >>>>>what is missing. Matt Ryan gave me one very useful command to mount my
> >>>>>initial ramdisk on loopback and see what it actually contains. I can
> >>>>>
> >>--
> >>Russell Cattelan
> >>cattelan@xxxxxxxxxxx
> >>
> >
|