* [TUHS] was turmoil, moving to rm -rf / [not found] <mailman.805.1493129956.3779.tuhs@minnie.tuhs.org> @ 2017-04-25 15:17 ` David 0 siblings, 0 replies; 18+ messages in thread From: David @ 2017-04-25 15:17 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1690 bytes --] Many years ago I was at Burroughs and they wanted to do Unix (4.1c) on a new machine. Fine. We all started on the project porting from a Vax. So far so good. Then a new PM came in and said that intel was the future and we needed to use their machines for the host of the port. And an intel rep brought in their little x86 box running some version of Unix (Xenix?, I didn’t go anywhere near the thing). My boss, who was running the Unix port project did the following: Every Friday evening he would log into the intel box as root and run “/bin/rm -rf /“ from the console. Then turn off the console and walk away. Monday morning found the box dead and the intel rep would be called to come and ‘fix’ his box. This went on for about 4 weeks, and finally my boss asked the intel rep what was wrong with his machine. The rep replied that this was ‘normal’ for the hardware/software and we would just have to “get used to it”. The PM removed the intel box a couple of days later. David > On Apr 25, 2017, at 7:19 AM, tuhs-request at minnie.tuhs.org wrote: > > From: Larry McVoy <lm at mcvoy.com> > To: Clem Cole <clemc at ccc.com> > Cc: Larry McVoy <lm at mcvoy.com>, TUHS main list <tuhs at minnie.tuhs.org> > Subject: Re: [TUHS] was turmoil, moving to rm -rf / > Message-ID: <20170425140853.GD24499 at mcvoy.com> > Content-Type: text/plain; charset=us-ascii > > 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 :) ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards? @ 2017-04-24 22:06 Noel Chiappa 2017-04-24 22:18 ` Josh Good 0 siblings, 1 reply; 18+ messages in thread From: Noel Chiappa @ 2017-04-24 22:06 UTC (permalink / raw) > From: Josh Good > Would the command "cd /tmp ; rm -rf .*" be able to kill a V6 ... system? Looking at the vanilla 'rm' source for V6, it cannot/does not delete directories; one has to use the special 'rmdir' command for that. But, somewhat to my surprise, it does support both the '-r' and '-f' flags, which I thought were later. (Although not as 'stacked' flags, so you'd have to say 'rm -r -f'.) So, assuming one did that, _and_ (important caveat!) _performed that command as root_, it probably would empty out the entire directory tree. (I checked, and "cd /tmp ; echo .*" evaluates to ". .." on V6. Noel ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards? 2017-04-24 22:06 [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards? Noel Chiappa @ 2017-04-24 22:18 ` Josh Good 2017-04-24 23:23 ` Kurt H Maier 0 siblings, 1 reply; 18+ messages in thread From: Josh Good @ 2017-04-24 22:18 UTC (permalink / raw) On 2017 Apr 24, 18:06, Noel Chiappa wrote: > > From: Josh Good > > > Would the command "cd /tmp ; rm -rf .*" be able to kill a V6 ... system? > > So, assuming one did that, _and_ (important caveat!) _performed that command > as root_, it probably would empty out the entire directory tree. (I checked, > and "cd /tmp ; echo .*" evaluates to ". .." on V6. Yeah, but does "rm" in V6 has a built-in "brake" to not process "." nor "..", no matter what ("-f")? -- Josh Good ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards? 2017-04-24 22:18 ` Josh Good @ 2017-04-24 23:23 ` Kurt H Maier 2017-04-24 23:59 ` [TUHS] was turmoil, moving to rm -rf / Larry McVoy 0 siblings, 1 reply; 18+ messages in thread From: Kurt H Maier @ 2017-04-24 23:23 UTC (permalink / raw) On Tue, Apr 25, 2017 at 12:18:41AM +0200, Josh Good wrote: > On 2017 Apr 24, 18:06, Noel Chiappa wrote: > > > From: Josh Good > > > > > Would the command "cd /tmp ; rm -rf .*" be able to kill a V6 ... system? > > > > So, assuming one did that, _and_ (important caveat!) _performed that command > > as root_, it probably would empty out the entire directory tree. (I checked, > > and "cd /tmp ; echo .*" evaluates to ". .." on V6. > > Yeah, but does "rm" in V6 has a built-in "brake" to not process "." nor > "..", no matter what ("-f")? > > -- > Josh Good > rm in V6 outsources globbing to /etc/glob, which appears to report no-match if the first character is . https://github.com/dspinellis/unix-history-repo/blob/Research-V6-Snapshot-Development/usr/source/s1/glob.c#L151 khm ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-24 23:23 ` Kurt H Maier @ 2017-04-24 23:59 ` Larry McVoy 2017-04-25 0:44 ` Dan Cross 2017-04-25 14:02 ` Clem Cole 0 siblings, 2 replies; 18+ messages in thread From: Larry McVoy @ 2017-04-24 23:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-24 23:59 ` [TUHS] was turmoil, moving to rm -rf / Larry McVoy @ 2017-04-25 0:44 ` Dan Cross 2017-04-25 14:02 ` Clem Cole 1 sibling, 0 replies; 18+ messages in thread From: Dan Cross @ 2017-04-25 0:44 UTC (permalink / raw) Am I the only one who mentally says, "f*ck recursively" whenever I type, "rm -fr" ? (f*ck being fsck, of course.) On Mon, Apr 24, 2017 at 7:59 PM, Larry McVoy <lm at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170424/e4343c34/attachment.html> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-24 23:59 ` [TUHS] was turmoil, moving to rm -rf / Larry McVoy 2017-04-25 0:44 ` Dan Cross @ 2017-04-25 14:02 ` Clem Cole 2017-04-25 14:08 ` Larry McVoy 2017-04-25 14:19 ` Corey Lindsly 1 sibling, 2 replies; 18+ messages in thread From: Clem Cole @ 2017-04-25 14:02 UTC (permalink / raw) 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170425/1f602f0f/attachment.html> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 14:02 ` Clem Cole @ 2017-04-25 14:08 ` Larry McVoy 2017-04-25 14:12 ` Álvaro Jurado 2017-04-25 14:18 ` Clem Cole 2017-04-25 14:19 ` Corey Lindsly 1 sibling, 2 replies; 18+ messages in thread From: Larry McVoy @ 2017-04-25 14:08 UTC (permalink / raw) 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 at 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 14:08 ` Larry McVoy @ 2017-04-25 14:12 ` Álvaro Jurado 2017-04-25 14:29 ` arnold 2017-04-25 14:18 ` Clem Cole 1 sibling, 1 reply; 18+ messages in thread From: Álvaro Jurado @ 2017-04-25 14:12 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3396 bytes --] I did it during my IBM days years ago. It was an AIX 4.2, I broke almost a half of /usr and /bin /etc... ashamed :-( Álvaro 2017-04-25 16:08 GMT+02:00 Larry McVoy <lm at mcvoy.com>: > 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170425/3ad86a6e/attachment.html> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 14:12 ` Álvaro Jurado @ 2017-04-25 14:29 ` arnold 2017-04-25 14:31 ` Álvaro Jurado 0 siblings, 1 reply; 18+ messages in thread From: arnold @ 2017-04-25 14:29 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3671 bytes --] I too, on a 4.1 BSD or 4.2 BSD vax 780 at Ga Tech. I forget who helped me put things back together. IIRC I had blown away "only" /dev, so it wasn't quite so bad. But yes, it's something you only do once. :-) Arnold Álvaro Jurado <elbingmiss at gmail.com> wrote: > I did it during my IBM days years ago. It was an AIX 4.2, I broke almost a > half of /usr and /bin /etc... ashamed :-( > > Álvaro > > 2017-04-25 16:08 GMT+02:00 Larry McVoy <lm at mcvoy.com>: > > > 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 at 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 > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 14:29 ` arnold @ 2017-04-25 14:31 ` Álvaro Jurado 2017-04-25 16:28 ` Pete Turnbull 0 siblings, 1 reply; 18+ messages in thread From: Álvaro Jurado @ 2017-04-25 14:31 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 4225 bytes --] My mstake was forgetting that "su -" is not "su". So I thought I was on the right dir and... Álvaro 2017-04-25 16:29 GMT+02:00 <arnold at skeeve.com>: > I too, on a 4.1 BSD or 4.2 BSD vax 780 at Ga Tech. I forget who helped > me put things back together. IIRC I had blown away "only" /dev, so it > wasn't quite so bad. > > But yes, it's something you only do once. :-) > > Arnold > > Álvaro Jurado <elbingmiss at gmail.com> wrote: > > > I did it during my IBM days years ago. It was an AIX 4.2, I broke almost > a > > half of /usr and /bin /etc... ashamed :-( > > > > Álvaro > > > > 2017-04-25 16:08 GMT+02:00 Larry McVoy <lm at mcvoy.com>: > > > > > 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 at 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170425/a1517807/attachment.html> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 14:31 ` Álvaro Jurado @ 2017-04-25 16:28 ` Pete Turnbull 2017-04-27 23:44 ` Steve Johnson 0 siblings, 1 reply; 18+ messages in thread From: Pete Turnbull @ 2017-04-25 16:28 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 316 bytes --] On 25/04/2017 15:31, Álvaro Jurado wrote: > My mstake was forgetting that "su -" is not "su". So I thought I was on > the right dir and... Not for quite the same reason, but on all my machines I've taken to creating a home directory for root that isn't / for the last couple of decades. -- Pete Pete Turnbull ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 16:28 ` Pete Turnbull @ 2017-04-27 23:44 ` Steve Johnson 2017-04-27 23:54 ` Ron Natalie ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Steve Johnson @ 2017-04-27 23:44 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 582 bytes --] The worst "nuke the file system" experience I had was on the GE mainframe. Think big room, punched cards, etc. And an operators' console that typed on paper... When you booted the system, the first message that came up said: INIT? If you said 'y', it wiped out the file system. After a very heated users' group meeting, they agreed to change the message to DO YOU WANT TO WIPE OUT THE FILE SYSTEM? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170427/3c726b11/attachment.html> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-27 23:44 ` Steve Johnson @ 2017-04-27 23:54 ` Ron Natalie 2017-04-28 3:04 ` Toby Thain [not found] ` <mailman.198.1493337336.3780.tuhs@minnie.tuhs.org> 2 siblings, 0 replies; 18+ messages in thread From: Ron Natalie @ 2017-04-27 23:54 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 311 bytes --] Exec 8 (the Univac Operating Systm) used to make you type the word “CATASTROPHIC” to proceed past a certain point in reiniting the system. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170427/33b13471/attachment.html> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-27 23:44 ` Steve Johnson 2017-04-27 23:54 ` Ron Natalie @ 2017-04-28 3:04 ` Toby Thain 2017-04-28 5:19 ` arnold [not found] ` <mailman.198.1493337336.3780.tuhs@minnie.tuhs.org> 2 siblings, 1 reply; 18+ messages in thread From: Toby Thain @ 2017-04-28 3:04 UTC (permalink / raw) On 2017-04-27 7:44 PM, Steve Johnson wrote: > The worst "nuke the file system" experience I had was on the GE > mainframe. Think big room, punched cards, etc. And an operators' > console that typed on paper... > > When you booted the system, the first message that came up said: > > INIT? > > If you said 'y', it wiped out the file system. > > After a very heated users' group meeting, they agreed to change the > message to > > DO YOU WANT TO WIPE OUT THE FILE SYSTEM? Good to know UX has always been terrible :-) --T ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-28 3:04 ` Toby Thain @ 2017-04-28 5:19 ` arnold 0 siblings, 0 replies; 18+ messages in thread From: arnold @ 2017-04-28 5:19 UTC (permalink / raw) Toby Thain <toby at telegraphics.com.au> wrote: > On 2017-04-27 7:44 PM, Steve Johnson wrote: > > The worst "nuke the file system" experience I had was on the GE > > mainframe. Think big room, punched cards, etc. And an operators' > > console that typed on paper... > > > > When you booted the system, the first message that came up said: > > > > INIT? > > > > If you said 'y', it wiped out the file system. > > > > After a very heated users' group meeting, they agreed to change the > > message to > > > > DO YOU WANT TO WIPE OUT THE FILE SYSTEM? > > > Good to know UX has always been terrible :-) > > --T Well golly gee whiz, the guy who wrote it knew what it was going to do ... ( :-) Arnold ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <mailman.198.1493337336.3780.tuhs@minnie.tuhs.org>]
* [TUHS] was turmoil, moving to rm -rf / [not found] ` <mailman.198.1493337336.3780.tuhs@minnie.tuhs.org> @ 2017-04-28 14:48 ` John Floren 0 siblings, 0 replies; 18+ messages in thread From: John Floren @ 2017-04-28 14:48 UTC (permalink / raw) On 2017-04-27, Ron Natalie <ron at ronnatalie.com> wrote: > This is a multipart message in MIME format. > > ------=_NextPart_000_0154_01D2BF90.27157840 > Content-Type: text/plain; > charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Exec 8 (the Univac Operating Systm) used to make you type the word = >=E2=80=9CCATASTROPHIC=E2=80=9D to proceed past a certain point in = > reiniting the system. > > > ------=_NextPart_000_0154_01D2BF90.27157840 > Content-Type: text/html; > charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > ><html xmlns:v=3D"urn:schemas-microsoft-com:vml" = > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = > xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = > http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta = > name=3DGenerator content=3D"Microsoft Word 14 (filtered = > medium)"><style><!-- > /* Font Definitions */ > @font-face > {font-family:Helvetica; > panose-1:2 11 6 4 2 2 2 2 2 4;} > @font-face > {font-family:Helvetica; > panose-1:2 11 6 4 2 2 2 2 2 4;} > @font-face > {font-family:Calibri; > panose-1:2 15 5 2 2 2 4 3 2 4;} > /* Style Definitions */ > p.MsoNormal, li.MsoNormal, div.MsoNormal > {margin:0in; > margin-bottom:.0001pt; > font-size:12.0pt; > font-family:"Times New Roman","serif";} > a:link, span.MsoHyperlink > {mso-style-priority:99; > color:blue; > text-decoration:underline;} > a:visited, span.MsoHyperlinkFollowed > {mso-style-priority:99; > color:purple; > text-decoration:underline;} > span.EmailStyle17 > {mso-style-type:personal-reply; > font-family:"Calibri","sans-serif"; > color:#1F497D;} > .MsoChpDefault > {mso-style-type:export-only; > font-size:10.0pt;} > @page WordSection1 > {size:8.5in 11.0in; > margin:1.0in 1.0in 1.0in 1.0in;} > div.WordSection1 > {page:WordSection1;} > --></style><!--[if gte mso 9]><xml> ><o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> ></xml><![endif]--><!--[if gte mso 9]><xml> ><o:shapelayout v:ext=3D"edit"> ><o:idmap v:ext=3D"edit" data=3D"1" /> ></o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue = > vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span = > style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= > D'>Exec 8 (the Univac Operating Systm) used to make you type the word = >=E2=80=9CCATASTROPHIC=E2=80=9D to proceed past a certain point in = > reiniting the system.</span><span = > style=3D'font-size:9.0pt;font-family:"Helvetica","sans-serif"'><o:p></o:p= >></span></p></div></body></html> > ------=_NextPart_000_0154_01D2BF90.27157840-- > Ron, can you and others who are posting via email please take care to send text-only emails? It's utterly unreadable to anyone using a newsreader or plain old 'mail'. http://i.imgur.com/EJS5Okd.png sorry for going off-topic... john ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 14:08 ` Larry McVoy 2017-04-25 14:12 ` Álvaro Jurado @ 2017-04-25 14:18 ` Clem Cole 2017-04-25 15:28 ` Dan Cross 1 sibling, 1 reply; 18+ messages in thread From: Clem Cole @ 2017-04-25 14:18 UTC (permalink / raw) Problem was /etc has been burned too... so the mknod command is off the table. On Tue, Apr 25, 2017 at 10:08 AM, Larry McVoy <lm at 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170425/04defef3/attachment-0001.html> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 14:18 ` Clem Cole @ 2017-04-25 15:28 ` Dan Cross 2017-04-25 17:56 ` Bakul Shah 0 siblings, 1 reply; 18+ messages in thread From: Dan Cross @ 2017-04-25 15:28 UTC (permalink / raw) On Tue, Apr 25, 2017 at 10:18 AM, Clem Cole <clemc at 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 at 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 at 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170425/f10332fe/attachment-0001.html> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 15:28 ` Dan Cross @ 2017-04-25 17:56 ` Bakul Shah 0 siblings, 0 replies; 18+ messages in thread From: Bakul Shah @ 2017-04-25 17:56 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 7302 bytes --] I once had to rebuild the root directory using ROM based disk IO and memory peek and poke commands! At this late date I don’t recall many details but at least the root block was trashed during some last minute testing. Unlikely it was “rm -rf / something” as that would’ve done far more damage. The situation was this: 1. We had *one* working hardware system[1]. 2. At that time we only had working floppy controller and driver[2]. 3. Our devel system was a VAX running 4.1BSD. no support for the floppy drive so everything had to be downloaded over a 9600 serial link. 4. The backup floppy either didn’t exist or wasn’t readable. 5. We had custom stuff that was done for a show and not backed up anywhere. Luckily, due to earlier debugging sessions I knew what the file system layout was — this was on a version 7 system, with 16 byte dir entries, 2 bytes inode #, followed by and 14 byte name. IIRC inode 0 was not used, inode 1 was used as a temp during fsck based recovery and inode 2 was for the real root. So I read in the root inode, found the disk address of its data block, read it in, using fixed up “.” and “..” and “/bin” entries — usually inode #3 was bin, wrote it back to the floppy and rebooted. I think the unix image was in /bin. On reboot fsck worked and reconnected all the lost directories, which were easy to figure out and rename. The back story is that this happened on a Saturday just before the Fall Comdex 1981, where we were going to show our system for the first time and we had to take a working system to Las Vegas by Sunday[3]. We were able to fly out on time and the Comdex show was a success, with thousands of leads generated. In terms of lessons, I don’t know what we learned. I guess it pays to be intimately familiar with the system as we were in an extreme bootstrap situation with very little working reliably. Seems often startups end up doing acrobatics without a net! — bakul [1] Two actually, but the second was a wire wrapped prototype. This was at an early Unix workstation startup; our main app was “word processing”. [2] Later we hooked up a Western Digital ST506 controller via parallel port and I was very happy when my disk driver could do 25 KB/s! No DMA so had to do programmed IO. [3] Rob Warnock (whom some of you may know from his SGI days) was our very hands-on CTO, and he was/is great at debugging/problem solving. I don’t know why they waited for me rather than call Rob. a) I was a junior engineer as that my first job with C & Unix (6 months at that time) and b) I had already worked about 80+ hours that week and gone home to sleep at 9AM on Saturday. May be Rob was smart enough to not answer his phone! > On Apr 25, 2017, at 8:28 AM, Dan Cross <crossd at gmail.com> wrote: > > On Tue, Apr 25, 2017 at 10:18 AM, Clem Cole <clemc at ccc.com <mailto:clemc at 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 at mcvoy.com <mailto:lm at 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 at mcvoy.com <mailto:lm at 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 <http://mcvoy.com/lm/masscomp-restore.pdf> > > > > > > Complete with all the typos. > > > > > > --lm > > > > > -- > --- > Larry McVoy lm at mcvoy.com <http://mcvoy.com/> http://www.mcvoy.com/lm <http://www.mcvoy.com/lm> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170425/f5103d5c/attachment.html> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [TUHS] was turmoil, moving to rm -rf / 2017-04-25 14:02 ` Clem Cole 2017-04-25 14:08 ` Larry McVoy @ 2017-04-25 14:19 ` Corey Lindsly 1 sibling, 0 replies; 18+ messages in thread From: Corey Lindsly @ 2017-04-25 14:19 UTC (permalink / raw) > 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. It was in a situation similar to this that I learned the blessed usefulness of echo * as a crude substitute for /bin/ls --corey ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-04-28 14:48 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <mailman.805.1493129956.3779.tuhs@minnie.tuhs.org> 2017-04-25 15:17 ` [TUHS] was turmoil, moving to rm -rf / David 2017-04-24 22:06 [TUHS] There is turmoil in Linux-land - When did rm first avoid going upwards? Noel Chiappa 2017-04-24 22:18 ` Josh Good 2017-04-24 23:23 ` Kurt H Maier 2017-04-24 23:59 ` [TUHS] was turmoil, moving to rm -rf / Larry McVoy 2017-04-25 0:44 ` Dan Cross 2017-04-25 14:02 ` Clem Cole 2017-04-25 14:08 ` Larry McVoy 2017-04-25 14:12 ` Álvaro Jurado 2017-04-25 14:29 ` arnold 2017-04-25 14:31 ` Álvaro Jurado 2017-04-25 16:28 ` Pete Turnbull 2017-04-27 23:44 ` Steve Johnson 2017-04-27 23:54 ` Ron Natalie 2017-04-28 3:04 ` Toby Thain 2017-04-28 5:19 ` arnold [not found] ` <mailman.198.1493337336.3780.tuhs@minnie.tuhs.org> 2017-04-28 14:48 ` John Floren 2017-04-25 14:18 ` Clem Cole 2017-04-25 15:28 ` Dan Cross 2017-04-25 17:56 ` Bakul Shah 2017-04-25 14:19 ` Corey Lindsly
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).