From: "D. Stimits" <stimits@idcomm.com>
To: kernel-list <linux-kernel@vger.kernel.org>
Subject: initial ramdisk failure
Date: Wed, 13 Jun 2001 22:10:03 -0600 [thread overview]
Message-ID: <3B28391B.60536489@idcomm.com> (raw)
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 contains...no 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
output:
lilo.conf:
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
vga=0x030c
default=2.4.6-p1-xfs-2
backup=boot.backup.when-2.4.6-pre1-xfs-3
# FAILS, modular.
image=/boot/vmlinuz-2.4.6-pre1-xfs-3
label=2.4.6-p1-xfs-3
initrd=/boot/ir-2.4.6-p1-xfs-3.img
read-only
root=/dev/sda6
append="noapic ramdisk_size=16000"
# WORKS, no relevant modules, despite a ramdisk.
image=/boot/vmlinuz-2.4.6-pre1-xfs-2
label=2.4.6-p1-xfs-2
initrd=/boot/initrd-2.4.6-pre1-xfs-2.img
read-only
root=/dev/sda6
append="noapic"
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 \
2.4.6-pre1-xfs-3
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
./kernel/drivers/scsi/aic7xxx/aic7xxx.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' ->
`/tmp/initrd.sXOMy4/lib/pagebuf.o'
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs_support/xfs_support.o' ->
`/tmp/initrd.sXOMy4/lib/xfs_support.o'
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs/xfs.o' ->
`/tmp/initrd.sXOMy4/lib/xfs.o'
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/scsi_mod.o' ->
`/tmp/initrd.sXOMy4/lib/scsi_mod.o'
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/sd_mod.o' ->
`/tmp/initrd.sXOMy4/lib/sd_mod.o'
`/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/aic7xxx/aic7xxx.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:
#!/bin/nash
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, stimits@idcomm.com
next reply other threads:[~2001-06-14 4:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-14 4:10 D. Stimits [this message]
2001-06-14 7:34 ` initial ramdisk failure D. Stimits
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B28391B.60536489@idcomm.com \
--to=stimits@idcomm.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).