Walt H wrote:
>
> Hello,
>
> I'm not all that familiar with mkinitrd.xfs as I use the standard
> "unpatched" mkinitrd under Mandrake 8.0 Does it need the --preload
> switches to preload the appropriate modules in order for XFS to work?
> Using stock mkinitrd I need to use:
>
> mkinitrd --preload pagebuf --preload xfs_support blah,blah,etc....
>
> That forces the ramdisk image to preload the proper support modules.
> Dunno, maybe mkinitrd.xfs already does this.
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
absolutely guarantee it contains:
pagebuf.o
xfs.o
xfs_support.o
I have tried this both using the "--with" and the "--preload" arguments.
I have tried both with the stock (but current) mkinitrd, as well as
mkinitrd.xfs that was from the same 2.4.6-pre1-xfs cvs. In all cases,
the kernel and other module items successfully unpack, e.g., module
based USB and ethernet modules successfully load. I even see the scsi
system load...without that, it could never even mount /boot/. I see it
succeeding at all things until it mounts the root filesystem. There must
be some other module I am missing...not just pagebuf, xfs, and
xfs_support. What is the fourth module? Can anyone here that has a
module-based XFS support give me a list of lsmod output?
D. Stimits, stimits@xxxxxxxxxx
>
> -Walt
>
> D. Stimits wrote:
>
> >Juha Saarinen wrote:
> >
> >>On Tue, 12 Jun 2001, D. Stimits wrote:
> >>
> >>>going to attempt a 2 floppy boot setup. However, either mkinitrd.xfs is
> >>>failing, or something with lilo config is failing. The system is scsi,
> >>>but scsi is being compiled in and not as a module.
> >>>
> >>Try compiling SCSI as modules instead -- that's what I've got here, and it
> >>works (Tekram controller plus two drives).
> >>
> >>Mkinitrd looks for the SCSI modules to put into the initial RAM disk
> >>image, so you'll need them.
> >>
> >>>It will instead say:
> >>>Kernel panic: VFS: Unable to mount root fs on 08:06
> >>>
> >>Sounds like the SCSI stuff isn't being loaded.
> >>
> >
> >That's the interesting part. The bootup shows that it booted /boot/, and
> >all scsi was detected and loaded. It was mounting of the root partition
> >(/boot is ext2, root is xfs) where it failed, due to lack of the initial
> >ramdisk providing XFS...but I think I did get XFS module into the
> >ramdisk. I wonder if there is a way to read an initial ramdisk image and
> >see if XFS did indeed make its way in. Guess I'll try again explicitly
> >forcing XFS into the ramdisk.
> >
> >>>The version that works I have as "2.4.6-pre1-xfs-2", the failed but
> >>>nearly identical version is labelled as "2.4.6-pre1-xfs-3". Here is the
> >>>lilo.conf (note that the i840 chipset must run with apic disabled to be
> >>>reliable...Intel seems to have broken the chipset):
> >>>
> >>Hmmm... the i850 works for me.
> >>
> >
> >The i840 IO-APIC can send spurious interrupt vectors for irq 217, which
> >does not exist. i850 is a completely different chipset. i840's without
> >the 64 bit pci slots have only one of the defective APIC items, while
> >those with 64 bit bus have more...mine has 3. 2 of those are tied to the
> >64 bit pci, which means pci activity is one of those locations it fails
> >under heavy load.
> >
> >>>Now it appends two items at once, both "noapic" and
> >>>"ramdisk_size=25000". Is the space separation the correct delimiter
> >>>between multiple append items (man page does not say)? Or maybe what is
> >>>happening is that it thinks the whole "25000 noapic" is what to set
> >>>"ramdisk_size" to (in which case it probably ignores the parameter
> >>>entirely)?
> >>>
> >>No, that's the correct one -- I used it here.
> >>
> >
> >So specifying both on one line as I did should work? I wasn't sure about
> >the space separator.
> >
> >>>There is also a kernel config item to allow initial ramdisk size to
> >>>default to something else, but is set to 4096 by default; thus the lilo
> >>>parameter should get around this for the larger ramdisk requirement.
> >>>Maybe I *must* also set this option during kernel compile also, and not
> >>>just for lilo?
> >>>
> >>This I'm not so sure about. If you read the README file for the kernel
> >>sources, it says:
> >>
> >> If you ever need to change the default root device, video mode,
> >> ramdisk size, etc. in the kernel image, use the 'rdev' program (or
> >> alternatively the LILO boot options when appropriate). No need to
> >> recompile the kernel to change these parameters.
> >>
> >
> >rdev would be for changing parameters of boot, but this is the first
> >time this kernel with this configuration has been installed. The old
> >entry still exists until I can get the new one to work right. The kernel
> >itself was reconfigured.
> >
> >>Also, the Documentation/ramdisk.txt appears to say that you can change the
> >>size, without recompiling.
> >>
> >
> >Right, there are two possible ways to change it, I didn't know if both
> >were required (this is one of my questions). Sounds like either/or will
> >work. But since I'm not using the same exact kernel configuration, and
> >this is an extra kernel rather than just a partial reconfig of old, this
> >will be the first time I have booted with XFS supported only by module.
> >
> >D. Stimits, stimits@xxxxxxxxxx
> >
> >>--
> >>Regards,
> >>
> >>Juha
> >>
> >>PGP fingerprint:
> >>B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544
> >>
> >
|