From: Igor Gueths <igueths@attbi.com>
To: speakup@braille.uwo.ca
Subject: Re: update on inode problem
Date: Fri, 8 Nov 2002 17:23:31 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.44.0211081714250.15007-100000@igueths> (raw)
In-Reply-To: <200211080832.gA88WUa15732@sunset.net>
Hi Ralph. Btw, my system is working fine, its this bootable Cd distro that
I can't get quite working yet. Now I have tried changing the ramdisk size
to 32768 and it still doesn't work. I have noticed all the problems come
after starting busybox. The filesystem is mounting properly, or this is
what the kernel reports during its half boot sequence. Does anyone know if
busybox does any filesystem checks and perhaps this is what is causing the
problems? Does anyone know if perhaps I throw in the regular binaries
busybox uses and that fixes it? Thanks!
May you code in the power of the source,
may the kernel, libraries, and utilities be with you,
throughout all distributions until the end of the epoch.
On Fri, 8 Nov 2002, Ralph W. Reid wrote:
> Igor Gueths staggered into view and mumbled:
> >
> >Hi all. Well after digging into this problem a bit further, I figured out
> >that the 1:0 reported in the errors about ext2_read_inode were refering to
> >/dev/ram0 according to /usr/src/linux/Documentation/devices.txt. That
> >would explain why changing the root.bin image never fixed the problem.
> >Does anyone know why /dev/ram0 would report this type of error after the
> >kernel mounted the EXT2_fs using the initrd? One thing I am going to try
> >is to change the ramdisk_size to 16385 KB. It is currently set to 4096,
> >and vanilla flavor is what isolinux is defaulting to at the moment. Does
> >anyone have any other suggestions besides changing the disksize? Thanks!
>
> Hmmm. I wonder if this is an indication of a bit of bad RAM. I have
> heard that Linux is not very tolerant of bad memory, but RAM problems
> are rare enough that I have never heard exactly how they manifest
> themselves. If all else fails (and I do mean _all_ else), you might
> try swapping memory module locations on your mother board to see if
> this affects the situation at all. RAM failures are very rare, but
> they can happen. The simple RAM test performed during system boot
> can miss some memory errors, but this is pretty rare as well. I hope
> you can get your system working soon.
>
> Have a _great_ day!
>
>
>
> --
> Ralph. N6BNO. Wisdom comes from central processing, not from I/O.
> rreid@sunset.net http://personalweb.sunset.net/~rreid
> Opinions herein are either mine or they are flame bait.
> y = x ^ LOG_B (x, y)
>
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
next prev parent reply other threads:[~ UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
Igor Gueths
` Ralph W. Reid
` Igor Gueths [this message]
` Gregory Nowak
` Igor Gueths
` Gregory Nowak
` Kerry Hoath
` Gregory Nowak
` Kerry Hoath
` Kerry Hoath
` Igor Gueths
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=Pine.LNX.4.44.0211081714250.15007-100000@igueths \
--to=igueths@attbi.com \
--cc=speakup@braille.uwo.ca \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).