archive mirror
 help / color / mirror / Atom feed
* initial ramdisk failure
@ 2001-06-14  4:10 D. Stimits
  2001-06-14  7:34 ` D. Stimits
  0 siblings, 1 reply; 2+ messages in thread
From: D. Stimits @ 2001-06-14  4:10 UTC (permalink / raw)
  To: kernel-list

I have been trying for a while now, without luck, to get a kernel with
the SGI XFS system to boot as modules. I do fine if I make all scsi and
XFS as non-modules, but modules fail for both scsi and XFS (I can make
one or the other modular at a time, or both, it fails). According to
what I see, this should not be happening, but it is. All messages
indicate it was successful. I can also take the initial ramdisk image
and gzip, and create a file that I mount via loopback to actually view
the items it surprises, it has what it should have. But
lilo is not using it (the messages from lilo claim to, but proof is in
the failure). I'm going to list my output below, but the question will
be, for an SMP scsi aic7xxx system, noapic, with ext2 compiled in, and
/boot on its own ext2 partition (root is XFS), how is it possible that
this output lies and does not install scsi or XFS modules? Big note:
label with -2 is successful and has no modules; label with -3 fails, if
any part of filesystem XFS or scsi is modular, and otherwise, there are
no kernel configuration differences. Also, the "ramdisk_size" argument
of the relevant kernel is due to the size of XFS, just to be sure. The


# FAILS, modular.
        append="noapic ramdisk_size=16000"

# WORKS, no relevant modules, despite a ramdisk.

Creating the ramdisk (tried both with SGI's mkinitrd.xfs, as well as
regular mkinitrd):
mkinitrd \
 -v \
 -f \
 --preload pagebuf \
 --preload xfs_support \
 --preload xfs \
 --with=scsi_mod \
 --with=sd_mod \
 --with=aic7xxx \
 /boot/ir-2.4.6-p1-xfs-3.img \

The output of mkinitrd:
Using modules:  ./kernel/fs/pagebuf/pagebuf.o
./kernel/fs/xfs_support/xfs_support.o ./kernel/fs/xfs/xfs.o
./kernel/drivers/scsi/scsi_mod.o ./kernel/drivers/scsi/sd_mod.o
Using loopback device /dev/loop0
/sbin/nash -> /tmp/initrd.sXOMy4/bin/nash
/sbin/insmod.static -> /tmp/initrd.sXOMy4/bin/insmod
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/pagebuf/pagebuf.o' ->
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs_support/xfs_support.o' ->
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs/xfs.o' ->
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/scsi_mod.o' ->
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/sd_mod.o' ->
-> `/tmp/initrd.sXOMy4/lib/aic7xxx.o'
Loading module pagebuf with options 
Loading module xfs_support with options 
Loading module xfs with options 
Loading module scsi_mod with options 
Loading module sd_mod with options 
Loading module aic7xxx with options 

The output of lilo -v -v:
# lilo -v -v
LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger
'lba32' extensions Copyright (C) 1999,2000 John Coffman

Reading boot sector from /dev/sda
Merging with /boot/boot.b
Secondary loader: 11 sectors.
Mapping message file /boot/message
Message: 46 sectors.
Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-3
Setup length is 9 sectors.
Mapped 1607 sectors.
Mapping RAM disk /boot/ir-2.4.6-p1-xfs-3.img
RAM disk: 1304 sectors.
Added 2.4.6-p1-xfs-3
Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-2
Setup length is 9 sectors.
Mapped 2274 sectors.
Mapping RAM disk /boot/initrd-2.4.6-pre1-xfs-2.img
RAM disk: 500 sectors.
Added 2.4.6-p1-xfs-2 *
boot.backup.when-2.4.6-pre1-xfs-3 exists - no backup copy made.
Map file size: 34304 bytes.
Writing boot sector.

NOTE: It explicitly states "Mapping RAM disk
/boot/ir-2.4.6-p1-xfs-3.img", the relevant ramdisk. It lied. How can it
be? I've been going at this for a couple of weeks now with no success.

After using gzip -dc on the .img, and mounting it via loopback, here is
the content of linuxrc:

echo "Loading pagebuf module"
insmod /lib/pagebuf.o 
echo "Loading xfs_support module"
insmod /lib/xfs_support.o 
echo "Loading xfs module"
insmod /lib/xfs.o 
echo "Loading scsi_mod module"
insmod /lib/scsi_mod.o 
echo "Loading sd_mod module"
insmod /lib/sd_mod.o 
echo "Loading aic7xxx module"
insmod /lib/aic7xxx.o 

Here is the tree of the whole initial ramdisk from loopback mount:
|-- bin
|   |-- insmod
|   `-- nash
|-- dev
|   |-- console
|   |-- null
|   |-- ram
|   |-- systty
|   |-- tty1
|   |-- tty2
|   |-- tty3
|   `-- tty4
|-- etc
|-- lib
|   |-- aic7xxx.o
|   |-- pagebuf.o
|   |-- scsi_mod.o
|   |-- sd_mod.o
|   |-- xfs.o
|   `-- xfs_support.o
|-- linuxrc
|-- loopfs
`-- sbin
    |-- bin -> bin
    `-- modprobe -> /bin/nash

Something is wrong, it lacks scsi support if I make scsi a module, it
lacks XFS support if I make that a module. For all intents and purposes,
lilo totally ignored the ramdisk. Any possible clues at all how this
could be?

D. Stimits,

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-06-14  7:33 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-14  4:10 initial ramdisk failure D. Stimits
2001-06-14  7:34 ` D. Stimits

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).