Re: Problem with kernel-image-2.4.18-686-smp_2.4.18-5_i386 from testing
On Fri, May 24, 2002 at 09:47:52AM -0500, Ken Causey wrote:
> > Well, it makes sense to make the kernel executable, but
> > that doesn't seem to be the problem as the kernel seems to be
> > executing already (all that output is from the kernel, I think).
> >
> > It all looks normal until the end, when the kernel can't mount>
> > the root partition. You say you have a SCSI disk, but I don't
> > see any SCSI device drivers getting loaded in the kernel output.
> > So.... you have to find a kernel with SCSI support compiled in
> > and install that. This kernel seems to assume all buses are
> > PCI (and ISA?).
> >
> > HTH
>
> Perhaps I'm misunderstanding, but isn't the entire point of initrd to
> NOT have to compile everything and the kitchen sink into the kernel?
> The kernel very early on mounts a ramdisk from the initrd image at which
> point modules and things can be loaded before the kernel starts doing
> its thing, no?
>
> Perhaps I'm mistaken but I get the impression that the kernel is able to
> mount the initrd image:
Well, if you only have scsi then you can leave off the pci bus
support. As for mounting the initrd image I assumed you
were doing an install, so the image came from the install
medium (the network? a cd drive?)
Actually what's initrd? (see later in the message where I
learn what initrd is)
> > >RAMDISK: cramfs filesystem found at block 0
> > >RAMDISK: Loading 1988 blocks [1 disk] into ram disk... done.
>
> and it resides on the scsi hd. Or is this something else?
RAMDISK is a filesystem in the cpu's imagination (ie in its
memory). RAMDISK (and all the contents) goes away when you
reboot. It doesn't even persist after an unmount. It's handy
for making some operations faster when you have programs that
write temporary files. It's also handy as a place to put
a root filesystem on a machine with no writeable media (eg
on a write-protected floppy based firewall with no other disks).
I just looked up initrd, it seems it's a RAMDISK used at boot
time to be able to load a kernel which can then load a module
(the scsi module) during boot time.
Well I guess I don't know what I'm talking about. Sorry
for poking my nose in where it doesn't belong. Also you say
the RAMDISK is being loaded from the SCSI disk so the disk
is already being read... then again if you are still installing
from install medium the RAMDISK is coming from the install
medium too.
However I have one more silly idea... I assume your scsi drive
id is 08:02? Is that how you specify the root device in the
lilo file? Actually I don't remember seeing such a high id
number (8). My largest number is 6 and that's for the CD drive.
The other units are between 0 and 5 (no not all ids are used).
If you try other numbers you have to set the hardware (jumpers?
disp switches? something else? depending on the device) to the
other number as well as changing the configuration in the lilo
file. My hardware (Sun) has a prom prompt where I can ask the
machine about the scsi bus (probe-scsi). Does such a thing
exist on your hardware?
I usually put something like /dev/hda2 as the boot drive,
not scsi id numbers.
Also I use a separate partition /boot to contain the image (not
an initrd image). Then to specify the kernel image, I just
give the file name (the path to the image /boot/image is
just /image if you are only looking at the fs containing the
contents of /boot).
Ie, my system has:
/dev/sda1 /boot
/dev/sda2 /
silo contains (sparc loader, like lilo BUT NOT NECESSARILY ALL
THAT COMPATIBLE so read this with the view that maybe it
will help but maybe it won't)
partition=1
root=/dev/sdb2
timeout=100
image=1/vmlinuz-2.2.19-sun4u
label=linux
read-only
The image has the partition number "1" followed by the image name.
HTH
--
bjb@achilles.net
Welcome to the GNU age! http://www.gnu.org
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: