schwager@uxg.cso.uiuc.edu (04/26/88)
Here's a weird one:
I was rearranging my master Aztec C disk, the one I boot for doing my C
work. I had replaced all my AmigaDos commands with Arp commands, and I
added rez also. Cool stuff, by the way, folks. Rez is fantastic, as is
the arp stuff. Anyways, I had everything like I wanted so I finished
the startup-sequence file on my disk and was one happy camper... except
it took a looooonnngg time to boot and the disk gronked a lot. So I did
a copy dfX: to dfX: to see if that helped. Well, when I rebooted on the
newly copied disk it certainly did halve my bootup time (or so it
seemed, anyway, it was a lot faster). But, (and here's the weird part)
I got a guru meditation error!
Thinking that rez might be the problem, I rebooted the machine on a
(relatively) raw workbench disk... I say relatively because I'd added
vt and vc to it previously and took the endcli out of the
startup-sequence, but those were the only changes. Now I could go in
and try to edit the startup-sequence file on the disk that guru'ed, but
whenever I tried to write the file out, another guru! This happened if
I used ed or the microemacs from the Extras disk. It happened even if I
booted cold from the Workbench disk (since rez is a beta version, I
kinda suspected it of messing around with my memory). Nothing worked-
as soon as I tried to write the startup-sequence file out, guru. So I
finally ended up copying my Aztec master disk to a newly formatted disk using
AmigaDos' version of copy. Reboot off the newly copied master... no
problem. I'll include a copy of my startup-sequence that caused the
problem (I'm using the same one now, error free). The guru would happen
at the very end, since my mclk did indeed fire up. I never got a cli
prompt:
-Mike Schwager
-- {ihnp4,convex,pur-ee}!uiucdcs!schwager schwager%uiuc@csnet-relay.arpa
University of Illinois, Dept. of Computer Science
*********************Begin startup-sequence file************
mount vd0:
Dir vd0:
AddBuffers df0: 20
AddBuffers df1: 20
if NOT EXISTS vd0:common
df0:common/mkdir vd0:common
df0:common/mkdir vd0:include
df0:common/copy df0:lib/c.lib vd0:
endif
df0:common/cd df0:common
rez ls more list mkdir path copy grep delete arun cd set type info
df0:common/path df0:common add
echo "Mike's Aztec C 3.4a Work Disk"
Stack 8000
set INCLUDE=vd0:include!SYS1:include!SYS2:asm
CLIB=vd0:!SYS1:lib!SYS2:lib!
set FUNCLIST=SYS2:lint/manx.c DBINIT=s:.dbinit
set CCTEMP=ram:
path ram: add
path df1: add
path df0:bin add
setclock opt load
;
;cd df0:bin
;rez cc as
;
arun GOMF1.0
arun df0:c/mclk
date > SYS1:s/nowdoug@eris (Doug Merritt) (04/27/88)
In article <44000001@uxg.cso.uiuc.edu> schwager@uxg.cso.uiuc.edu writes: >I was rearranging my master Aztec C disk, the one I boot for doing my C >work. [...] I've been wondering for a LONG time now...why do people talk about booting so much? Schwager makes it clear later that he has vd0:, and that he's a CLI-er, which increases my puzzlement. I dislike booting, so I do it as little as possible (hey, what's to LIKE about booting?) (BTW I ask because it seems that so many people have a zillion boot disks that they reboot all the time; I'm not singling out Schwager). Aside from playing games which *require* booting, I average about two months between boots for normal use. Versus zillions of times when debugging programs that scribble on memory, but that's another story. And...when I *do* boot, I *ALWAYS* use the same boot disk. Which is always write protected. So then I have to wonder how people catch viruses. Doing "execute some-setup-script" full of assigns always seems to get me the environment I want instead of having to prepare endless numbers of boot disks. So tell me, what am I missing? What is the attraction of rebooting all the time from different diskettes? Ok, with no restartable ram disk, you may as well switch floppies for a new purpose (I guess). But with one, why? Have I lost perspective from growing up around Unix systems that one desperately wants to stay up forever? I must be missing *something*. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
mp1u+@andrew.cmu.edu (Michael Portuesi) (04/28/88)
Doug Merrit poses the following question: > I've been wondering for a LONG time now...why do people talk about > booting so much? Schwager makes it clear later that he has vd0:, > and that he's a CLI-er, which increases my puzzlement. I dislike > booting, so I do it as little as possible (hey, what's to LIKE about > booting?) Perhaps because some of use use floppy-only systems, and we can't fit all of the software we normally use on one Workbench disk. My Workbench disk is about 99% full, containing programs I use all the time like Facc, VT100, and MG. I also have an Aztec C disk which contains the compiler plus Make and MG for an editor. There is no way I can cram all of that on one disk. So when I do C hacking I boot from my C disk, and for everyday tasks I use my Workbench disk. It's not entirely convenient but then again, I don't have much of a choice. --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "words like conviction can turn into a sentence"
schwager@uxg.cso.uiuc.edu (04/29/88)
Not to get too defensive, but... > /* Written 3:32 am Apr 27, 1988 by doug@eris in uxg.cso.uiuc.edu:comp.sys.amiga.tech */ > > I've been wondering for a LONG time now...why do people talk about > booting so much? Schwager makes it clear later that he has vd0:, > and that he's a CLI-er, which increases my puzzlement. I dislike > booting, so I do it as little as possible (hey, what's to LIKE about > booting?) > Me too! But, I think you answer your own question: > Aside from playing games which *require* booting, I average about > two months between boots for normal use. Versus zillions of times when > debugging programs that scribble on memory, but that's another story. > I have three disks that I use to boot with (aside from games): my generic Workbench for when something wacky happens (like the guru I had with my Manx disk), so I can get back to the basics and know everything works and I'm not in the Twilight Zone, my Manx disk for C programming, and another disk for doing text/desktop publishing/dialup work. Since I have text editors and stuff on the text disk, cc and as et. al. on the Manx disk, I know I'm dealing with a known setup when I boot from whatever disk I boot from. Also, I can pop in the disks that I know I'll need for whatever application and do as little swapping as possible. If I had one boot disk only, I'd have to put additional commands and gizmos on another disk (I have just enough room on my Manx disk for everything; I have Emacs on a seperate disk- no room for a text editor). Having assigns on other disks and commands scattered around bugs me more than rebooting :-). I don't boot that often, under normal conditions. > > Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) > /* End of text from uxg.cso.uiuc.edu:comp.sys.amiga.tech */ -Mike Schwager -- {ihnp4,convex,pur-ee}!uiucdcs!schwager schwager%uiuc@csnet-relay.arpa University of Illinois, Dept. of Computer Science
doug@eris (Doug Merritt) (04/30/88)
In article <44000003@uxg.cso.uiuc.edu> schwager@uxg.cso.uiuc.edu writes: > Having assigns on other disks and commands scattered around >bugs me more than rebooting :-). I don't boot that often, under normal >conditions. More than any of the other comments, this answers my question. You see, I prefer doing "execute some-file-full-of-assigns-to-another-disk" instead of rebooting. So I swap in my customized Manx disk and do "execute df1:rc" and I'm all set to do compiles. I guess there isn't a lot of difference between this and rebooting, except that I find that rebooting takes longer. Probably depends on one's startup-sequence, though. Mine switches to vd0: early on. Doug Merritt doug@mica.berkeley.edu (ucbvax!mica!doug) or doug@eris.berkeley.edu (ucbvax!eris!doug) or ucbvax!unisoft!certes!doug or sun.com!cup.portal.com!doug-merritt
jesup@pawl18.pawl.rpi.edu (Randell E. Jesup) (05/03/88)
In article <44000001@uxg.cso.uiuc.edu> schwager@uxg.cso.uiuc.edu writes: >So I did >a copy dfX: to dfX: to see if that helped. Well, when I rebooted on the >newly copied disk it certainly did halve my bootup time (or so it >seemed, anyway, it was a lot faster). But, (and here's the weird part) >I got a guru meditation error! >Now I could go in >and try to edit the startup-sequence file on the disk that guru'ed, but >whenever I tried to write the file out, another guru! This is almost 100% certainly a bad disk/bad copy. My brother had his WP disk give guru's and r/w errors during boot. It turned out to be the destination disk a a few bad tracks, and Diskcopy doesn't do a readback after write to verify. I'd advise formatting disks before copying to them. (He had 4 bad out of 10) // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)