xfs
[Top] [All Lists]

Re: mkinitrd, ramdisk failure?

To: stimits@xxxxxxxxxx
Subject: Re: mkinitrd, ramdisk failure?
From: Walt H <waltabbyh@xxxxxxxxxx>
Date: Wed, 13 Jun 2001 18:59:20 -0700
Cc: "XFS: linux-xfs@xxxxxxxxxxx" <linux-xfs@xxxxxxxxxxx>
References: <Pine.LNX.4.33.0106131222080.5609-100000@vimfuego.saarinen.org> <3B26C626.24EC0F20@idcomm.com> <3B26CC5E.6050804@uswest.net> <3B26D839.E6C58E3E@idcomm.com> <3B26DCBB.2289C8FC@sigmastorage.com> <3B26E3DF.1B22B76A@idcomm.com> <3B26EFD1.723327FA@thebarn.com> <3B27E2B5.CB5E4CF6@idcomm.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux 2.4.6-pre3-xfs i686; en-US; rv:0.9.1) Gecko/20010607
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


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





<Prev in Thread] Current Thread [Next in Thread>