Return to BSD News archive
Newsgroups: comp.os.386bsd.questions
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!pacbell.com!unet!blunt!dsilvia
From: dsilvia@blunt.net.com ()
Subject: Re: PC keeps rebooting after install
Message-ID: <1993Mar3.011330.10035@unet.net.com>
Sender: news@unet.net.com
Nntp-Posting-Host: blunt
Organization: Network Equipment Technologies
References: <1n0nmqINNmro@crcnis1.unl.edu>
Date: Wed, 3 Mar 1993 01:13:30 GMT
Lines: 74
In article <1n0nmqINNmro@crcnis1.unl.edu> kent@unl.edu (kent eitzmann ) writes:
>
>Hello,
>
>I am having problems getting tiny 386bsd to boot off my hard disk after
>'install'. What happens is the pc keeps rebooting upon quickly flashing the
>following message. 'The operating system is saving a copy of RAM memory to
>device 1, offset 0 (hit a key to abort) [amount left to save RAM] device
>bad, system rebooting'. I have a 386dx/40 w/126MB IDE drive. This problem
>only happens when I partion the drive between DOS 5.0 and 386bsd, when I run
>'install' and tell it to use the whole drive everything is fine.
>
>Thanks in advance for any help you can give me.
>
I had the same problem and I tried several ways to 'outwit' the coexistence
dilemma.
I would get the dist.fs loaded to hard disk, be extracting bin01, get
'kmem_malloc' error and then, of course, not even being faster than a
speeding bullet, much less faster than a 486/50, the boot block was affected
before I could do anything about it. (The rantings that went on were enough
to chase my wife and children outside: "Mommy, what's the matter with Daddy?!",
"Never mind! Just don't *EVER* repeat what you heard him say!").
I tried putting the DOS partition at the end of the drive, the installation
seemed to think DOS took up the whole disk.
Finally, just short of apoplexy, I managed to build a kernel with the following
modification to machdep.c:
diff machdep.c.mine machdep.c.src01
508d507
< register int resp;
514,522d512
< do
< {
< printf("\nSave a copy of RAM memory to device %x offset %d? [y/n] ",
< dumpdev,dumplo);
< } while((resp=getchar()) != 'y' && resp != 'n');
< if(resp == 'n')
< {
< return;
< }
This allowed me to at least not dump to device 1 offset 0 (boot block?).
However, I still could not boot. Then I booted to my DrDOS disk and ran fdisk
and I serendipitously noticed option 4 'Restore DOS boot block' (or something
to that effect), selected it and when it came back 'Restore original boot block'
I selected it again, gave it the ol' 3 finger salute, opened drive A: and,
VOILA!, 386bsd booted!!!
It would appear that the kmem panic and subsequent dump overwrote the boot
block previously (as then, even DrDOS didn't recognize the hard drive had
been partitioned). Now, with the option to not dump, DrDOS was still able
to recognize the partitioned disk (however, it doesn't seem to realize that
his drive 'D:' is occupied by another system -- but that's okay, I do!).
It's still not clear _what_ is happening to the boot block that keeps 386bsd
from booting properly NOR why DrDOS is able to cure it!
Anyway, once I got all the sources, etc. unloaded and my swap set at 64Meg
kmem seems to be happy and my system is stable (except, of course, when I'm
hacking around on it !;'} ).
All in all, it's been a real adventure in problem solving!
PROPOSITION: Does it work just fine when DOS does not share the disk because
device 1 offset 0 is the swap partition? Seems like it. If so
isn't this a dangerous assumption - shouldn't it check, possibly
at startup for where exactly _IS_ swap?
Dave S.