Decommissioning an HP K Box

[Roger T. Wilson]

I am in the process of decommissioning a K and N box. I need to reformat (zero out) all disk on this system.

How and where would I begin?
Is there a doc on ITRC I can use.

[Steven E. Protter]

Boot the system off a Core OS CD

Do a basic installation, include all disks in the LVM phase.

Complete the installation.

This will destory everything. Also whomover gets the box will get nothing.

This is how I do it.

My employer is a charity if you are looking for a home for the box.

SEP

[Geoff Wild]

If you really...really want to zero out the disks:

How to use ODE to wipe out a disk
Reboot the machine
Insert the support plus media cd
Stop the "boot primary path"

Then find the cdrom drive:

>search

>boot

At the ISL prompt:

ISL>ode

At the ODE prompt:

ODE>diskexpt

You will be prompted for a password, you will need to ask HP for a temporary one - you can only get it if you have a contract with HP:

Commands to use in DISKEXPT:

To see disks: dispmap
Select disk: testdisk #
Then enter:

wrtmt

For range, enter 0/ and the max number displayed
Select 3 for userdefined, then enter 0 to write all zero's

Wait.....a long time........a really long time....

Do this for all disks.....



Otherwise, just do what Steven suggested.


Rgds...Geoff

[Roger T. Wilson]

Would the cold install do all the disks, putting null values on the disk?

Sincerely,

Roger

[Geoff Wild]

No - cold install will only affect vg00....though you could configure the rest of the disks as swap?


Rgds...Geoff

[Roger T. Wilson]

Could I not do a dd on vg01 - vgxx?

I was thinking I could use the if=/dev/null and of=/dev/dsk/c3t0d3.

But I don't know what the count= should be.

Can I make all of VG01-VG11 swap?

Guess I'm a little confused.

[Patrick Wallek]

Doing a cold install and selecting all disks to be part of VG00 will not delete the data on the disks. It will wipe out VGRA that was on the disks so you can no longer tell what VG the disks used to belong to. If someone is really industrious they could still possibly get data off the disks though it wouldn't be a trivial task.

You can find *lots* of threads on this subject in the forums. I did a search on "wipe disks" and got 50 hits back. Not all will be applicable to you, but a lot of them are.

Here is one of the more recent threads returned:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=382186

[Steven E. Protter]

My method:

A cold install using all disks, even without filesystems filling them all will zero every byte on every disk.

SEP

[Doug Burton]

I like the "zero" one:

Run this to wipe your drives (write "nothing" to the drive):
dd if=/dev/null of=/dev/rdsk/c?t?d? bs=1024k

or (write "0" to the drive):
dd if=/dev/zero of=/dev/dsk/c?t?d? bs=1024k

If you don't have /dev/zero, you can make it (11.11 (11i) already has /dev/zero):
mknod /dev/zero c 3 0x000003 #...on 10.20
mknod /dev/zero c 3 0x000004 #...on 11.x
chown bin:bin /dev/zero
chmod 666 /dev/zero

or....
mediainit -v /dev/rdsk/c?t?d?

[Tim D Fulford]

I've seen this type of question a few times. I decided to do someting similar because I've ALWAYs wanted to do naughty things like "rm -rf /"... or ... "chmod -R 400 /" & see what happens.

You can take the opportunity do this before any real zeroing activity on the disks

Have fun

Tim

[rmueller58]

An acquantance of mine was fairly new to scripting.. he was building a script to create an informix database from a disk export.. in reviewing his work I caught this particular piece of code after restoring from backup..

echo "enter database name"
read variable
cd /
export database variable
export exportedbfilesystem /exportfs/dbexport/
cd $exportedfilesystem
dbimport $variable
rm -f *

Needless to say it took a day or so to recover.. :(

[Pete Randall]

I have to concur with Patrick on this - including all disks in a re-install will not wipe out the data. There was a recent thread on this same "phenomena", where the questioner rebuilt the VG and LV data and was able to use the pre-existing file system - the LVM structures were over-written during the re-create, but the data remained untouched because he had not done a newfs on it.

The re-install method works just fine on the vg00 disk(s), but, for the others, your best bet is to use dd to over-write them with zeros.


Pete

[Steve Lewis]

10 years ago, hardware tools existed which could read the contents of disks which had been low-level formatted many times over. A pattern of repeating data can be analysed, very fine deviations in signal correspond to the previous disk contents. It may have changed since I worked in that area but bear in mind that hackers and spys generally don't lag far behind the technology.

With this in mind, a good quick method is to jam a screwdriver in the side of each drive, opening the casing, then either bending (metal) or breaking (ceramic) each physical platter, so that it cannot be read by anything.

I can also recommend the use of a masonry chisel and 5 pound hammer to assist.

To logically erase the data, but keep the drives for use elsewhere, it depends on the level of assurance you require, but I recommend writing data from a very large and good source of entropy 10 times over the raw device from start to finish.

[doug hosking]

I don't want to start a fight on this, but the matter of data security is important enough to make sure you don't depend on incorrect information. Doing a cold install does not overwrite every byte on the disks. You should be able to convince yourself of this just by how long it takes to start loading data onto the disks during a cold install vs. how long it takes to write a fixed pattern to the whole disk with a simple C program or dd. This is especially apparent on newer (say 36 or 73 GB) disks where the OS only needs to use a small portion of the available space on the drive. newfs initializes the metadata (organizational structure) for the file system but does not clear all of the actual data blocks.

As others have noted, 'sufficient' reformatting varies depending on how motivated someone may be to get to the data in question. A simple newfs/mkfs would be good enough to stop casual snooping. If you want more assurance, running something like:

sync
dd if=/dev/zero of=/dev/rdsk/ bs=256k &
dd if=/dev/zero of=/dev/rdsk/ bs=256k &
dd if=/dev/zero of=/dev/rdsk/ bs=256k &
wait

on all of each disk will do a better job.
Doing these in parallel (background) is faster but not essential.

If your version of HP-UX doesn't have a /dev/zero device you can do the same thing with a simple 10 line C program that keeps writing blocks of zeroes to stdout until it falls off the end of the device.

$ ./a.out > /dev/rdsk/
$ ./a.out > /dev/rdsk/

This is best done from single-user mode, especially when you get to the point of clearing out the final (vg00) disk on the system. (The kernel will get very unhappy when you do stuff like this on mounted file systems, but I've had good luck using it from single user mode in cases where I never wanted to type another command after that dd command finished.)

Be sure to do the above on the rdsk files, not just logical volumes.

If you have reason to be truly paranoid about the data, physical destruction of the drives is the best bet. Personally, I've never had reason to deal with data that I felt needed anything more extreme than the 'dd' approach above.

[doug mielke]

If simplicity counts:


for fs in /etc/fstab
while :
do
cat /somefile >> /fs/someotherfile
done

This would repeatedly write the same data until the fs fills, or the filesize limit is reached.

[doug hosking]

Re:

for fs in /etc/fstab
while :
do
cat /somefile >> /fs/someotherfile
done

Again, this doesn't guarantee all data is overwritten, because, among other reasons, there may be previously removed lvols whose space hasn't been reallocated since they were removed.