[vox-tech] ramdisk error booting Gentoo Linux

[ME]

On Mon, 15 Apr 2002, Matt Holland wrote:
> > In short, I would examine enabling RAMDisk support and Loopback support=
 in
> > your kernel. (Check block devices in make menuconfig for RAMDISK and
> > Loopback if you need them - you can also set your default RAMDIsk size
> > too for new RAMDisks that are enabled.)
>=20
>=20
> I made sure that RAMDISK was enabled, and I left the RAMDISK size set to=
=20
> the default value (I believe it was 4096, but I dunno if that's in bytes=
=20
> or Kb).  I also recall enabling loopback support, but couldn't find the=
=20
> line in .config this morning when I gave it another (cursory) look.

CONFIG_BLK_DEV_RAM=3D
CONFIG_BLK_DEV_RAM_SIZE=3D
CONFIG_BLK_DEV_LOOP=3D

Size of RAM Disk is Kb, so 4096 is 4096kB or 4MB.

> > Second, look at what dd is being called. If they size of data being
> > written by dd is greater than the default RAMDisk, then you may want to
> > change the default size when setting that option or ???
>=20
>=20
> Is this going to be somewhere in the init scripts?

I would expect it to be in a a startup script and would check your
/etc/rc?.d or /etc/init.d or whever they are placed. Do a grep for
"dd" and you may be able to find it.

> I must admit that I=20
> don't know much about what goes on between the beginning of the boot=20
> sequence and the appearance of the login prompt (perhaps I should read=20
> the "From power up to bash prompt HOWTO").  What I do know is that the=20
> Gentoo folks say "Gentoo linux bootscripts require either tmpfs or=20
> ramdisk support in the kernel," which is why I made sure I included=20
> ramdisk support, since tmpfs is not available in 2.2.

Another thing you can do is to examine what part of the bootup was
failing. Then when you examine the startup scripts, you should be able to
see a numbering system. The item that last started successfully should
have a file/script name that describes it. The next sequencial item from
that should be the target script that is causing you grief and is a place
to focus your attention.

If you are completely mystified by what happens in the script, you can try
inserting:
echo "point 1"
echo "point 2"
echo "point 3"=20
at different parts in the difficult script. WHen you see the fault arrive
after "point 1" is printed, but before "point 2" is printed, you can guess
the fault lies somewhere between those two points.

There may be another script called from the init/stratup script that
actually has the call to dd, and that script may be outside of the init
dir.

> > Verify the mointpoint "/mnt/.init.d..." actually exists if you presentl=
y
> > have ramdisk support enabled.
>=20
> Ah man, I so hoped that was the problem, but alas, the mountpoint does=20
> exist, so it's not so simple.
>=20
> =20
> > Also, what is dd being used to do with your RAMdisk?
> >=20
> > If you have a ramdisk-device enabled, you cane:
> > mkfs -t ext2 /dev/ram0
> > mount -t ext2 /dev/ram0 /mnt/point/here
>=20
>=20
> Can I try this at the point where I get the message "Give root password=
=20
> for maintenance..."?

You might be able to do that. What I would do is instead do a:
# mount
and maybe
# df
to see what is mounted, and where and how much space is free for each and
if they are mounted (rw) instead of (ro).
If you also knew which script failed, you can try toi manually issued the
instructions of the scrtipt by hand to see what can fix it.

If the item is not mounted, then you can try to make your own ramdisk and
formatt it and mount it like above and see if the script then works - or
prepend this to the script to see if it works after you manually insert
it.

> I guess my ignorance of exactly what state the=20
> system is in at this point leaves me a bit confused.  Is it correct to=20
> say that by the time I get my error, the kernel has made nice with most=
=20
> of the hardware and is just getting ready to start system services, so=20
> basic things like your suggested commands should work?  Please pardon my=
=20
> ignorance... you can say RTFM if you want!

RTFM. Hehe :-) when all of your filesystems are mounted, you should have
full access to all commands (there are of course exceptions.) With only
some of the filesystems mounted, you may be missing libs/so needed by
other apps or trees of bins available for running.

# mount -a
tries to mount all automoutable entries in /etc/fstab

> > Why not try each operation manually from their kernel?
> >=20
> > See if you can create a RAMDisk for use as a mountable filesystem. See =
if
> > you have the mount point they are looking for.See if it is requiring
> > writing to the ramdisk monted system.
>=20
> I'll try some stuff.  Thanks a lot for the suggestions
>=20
>=20
> >>This is on a new Gentoo Linux system that I built... er, almost built.=
=20
> >>I suspect that I may have screwed something up in the kernel build=20
> >>(something involving ramdisk support?), or maybe just in configuring=20
> >>Grub.  I'm using a custom compiled version 2.2.20 kernel, because I hav=
e=20
> >>an old ATAPI cd-rom that can't seem to mount media under 2.4 kernels.=
=20
> >>That's a little nonstandard for Gentoo, so it's possible that I followe=
d=20
> >>all of the instructions correctly, but that the instructions were=20
> >>wrong... pardon the rambling.
> >>
> >=20
> > That seems odd. Care to share your /proc/filesystems ?
> >=20
> > Does it include iso9660? Did you include support for this in your 2.4
> > kernel? How aboiut MS Joliet support?
> > (These options in kernel compilation can be found in the filesystems
> > section.)
>=20
>=20
> I know, I thought it was odd as well, but I'm pretty sure that this=20
> particular cd-rom has never worked with 2.4 kernels.  I originally=20
> noticed the problem when the same drive was in my main box running=20
> RedHat 7.0 or 7.1.  Strangely, I could use the cd-rom to install the=20
> system, but after that, I couldn't mount a filesystem (and yes, all of=20
> the filesystem support was there, this happened with stock kernels;=20
> besides the same systems were able to mount iso images as loopback=20
> devices).  I actually wrote to vox-tech with this problem last fall, and=
=20
> Pete tried valiantly to solve it, but we couldn't get it.  The ultimate=
=20
> solution was to buy myself a DVD drive, which was a welcome addition to=
=20
> the system ;)  However, now I'm trying to use the old drive in a "new"=20
> system (read: scavenged parts), and installs of Mandrake 7.1 and RedHat=
=20
> 7.x have worked fine, with the exception of the cd-rom.  I was hoping=20
> Gentoo would be different (for the record, in case Pete's reading this,=
=20
> Debian Potato was also fine... but I really like the idea of Gentoo).=20
> My guess is that something happened to the ATAPI cd-rom driver that=20
> "left behind" a certain class of older drives; unfortunately, it's=20
> beyond my abilities to find and fix such a bug if it really exists.

try:
# dmesg | grep "ide"
(Assuming an IDE based CDROM drive)
then:
# dmesg | grep ^hd

After the system is booted and see what you get.

If you see something that you can identify as the CD-ROM drive, then try
this:=A0(Asuming it is "hdc")
# cat /dev/hdc > /tmp/cd.iso
(Make sure you have at least 650Mb of disk space free in /tmp)
And see if the CD-ROM access light comes on and your HD light comes on.

If it does, you can let it finish and then see if you can mount the
resulting iso as an imnage via loopback. You could also, control-c and
interrupt the read/write and rm the resulting file.

> >>In any case, I'm wondering if anyone has seen a problem like this after=
=20
> >>compiling a new kernel; if so, any idea what's causing it?  A newsgroup=
=20
> >>search didn't turn up anything helpful (or even relevant), so I thought=
=20
> >>I'd let you guys take a crack at it before turning to gentoo-user.
> >>
> >=20
> > If the problems exist after a new kernel, but not in earlier ones, and =
you
> > are using the stable siries (lik 2.2, 2.4 etc) then odds are in favor o=
f
> > an unset option in your kernel config.
>=20
>=20
> Well, unfortunately, there is no "earlier" kernel, aside from the one on=
=20
> the boot/rescue disk.  This makes it a bit of a pain to fix, since in=20
> order to compile a new kernel, I have to boot with the rescue disk,=20
> mount my filesystems by hand, chroot, and go through the configuration=20
> process again.  I think maybe I'll try a 2.4 kernel next, b/c that=20
> should be more straightforward to get running since Gentoo was designed=
=20
> with 2.4 kernels in mind.

As an alternativem you can compile the kernel on another system and then
export the compiled kernel source tree as an NFS readOnly mount and then
mount it from the other system to make install the modules and copy the
kernel and get the System.map put in their proper places from the kernel
source.=20

Ah, wait. You *did* copy the System.map file to the (often) /boot
directory after compiling your kernel, right? I have seen a lack of doing
this cause some devices to fail. They were mostly ethernet and PCMCIA
based, but it is still something that should be done. I frequently use a
different name when I copy it like "System.map.2.2.20" for each kernel
compiled. (Just an off chance for this CD-ROM issue - not very likely to
fix it, but checking anyway.)

> In any case, thanks for the ideas.  I guess I'll have to start getting
> my hands dirty!

Sorry to be so long in not responding, I have had a tough headache and
been on some groovy medication. Just now trying to get caught up.

-ME

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++=
=20
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html