From owner-freebsd-questions@freebsd.org Wed Jul 12 08:54:04 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 104FBD918A3 for ; Wed, 12 Jul 2017 08:54:04 +0000 (UTC) (envelope-from srs0=flhm=6p=mail.sermon-archive.info=doug@sermon-archive.info) Received: from mail.sermon-archive.info (sermon-archive.info [71.177.216.148]) by mx1.freebsd.org (Postfix) with ESMTP id DFF4F7FA50 for ; Wed, 12 Jul 2017 08:54:03 +0000 (UTC) (envelope-from srs0=flhm=6p=mail.sermon-archive.info=doug@sermon-archive.info) Received: from [10.0.1.251] (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 3x6t6D3Wp5z2fk5S for ; Wed, 12 Jul 2017 01:53:56 -0700 (PDT) From: Doug Hardie Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Unusual Question Date: Wed, 12 Jul 2017 01:53:56 -0700 References: <20170709230708.M27871@sola.nimnet.asn.au> To: "freebsd-questions@freebsd.org Questions" In-Reply-To: <20170709230708.M27871@sola.nimnet.asn.au> Message-Id: X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 08:54:04 -0000 > On 9 July 2017, at 06:14, Ian Smith wrote: >=20 > In freebsd-questions Digest, Vol 683, Issue 8, Message: 1 > On Sun, 9 Jul 2017 02:57:14 -0700 Doug Hardie = wrote: >=20 >> I have a FreeBSD 9.3 remote server that needs to be purged. I know=20= >> that rm -rf / will remove all the directory entries, but I need to=20 >> write over the drive. I thought that dd if=3D/dev/zero of=3D/dev/ada0=20= >> might do the trick, but it gives an not permitted error. The whole=20= >> thing can crash and burn at the end. This is an unmanned site so=20 >> moving drives is not viable. >=20 > # sysctl kern.geom.debugflags=3D16 >=20 > purge at will. if=3D/dev/random for the more paranoid :) >=20 > cheers, Ian Today was the experimentation. I had an old system here at the house = with 8.2 on it. So I started with a dd in=3D/dev/ada0 out=3D/dev/null = to find out how many blocks were on the device. Once I had that number, = I then ran dd if=3D/dev/random of=3D/dev/ada0 skip=3D. I typed oskip, but somehow the o didn't make it through = the keyboard. When it finished, I realized the error. So I had an install memstick for 11.0 and put it on as I wanted to try = camcontrol sanitize. Unfortunately, it reports an error accessing my = drive. I then used dd if=3D/dev/ada0 skip=3D | od = -c. Then I wrote down the first few bytes of the output. They were = non-zero. I was a bit surprised by that since the last partition is = swap and it was never used. But perhaps that was left over from the = random write. =46rom here on I have pictures of the output. This is a = dumb terminal and I will attempt to enter in the data since the list = doesn't accept attachments. dd if=3D/dev/zero of=3D/dev/ada0 bs=3D32k dd: /dev/ada0: short write on character device dd: /dev/ada0: end of device 2442211+0 records in 2442210+1 records out nnnn bytes transferred..... ls -l pwd /bin/pwd: Exec format error. Binary file not executable. who /usr/bin/who: Exec format error. Binary file not executable. dd if=3D/dev/ada0 skip=3D1000 count=3D5 | od -c 0000000 \0 \0 \0 \0 ... * 0005000 5+0 records in 5+0 records out dd if=3D/dev/ada0 skip=3D10000 count=3D500 | od -c 0000000 \0 \0 \0 \0 ... * 0764000 500+0 records in 500+0 records out nnnn bytes transferred... I didn't capture this but I did run the dd with the oskip of the big = number and it showed all zeros. I believe that dd, od and some of the current directory blocks were = still remaining in memory. However, the drive was definitely zapped. = It did write to the end of the drive. However, I suspect that if = something else was running during the dd and it tried to access the = drive things could have come to a halt before the zap completed. At = this point I tried to do a shutdown command and got the same Exec format = error. However, hitting the reset switch did cause a shutdown. It = seemed to be a normal shutdown as there were messages on the console, = but I was not expecting it to work and only saw them for a brief second = before the display was shut off. I would like to have tried camcontrol sanitize as that appears to be = handled completely in the drive and controller. It would complete = regardless of what happened to the OS. I couldn't use it anyway on the = production systems as they are only at 8.3 and the sanitize command was = added in 11.0. Net result: I am not sure if the first production drive actually = completed the zap. It might have, but there is no way to tell. = However, it was not important as it does not hold any sensitive data. = It was tried first to see what would happen. I will make sure nothing = is running but sshd and dd when I do it on the critical systems. I am = considering starting the dd with a nohup and then killing sshd before it = gets very far. I think that has the best possibility of completing = properly.