From: Alfie Costa (agcosta@gis.net)
Date: Thu May 18 2000 - 08:48:00 CEST
On 16 May 2000, at 8:51, Michele Andreoli <mulinux@sunsite.auc.dk> quote and
wrote:
> On Mon, May 15, 2000 at 08:59:35PM +0200, Johannes Krausmüller nicely wrote:
> > After creating my mulinux6... floppy I tried to boot from it. But the
> > following message didn't allow me to do so:
> >
> > We need of swap. Do you wish:
> >
> > [1] to continue
> > [2] to inspect the system, opening a shell
> > [3] abort the installation
> >
> >
> > I see no possibility to create a swap-file in the way you wrote. So my
> > question. What shall I do?
> >
>
> The system can't run the script which create swap. If you have release
> old the 9r1, try to upgrade.
Last weekend I acquired a 386 laptop, 4 megs, color even, and tried to install
mu v9.1b and got exactly the same trouble as quoted from Johannes Krausmüller
above. mu sort of hung then and there, though it didn't really hang like PC
programs do, as the numlock key still turned on/off the keyboard LEDs -- a good
test for a completely crashed program. I looked in the mu root/boot disk
archive on my HD, and found the script that gives that 'we need swap' prompt,
and was all set to start tweaking it, but couldn't figure out how to get at the
same script already on the floppy. I mounted the floppy, but must have mounted
the wrong part of the disk, I couldn't find the script file anywhere; obviously
it must be on the floppy, and there must be some command that will get at it.
Well I wanted to install mu anyway, so I ran mu's root/boot on a machine with
lots of memory, but installed a 16 meg swap file and nothing else, not even
'usr'. Then I cloned (umsdos) that very minimal system to this larger
machine's HD. I made an .ARJ archive of the resulting /linux HD directory on a
single dos floppy, (it fit!), and unarchived it on the 4 meg 386 laptop. And
so the laptop booted mu successfully, if a little slowly.
I commenced installing the 'usr' partition on the laptop using the floppy.
That 'usr' install took too long, (the 386 was madly thrashing that swap space,
with no output to show for it), so I stopped it, then decided to try again and
just leave it alone to thrash away. Several hours later 'usr' was installed.
I looked at the setup code to see why it took so long.
(One possible hardware problem was that it's unknown if Linux can see all 4
megs on this 386 or not. 'free' seems to only report 2.9 megs or so -- maybe
the Phoenix BIOS is telling lies to the kernel or something. It's a NEC
Ultralite, if it matters.)
The bottleneck for small systems turns out to be 'bzip2', which gets its
superior compression from using about 3 megs or so of runtime memory. A good
program, but not designed for small memories. Now the bzip2 man page says that
the switch '-1' will make bzip2 use much less runtime memory, but the archives
will be bigger. Strangely enough, how the archive is *made* determines how
much memory the *decompression* program needs. Sort of a run-time/compile-time
memory management issue.
So, starting from a P200 with lots of RAM, I rearchived the EXT and VNC addons,
with the '-1' switch. These were about 30K bigger than the originals, but they
still fit on the floppy. Made new floppies with these new .bz2 archives, and
then installed them on the 386 laptop. Sure enough, it worked -- not as fast
as PKZIP or ARJ, but only minutes to uncompress, and not several hours.
Mu runs on the 386 well enough, but still thrashes a bit too much, but it's not
that bad. (It's still possible there's some problem with it not seeing all 4
megs of RAM or not.) Also it may be faster on an ext2 partition rather than in
umsdos.
Which leads to a general question. New archivers are being written every so
often, so I wonder if bzip2 is the still best archiver for something like mu
anymore. An improved archiver should be as small a program as bzip2, produce
equally good compression or better, use less memory, and work no slower. If
there is no such program with all these good points, one trade-off that might
be worth it would be an archiver that takes more CPU cycles to compress small,
but decompresses quickly. In this way the main archives could be made on a
newer machine, yet easily decompressed on an old one. The question: what
GPL'd archivers compare well to bzip2?
Perhaps bzip2 will turn out to be the best one after all. I shall try to look
on a few archive sites to find out what's new out there.
---------------------------------------------------------------------
To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: mulinux-help@sunsite.auc.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:14 CET