Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!Teknowledge.COM!polya!ali
From: ali@polya.Stanford.EDU (Ali T. Ozer)
Newsgroups: comp.sys.next
Subject: Re: kernel corruption on 330Mb hd???
Message-ID: <12837@polya.Stanford.EDU>
Date: 16 Nov 89 15:58:20 GMT
References: <17504@kuhub.cc.ukans.edu> <5604@umd5.umd.edu> <12811@polya.Stanford.EDU>
Reply-To: ali@Polya.Stanford.EDU (Ali T. Ozer)
Organization: .
Lines: 34

In article <12811@polya.Stanford.EDU> Ali T. Ozer writes:
>In article <5604@umd5.umd.edu> feldman@umd5.umd.edu (Mark Feldman) writes:
>>I've had three systems corrupted the same way.  It's a bug.  Many others
>>have suffered the same bug.  As of yet, no one knows what is causing the
>>boot file to become corrupted, let alone how to prevent it.
>Yes, this is a bug.  NeXT is working on it.

The bug has been discovered and there is a workaround, in fact, an incredibly
simple one.  Launch a Shell, become root, and remove the executable bit on 
your kernel:

	su
	[type password]
	chmod a-x /sdmach

The problem occurs if you try to launch an executable in the Mach preload
format; depending on how the pages our laid out in the file, a part of the
file might become corrupted if paging occurs after the file is "launched."

Mach preload executables are meant to be bootable images and are not meant
to be executed by the demand-paged system; thus your system will not lose
any functionality when you remove the executable bit.  You will just be
assuring that the kernel is not launched inadvertently (either from the
Shell or with a double-click), which is probably what caused the
problem in all cases.  

There are only two preload format files in the system, the kernel and the boot 
file.  The boot file has been shipped without the executable bit so it's fine.

Thanks to Alan Marcum and Avie for the explanation and workaround.

Ali