[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Slink _minimum_ install from 2.1.4 disks

On 9 Jan 1999, Adam Di Carlo wrote:
> No, well, this is where the lowmem.bin initrd stuff comes in.  Read
> the Installation Manual (that part needs big faclift, thought).
> What is chewing your memory is the big ramdisk that the root.bin loads
> into.  Plus the kernel.

I'll try a few tomorrow.

> Well, since you didn't use the lowmem.bin stuff, I suspect we could
> squeeze the total disk/swap requirements down.  Really, you should try
> the lowmem stuff!  If even just for fun...;)

It is a good thing that the drives made 10 years ago know how to have
"fun", eh.  :)
> > The fix for this error source is to have the software log VM and FS
> > status at the proper points in the installation procedure...  for
> > this distribution - during device driver configuration, and when
> > both the base archive and base files are on the hard disk.
> Oic.. interesting.  Because catting on tty2 takes up more ram, yes.

Well, ya, a little... I was referring to the error caused by the random 
sampling of FS and VM info.  Synchronizing the data collection with the
installation will allow sampling at known peaks in resource use, instead
of hoping that I sampled enough during the correct intervals.

> Interesting idea -- dunno if we'll get to it for a bit.

Thanks --  Aw, just hack the equiv of `echo $IDstring >> install.log;df >>
install.log;cat /proc/meminfo >> install.log` into the existing code, it
doesn't need to be distributed.  Nice stuff like automatically analysing
the data and updating the docs can wait 'til ya get tired of doing it by
hand.  ;)

> Excellent job, very thorough!

Thank you, I aim to please.

> > The hang-up problem is probably related to linux not being able to
> > figure out my hardware (how do I do a DOS `HIMEM /MACHINE:7'
> > equivalent?), which results in SEGVs from time to time.
> Well, the stock kernels are rather loaded up.  This can cause
> (intermittant) freezes with some peripheral/firmware combinations.

Hmmm, I am basing my theory on the fact that if I follow the directions
and set all available RAM as `extended' (or is it expanded, whatever),
Linux thinks I have (4096 + 384)k... this actually crashes the machine.
When I leave the 384k block as `expanded' memory, Linux sees 4096k and I
get SEGVs, sometimes, depending on what I am doing, or how long the
machine has been up, and (curiously, apparently) on how much free disk
space there is.  Sometimes I can go for days without a problem, 
other times dselect SEGVs as soon as it hands a job off to dpkg.  
Ya, I know, it is really dpkg SEGVing, but dpkg alone rarely gives me any
trouble.  Hmmm, does dselect test for RAM and add --smallmem to dpkg's
command line if available is below some set point (#72 on my todo list).

> I've been supporting PC installations since DOS 3.1.2, and there's
> always difficulties.  I suggest pulling out cards, and even taking the
> stock kernel-image and trying a few different recompiles, modifying
> the selected drivers.  The qlogicisp probe seems to kick up a lot of
> problems.

I would love to be able to compile a kernel, and pulling cards is out
 - it is an old laptop.  Unfortunately, anyone with a computer I know well
enough to ask if I can take over their machine for a few days, so I can
learn how to compile a kernel... well, lets just say that the look that
comes over their face is priceless.  I guess that's what happens when you
are raised as a user in the M$ and Mac WIMP world.

> I hope to document this process of that initial boot much better
> soon... I'm having a really hard time keeping up with comments and
> suggestions on the Install Manual, which is a mixed blessing, I guess.

You mean I'll have to wait... ;)
> It would be quite easy, btw, to strip down a kernel just for basic
> machines, i.e., if you had specialized needs (boot-floppies for
> embedded ROMfs anyone? ;)

At the risk of going past the point of going on too long...
There are lots of OS products for small embedded systems, what is scarce
are ones that can scale up to a full featured OS and UI with complete
networking capabilities.  Anything I am aware of comes out of the 
ATE/T&M world, i.e. very specialized and expensive.  Check out National
Instuments (www.natinst.com) if you are interested in that sort of thing.
Hmmm, I wonder if anyone is working on a VXI base for Debian...



p.s. - that's Automated Test Equipment, Test & Measurement, 
       and Vme eXtensions for Instrumentation

To UNSUBSCRIBE, email to debian-testing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: