25 Apr
2017
25 Apr
'17
5:28 p.m.
On Tue, Apr 25, 2017 at 10:18 AM, Clem Cole <clemc(a)ccc.com> wrote:
Problem was /etc has been burned too... so the mknod
command is off the
table.
Either boot into standalone media like some kind of miniroot (that
hopefully has a copy of mknod) or look for some kind of shell builtin?
E.g., if the shell provides some mechanism to make a raw system call, you
can do it. E.g., an escape hatch to syscall() or indir(). If a copy of
`mkdir` survived, then on older systems where directory creation was done
by calling mknod(), one might be able to modify `mkdir` enough to create
device file for a tape device to launch a restore off of. I thought some
systems came with a syscall(1) utility, but it does't seem to be current
anymore and I can't find any references to it so perhaps I'm misremembering.
I once messed up a NeXT machine by "mv"'ing the system shared libraries to
an unexpected path. Oops. I had to boot off the CD to fix it, but that's
child's play compared to some of the esoterica you guys are talking about.
- Dan C.
On Tue, Apr 25, 2017 at 10:08 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
Whoever was the genuis that put mknod in /etc has
my gratitude.
We had other working Masscomp boxen but after I screwed up that
badly nobody would let me near them until I fixed mine :)
And you have to share who it was, I admitted I did it, I think
it's just a thing many people do..... Once :)
On Tue, Apr 25, 2017 at 10:02:26AM -0400, Clem Cole wrote:
Larry,
I had to laugh when I read that because what you don't know is it was
part
of my old Unix wizards test which was left over
from a the day when one
of
our hackers (whom I think you would later get to
know so I'll not name
him)
accidentally typed: rm -rf . as root from his /
on his workstation.
Because /bin/rmdir had been lost, he started getting errors when rmdir
was
forked. So he hit ^C, but he had already lost:
/bin, /dev, /etc,
/lib,
most of /usr. He was a developer in the
networking group so he was
working
on network code which we could not trust would
not panic (in fact we
disconnected the node from the ethernet immediately just in case).
But we
did have pretty much everything in
/usr/bin/[s-z]* -- that is we think
it
was deleting files in /usr/bin when he stopped
it.
We obviously had another working Masscomp box just like it. And of
course
the shell was working on the machine that was in
trouble. We recovered
the system as it was. Hint the key item is you have to start by
putting
/dev back together and the solution to that
problem has had been
discussed
on this list.
Clem
On Mon, Apr 24, 2017 at 7:59 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
> This is gonna seem like I'm tooting my own horn, and I am a little,
but
> here's an rm -rf / story.
>
> Clem will be amused because I was a junior or senior in college and a
sys
> admin for a Masscomp with a 40MB disk with
20 users. And I did some
> version
> of rm -rf /, realized part way through that I screwed up, and killed
it.
> But /bin and /dev were gone so putting
things back together was hard.
>
> But I did it and wrote up this little note for the people who came
after
> me, if I was stupid enough to do this
someone else would, was my
thinking.
> You can get a sense of how scared I was in
it if you read it
carefully.
> It was a very long night.
>
> For an undergrad, I think it's not bad? Maybe? I dunno, I look at
how
> much I needed to have understood to get the
system back up, that's a
lot
> of reading, playing, experience. Love that
Geophysics department,
they
> pushed me.
>
> And it was during my (brief) foray into the *roff -me macros (I went
> -ms and never looked back). Roff source on request to anyone who is
> twisted enough to want it.
>
> http://mcvoy.com/lm/masscomp-restore.pdf
>
> Complete with all the typos.
>
> --lm
>
--
---
Larry McVoy lm at mcvoy.com
http://www.mcvoy.com/lm