Re: Slink _minimum_ install from 2.1.4 disks
On Fri, 8 Jan 1999 05:01:22 -0700 (MST), Bruce Sass <bsass@ecn.ab.ca> said:
> On 5 Jan 1999, Adam Di Carlo wrote:
>> Also, have you tried the specifically low-memory installation?
> No. A `cat /proc/meminfo` right before reading in DRV1440 reveals
> 1960k of _total_ memory on a 4096k system; am I correct in assuming
> that the OS overhead is 2136k... if so, I'll try at 3M and (if
> possible) at 2.5M... although I'm not sure I would want anyone to
> see a stock DGL kernel running in 2.5M of RAM :)
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.
> <...>
>> You must have at least 4MB of RAM and 20MB of hard disk.
>>
>> >From your message, this should be 4MB RAM, and 25MB disk?
> You need 9M of VM to get past configuring the device drivers and 33M
> of disk space to extract the base archive... it looks like a
> resource poor installation will need over 2M of RAM and at least
> (33M + (9M - RAM) + 2M) of HDD space.
Ah, thanks for the info. Documented it all:
<!-- threshold, below which, we are a low memory system -->
<!ENTITY low-mem-threshold "4MB">
<!-- minimum size of root disk (i.e., just enough for base system) -->
<!ENTITY minimum-fs-size "35MB">
<!-- minimum total memory (RAM + swap is ok) needed, i.e., for kernel -->
<!-- module config -->
<!ENTITY minimum-memory "9MB">
> My system, with 4M RAM and a 40M HDD, just makes it!
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...;)
> There is a possibility that the size of my HDD (40.88M), and the
> uncertainty in my data (a couple, or maybe few, hundred K) have
> conspired against me. The formula should be check independently.
I'll try... no promises. I don't mind being a little incorrect on the
conservative side...
> 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.
Interesting idea -- dunno if we'll get to it for a bit.
> anyways, Armed with the formula I repartitioned the HDD and did ya
> fresh install, actually I did a couple. Everything was more or less
> identical during each dinstall, monitoring revealed 300k and 400k
> for VM and FS overhead respectively (I think I heard it squeek).
> Then I ran into a problem; both installs seemed to hang up at some
> point after the netbase script is executed (I am most certainly
> _not_ blaming netbase for anything).
Excellent job, very thorough!
> The first install proceeded from dinstall to the smoke test without
> interruption, the second had a power down for half an hour before
> the smoke test. When the system hung (I gave it 30 min), CTRL-c had
> no effect (waited 5 min,) but the three finger salute would start a
> reboot in under a minute. It didn't matter if the reboot was
> allowed to proceed, or was interupted with a power down and then
> restarted, the system would come up as expected.
> 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. I only
> mention these hang-ups because I can't really say that I managed to
> use the given formula to boot the system with the minimum predicted
> requirements, without intervening in some way. :(
Well, the stock kernels are rather loaded up. This can cause
(intermittant) freezes with some peripheral/firmware combinations.
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 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.
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? ;)
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-testing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: