Re: urgent warning---don't use 1.3.4[41]

Chel van Gennip, (chel@vangennip.nl)
Thu, 16 Nov 1995 21:03:56 +0100 (MEZ)


On Wed, 15 Nov 1995 07:45:41 David Mosberger-Tang wrote:

>>>>>> On Wed, 15 Nov 95 10:31:35 MET, "Ka'plaagh 15-Nov-1995 0924 +0000" <rusling@rdgeng.enet.dec.com> said:
>
> Dave.R> All, I can verify that, my disk got trashed last night the
> Dave.R> moment I touched the floppy on my AlphaPC64. By the way,
> Dave.R> this is *not* true for the Universal Desktop Box (aka
> Dave.R> Multia) and probably not for Noname...
>
>Actually, the bug is not Cabriolet specific. But it may be that for
>some reason it doesn't show (frequently) on the Multia and Noname. I
>would stay away from those kernels anyway. My fix seems to work, but
>I haven't tested it enough yet to make sure...
>
> --david

I don't know if this problem relates to the floppy bug mentioned, but
when I tried to install the new Blade distribution on a machine with
limitted memory (8MB), I had a lot of floppy problems. I tried some kernels
1.3.27 as in the nov 4th blade, 1.3.31, as in the nov 14th blade and the
kernel I used before 1.3.35. I was installing from scratch: boot from
floppy with ramdisk. After such a problem the mounted filesystem was
a complete mess.

After getting back to 32MB memory the installation was smooth. I installed
the whole nov 14th blade without problems (I did however use the 1.3.35
kernel in order to use the network during installation).
The new X set in this distribution is quite complete and improved!
Now my S3 trio64 card works allright. :-)

During installation however a lot of disk space is needed. The installation
first stores all the 28 images, and afterwards extracts. Because I installed
from disk files instead of floppies, I needed about 80MB free disk space extra.

I think the Linux-Alpha on our NLUUG CD (snapshot nov 9th, release nov 23rd)
allready is obsolete :-(

The problems I met were:
- the B set only uses 9 out of 11 floppies.
- installation with 8MB has severe flopy problems
- autoboot in MILO does not transfer BOOT_STRING to the kernel
- MILO setenv BOOT_STRING root=/dev/fd0 ramdisk=1440 results in
BOOT_STRING=root=/dev/fd0
- shutdown -r -q now does not result in reboot.
- the definition of console is wrong, no delete is available in vi.

Chel
-------------------------------------------------------------------------
Chel van Gennip | Spechtstraat 15 | 2623 GP Delft | The Netherlands
Tel: +31 15 567783 | Fax: +31 15 610985 | E-Mail: chel@vangennip.nl
-------------------------------------------------------------------------