Welcome back, chilluns. I hope you had a nice rest, got something to eat, went potty. Letapos;s pick the story again. Now, where was I?
Ah, yes.
It was spring, when a young manapos;s fancy lightly turns to thoughts of ...
Hacking the new toy.
Hey, we were geeks. Deal.
Anyway, it was spring, the donated PDP 11/45 was humming along with only the occasional hiccup, and we finally had a way to read the data on the stack of tapes gathering dust in the computer room. Casey I, as two of the top students in the department, got the plum job of installing the new OS and configuring the system. We had stacks of printouts from all the current config files, with lots of notes of changes. We had the tapes, the drive had been tested, we were ready to go.
We waited until Friday afternoon, figuring it would take us most of the weekend to install, recompile the kernel, and check all our settings. But the system would be back up on Monday, in time for everyone to get their midterm projects turned in.
We issued a message to all terminals giving them a ten-minute grace period before shutdown, There was the usual grumbling and begging for more time, but we were adamant. More or less on time, we shut down multiuser mode and switched over to single user, then settled down in front of the system console.
The first thing we did, after mounting the tape, was read the header file. Theyapos;d conveniently stuck a readme at the beginning, telling us the OS version number, some late-breaking errata, and other install notes.
We noticed that the install needed 120+ megabytes of free disk space. So we called up the partition table and started looking. We saw several small - 1-10MB - partitions with variations on "temp" as the partition name; and the usual suspects on a UNIX system - /usr, /bin, /var, /, etc. And we saw one partition that looked like it was unused, with about 130MB free space. Weapos;d found our spot
We worked out the commands on paper, typed them in, checked each other, then hit return. MFS (make file system) started creating the basic structures we needed in order to dump the tape files off and get the install going.
The job ran for about 30 seconds, then suddenly the console screen flashed the message:
*** FATAL ERROR ***
Not a problem, we thought. There might have been a bad sector on that pack. The system will mark it and go on. Fatal errors just mean the process is having trouble. The kernel is still working, handling the error message.
Then another message
*** FATAL ERROR ***
and another
*** FATAL ERROR ***
Then they just started scrolling rapidly down the screen
*** FATAL ERROR ***
*** FATAL ERROR ***
*** FATAL ERROR ***
*** FATAL ERROR ***
*** FATAL ERROR ***
...
We started to get concerned. This many fatal errors might mean the whole pack was bad, or the drive was going, or some other hardware fault. Then the errors messages stopped, the screen cleared, and we breathed easier.
Until the next message:
*** PANIC ***
followed by a core dump. The console stopped responding.
Oh ... Shit.
We ran and grabbed the professor who was our UNIX guru and showed him the messages. He showed us how to boot into the PDPapos;s BIOS mode, used for initial setup and debugging. With his help, over the next few hours we diagnosed the problem.
That huge empty partition we found? That was somehow linked to the drive as a whole. All the other, smaller partitions were part of it. We thought we were making a file system in an empty area of the disk, instead we were making it right on top of the running system.
We overwrote the inodes.
For non-UNIX people - the file system used "inodes" to keep track of the disk blocks used by a file. Each inode was a list of pointers to those blocks, and the first part of the disk was set aside to store them. Weapos;d essentially corrupted the pointers - the file data was still there, it just couldnapos;t be found anymore.
Those fatal errors were us writing over system files. The panic was when we wrote over the /var partition and the kernel was suddenly loading crap to run.
But hey, no problem, the prof said. Weapos;ll just restore from backup and start over, right?
Um, no, we hadnapos;t made a backup.
Okay, plan B.
We grabbed a spare disk pack, plopped it in, double-checked that it truly was scratch, and started the install again, building up from the most basic I/O commands. Finally, we had enough to recompile the kernel, giving us the custom BSD system weapos;d been working toward. We started that, then went over to Caseyapos;s apartment to monitor it via modem. We only left to swap tapes and do things we had to do directly on the console. The pizza boxes built up, and the poor coffeepot almost burned out.
Come Monday morning, we had a working system - sorta. We had a valid BSD kernel, most of the support apps and tools, and it looked like the terminals could log in.
But there was nothing to log into. All the user accounts were on the disk pack we had trashed.
And it was midterms week.
There were immediate calls for Casey I to be drawn and quartered, keelhauled, tar and feathered, etc. We escaped defenestration only because the computer science building was a single story. People were _not_ happy.
Three things saved our hides.
1. The BIG login splash screen with the note about this being a student-run system, and students used it at their own risk and were responsible for their own backups;
2. The fact that the professors accepted "the computer ate my senior project and I had to retype it from scratch" as a valid reason for being late; and
3. The fact that the mob couldnapos;t find us.
We barricaded ourselves in Caseyapos;s apartment again, only making late-night forays for food, and spent the next week, practically 24/7, hand-building directories and files onto the new pack from a post-crash raw dump of the old pack.
The upshot was that half the student accounts went bye-bye completely. The rest, including the faculty and department accounts, suffered damage. I lost about 1/4 of my stuff, Casey 1/3. There was a lot of muttering in the lab for the rest of the semester, and we got cricks in our necks from looking over our shoulders all the time.
Unca Rain finishes his story and looks fiercely at the chilluns. "And what have we learned today?" he asks.
"Always make backups?" ventures one brave soul.
"No," says Unca Rain. "Always have a good escape plan, a strong hidey-hole, and the numbers of at least three places that deliver."
definition intensity, elasticity loss skin, elasticity log, elasticity lecture notes, elasticity lecture note revenue total.
