Date: Wed, 12 Jul 2017 01:53:56 -0700 From: Doug Hardie <bc979@lafn.org> To: "freebsd-questions@freebsd.org Questions" <freebsd-questions@freebsd.org> Subject: Re: Unusual Question Message-ID: <A683A228-F81C-4596-943A-A10A84F0D504@mail.sermon-archive.info> In-Reply-To: <20170709230708.M27871@sola.nimnet.asn.au> References: <mailman.85.1499601601.14159.freebsd-questions@freebsd.org> <20170709230708.M27871@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 9 July 2017, at 06:14, Ian Smith <smithi@nimnet.asn.au> wrote: >=20 > In freebsd-questions Digest, Vol 683, Issue 8, Message: 1 > On Sun, 9 Jul 2017 02:57:14 -0700 Doug Hardie = <doug@mail.sermon-archive.info> 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<number of blocks = minus a few>. 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<same large number> | 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 <directory listing> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A683A228-F81C-4596-943A-A10A84F0D504>