On Sun, 17 Nov 2002, Pawel Idzi wrote:
> On Fri, 15 Nov 2002, Reginald R. Richardson wrote:
>
> > And my test one, for new releases, new pakages, is a Compaq deskpro 486
> > /66, and from version rc2 wroks perfect on it, without any problem, I
> > use the same identical copy of my production, and I have no problem with
> > it
>
> On Fri, 15 Nov 2002, JamesSturdevant wrote:
>
> > No. It works fine on a 486. I'm running it on one right now with 20MB ram.
> > It is slow to boot, but once running it works great.
>
> On Fri, 15 Nov 2002, JeeBak Kim wrote:
>
> > Default Bering works fine on my 486 (IBM ThinkPad 755CSE 486 DX/4.)
> > Here is some output from Bering rc3... should upgrade now that 1.0
> > stable is out but rc3 has been rock stable as-is for me since I
> > first installed it ;).
>
> OK :) You're lucky guys:))
> So now I know from you that Bering is working on 486, maybe not on all
> 486s (for example - mine)
>
> > The issue, I believe, is that there is not enough memory. PC recyclers and
> > ebay may be your friend in this case.
>
> My 486 has 8MB RAM. Maybe later I'll put to this more RAM, but now...
Mistake.
> On Fri, 15 Nov 2002, guitarlynn wrote:
>
> > I don't believe the stock Bering kernel supports a non-FPU processor
> > (SX). There are alternate kernels available for Dachstein to run on
> > SX's on Charles' site. The 8M of Ram will need modification to work
> > on, which is possible but not preferred as long as you load minimal
> > packages and log Ramdisk. If there is a i586 kernel floating around,
> > I am sure it is a mistake and should be located/corrected. I can't say
> > that I can remember anyone having problems with a K5 chip, but that
> > could also be a (remote) possibility as well.
>
> ...I've done little experiment with Bering 1.0rc4. I created floppy
> bootdisk 1.44 with Bering. I've cut packages and syslinux.cfg now looks
> like:
>
> display syslinux.dpy
> timeout 0
> default linux initrd=initrd.lrp syst_size=2600K log_size=100K
> tmp_size=600K init=/linuxrc root=/dev/ram0 boot=/dev/fd0:msdos
> PKGPATH=/dev/fd0 LRP=root,etc,local,modules,iptables
>
> I tryed this on my desktop (iCeleron 333 with 192 MB RAM) and it boots of
> course. The TMPFS is used in 98% so it has a little free space. /var/log
> I've limitted to 100kB and /tmp to 600kB (to backup be still possible
> - none of packages is bigger then 600kB).
>
> Then I tryed this on my 486 with 8 MB RAM. Here is what I've seen:
So you have shown that, if the kernel is not an issue, then the ramdisks
are big enough. Hmmm.. so your disks are 2600+600+100=3300K... that leaves
about 4.7MB for the kernel, networking buffers, init, getty, sh, and any
other programs you need to run. I can't say for certain that that is not
enough, but it seems tight at best.
One thing to be aware of... the "syst_size" parameter doesn't guarantee
that the disk will be that big... it only sets a maximum limit for the
memory it will occupy. Thus, anything already in memory will push into
that "allocation", and only when data starts getting loaded into memory
will the problem appear, with the ramdisk "full" even though less than
"syst_size" KB of data have been put into it.
> [to this moment all was OK]
> INIT: version 2.78 booting
> update-rc.d: not found
> INIT: Entering runlevel: 2
> INIT: cannot execute "/sbin/getty"
> INIT: cannot execute "/sbin/getty"
> INIT: cannot execute "/sbin/getty"
> ... [about ten or more the same lines]
> INIT: cannot execute "/sbin/getty"
> INIT: cannot execute "/sbin/getty"
> INIT: cannot execute "/sbin/getty"
> INIT: Id "1" respawning too fast: disabled for 5 minutes
This is a classic behavior when init is unable to run terminal management
programs. This often shows up when a serial port is missing and the
configuration expects one to be there and attempts to run mgetty on the
serial port.
In this case, init is running, so root.lrp loaded. However, the first
hint of an error is when update-rc.d is not found... I think this is a
POSIXness shell script function in lib/POSIXness/POSIXness.linuxrouter.
This file is supposed to be in root.lrp along with init, but the symbolic
link to it is not there or the file is missing.
If the ramdisk "filled" up before root.lrp was completely extracted, then
part of root.lrp could be missing. As I pointed out above, this could
happen if you don't have enough RAM, even though everything worked fine
on your memory-fat machine with the same ramdisk size settings.
Your 486 is not at fault because you would never have reached this point
if it was. Guitarlynn's guess about the disk not reading large floppies
missed your assertion that this is a 1440 disk, so that seems to be a red
herring. The disk drive _could_ be bad, but your test on the Celeron
seems to indicate that the disk and files are good.
Memory is the only remaining impediment I can think of.
> I don't know where is the problem? In hardware? Is there anyone who did it
> - runing Bering on 486 with 8 MB RAM?
I gave up on that a long time ago... even when it worked with the old LRP
2.9.4, I often had difficulty with the machine locking up temporarily
until memory was freed by timing out masquerading entries. At
unpredictable times, the memory would be so low I could not run "ls".
In my opinion, if you need to run in 8MB, you need to build your own
installation of linux that does not use a ramdisk, because you cannot
spare it.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
