Announcement

**Qqmike** · Jun 12, 2011, 10:28 AM

Re: Privacy Cleanup 101

Privacy101_Reply_1_NEW

How to securely delete data

Contents

-- How to securely delete data: history, misconceptions, controversy
My take on this -- A prescription for your data wiping
(This is the current version of the topic)

-- Archive (a previous version)
When you delete a file, you do not delete the file
How to Wipe Data: Logic behind a zero-fill
Note the section titled
See for yourself. A Deleted File is Not Deleted
(An experiment: dd if=/dev/sdc1 bs=16065b | hexdump -C | grep 'Zmy Zfacts')

How to securely delete data, history, misconceptions, controversy.

How many "overwrites" are needed to safely wipe your data?
Can you recover overwritten data?
How should you overwrite your data?
How about the government DoD 7-pass standard?
and, finally,
-> My take on this -- A prescription for your data wiping

Answers:
One.
No.
Any way you wish.
Where did THAT come from?
My take on this? See below.

Here's the scoop, my logic, and I'm going to be brief because we have better things to do in this how-to.
The references are the key.

In 1996, Peter Gutmann Department of Computer Science, University of Auckland, wrote his now (in)famous, Secure Deletion of Data from Magnetic and Solid-State Memory. THAT is the document that is widely misquoted and misused to promote/preach all sorts of extreme overwriting strategies and rules ("voodoo incantations") for how to overwrite data to prevent recovery. You'll see them all over the Internet, secure data deletion programs that perform up to 35 passes over the data, each time overwriting the data using zeros, ones, other numbers, random numbers, and pseudo random numbers.

Even Gutman takes issue with the mis-use, misinterpretation, of his paper. Sometime between 1996 and 2002, he wrote his Epilogue:

"In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical
analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, 'A good scrubbing with random data will do about as well as can be expected'. This was true in 1996, and is still true now." [Emphasis added]

In July 2003, Daniel Feenberg, National Bureau of Economic Research, Cambridge MA, published a cogent rebuttal to the Gutman paper, "Can Intelligence Agencies Read Overwritten Data? A response to Gutmann." After working through several logical points, as well as points of evidence, Feenburg concludes, "... that Gutmann's claim belongs in the category of urban legend. Or it may be in the category of marketing hype ..." and " ... Of course it has been several years since Gutmann published. Perhaps microscopes have gotten better? Yes, but data densities have gotten higher too. An hour on the web this month looking at STM sites failed to come up with a single laboratory claiming it had an ability to read overwritten data ... Recently I was sent a fascinating piece by Wright, Kleiman and Sundhar (2008) who show actual data on the accuracy of recovered image data. While the images include some information about underlying bits, the error rate is so high that it is difficult to imagine any use for the result. While the occasional word might be recovered out of thousands, the vast majority of apparently recovered words would be spurious ... Charles Sobey has posted an informative paper "Recovering Unrecoverable Data" with some quantitative information on this point. He suggests that it would take more than a year to scan a single platter with recent MFM technology, and tens of terabytes of image data would have to be processed."

Charles H. Sobey, in his white paper, "Recovering Unrecoverable Data - The Need for Drive-Independent Data Recovery," (see Section 4.2.2 Magnetic Force Microscopes (MFM)), after rather technical analysis, concludes, " ... Although such exotic methods of data recovery are theoretically possible ... I have found no evidence of commercially viable recoveries being performed. Furthermore, I have seen no public demonstrations of any of these methods that show the recovery of files or even user data--only images or raw encoded data." And like other sources, Sobey points out that the error rates inherent in the technology of trying to read any data off disks are very high.

Starman--Daniel B. Sedory--having researched the topic to its outer limits, concludes that for most of us and almost all home or personal privacy needs, "... we believe simply 'zeroing-out' a drive AND checking that it has actually been done is more than adequate." And, further, "...NOW IN THE YEAR 2008, after 15 years of people warning others and passing along their fears of possible scenarios involving electron (sic) microscopes, WE STILL have NEVER heard of a single case from any lab actually using a microscope to discover any useful bit patterns [emphasis added]!" And, "Personally, I'm not at all concerned about anything I 'zero-out' on a hard disk ever being seen by someone else again. If you think that any local law enforcement or government agency is going to attempt to find data on a drive with ALL zeros by taking a very long time and spending more money than they can really afford with no assurance whatsoever of finding anything(!), then you're living in a dream world that's already beyond all the fictional elements in TV shows like CSI and other such scientific forensic evidence dramas. It's much easier ... to obtain data about you using many other means!"

Finally, you will see MANY Internet references to the US government 7-pass DoD wipe standard (as per DoD 5220.22-M). After another extensive research effort, Starman is unable to fully trace where this came from. Although it can mean many things, most references to the government 7-step wipe consider it to be " ... three cycles of alternating patterns of 0x00 and 0xFF, followed by an 0xF6 byte pattern for a total of seven passes. But as the DSS and other security organizations have pointed out, they rarely include a verification pass!" (See Starman, "DoD 5220.22-M and its relation to the so-called DoD Wipe Standard")

-> My take on this -- A prescription for your data wiping

For most of us, it suffices to do a simple one-pass zero-fill (zero-out) of your files/partition/drive to ensure that no one will be able to retrieve your data. That includes users who keep on their PCs personal correspondence/emails, documents, normal business, finance, and medical records, family/personal photos, and personal items downloaded from the Internet (including legal adult materials).

Other things you can do: Now, if you wish to do a pass with random or pseudo random numbers instead of zeros, that's fine, too; or do multiple passes. Another thing some folks believe in is doing a zero-fill followed by a fill with truly random numbers; the random numbers making it less obvious that a file was wiped, and maybe making it technically more difficult to detect meaningful information from the wiped bits. Or, do a zero-fill of a file, then before deleting the file change it's name to some random characters or a nonsense name, again making the job of data recovery folks more difficult. Some sources do a wipe using random numbers, then a final wipe with zeros (the opposite of what has been said above).

If your data is extremely sensitive for whatever reasons, my sense is that you will be able to decide what to do based on what is said here and the links (which I'm sure you will read in great detail). Having said that, (1) the evidence suggests that one zero-fill will likely do the trick; (2) some folks would probably feel better doing two or three passes, perhaps with zeros and random numbers; and (3) most folks in the category will want to secure their data and PC physically, and when done with a drive will want to physically destroy it (using standard means of physical shredding, burning, hammering it into small pieces, using a blow torch on it, etc.).

References

Peter Gutmann, Secure Deletion of Data from Magnetic and Solid-State Memory
http://www.cs.auckland.ac.nz/~pgut00...ecure_del.html

Peter Gutmann, Epilogue
http://mirror.href.com/thestarman/as...nnEpilogue.txt
(Credit goes to thestarman.)

RE: Peter Gutmann data deletion theaory (sic) ?
http://seclists.org/bugtraq/2005/Jul/464

Daniel Feenberg, "Can Intelligence Agencies Read Overwritten Data? A response to Gutmann."
http://www.nber.org/sys-admin/overwr...a-gutmann.html

Charles H. Sobey, "Recovering Unrecoverable Data - The Need for Drive-Independent Data Recovery,"
527KB PDF. Published April 14, 2004.
http://www.actionfront.com/ts_whitepaper.aspx

Daniel B. Sedory (starman), "How To Permanently Erase Data from a Hard Disk"
Copyright©2003-2008 by Daniel B. Sedory (starman)
http://mirror.href.com/thestarman/asm/mbr/WIPE.html

Daniel B. Sedory (starman), "An overwriting standard: there was some truth to it in the past"
http://en.wikipedia.org/wiki/Talk:Na...ting_standard:
_there_was_some_truth_to_it_in_the_past

Daniel B. Sedory (starman), "DoD 5220.22-M and its relation to the so-called DoD Wipe Standard"
http://mirror.href.com/thestarman/asm/5220/index.html
Compiled by Daniel B. Sedory
All Original Research is Copyright©2008 by Daniel B. Sedory
(re Where did the so-called 7-pass DoD 5220.22-M Wipe Standard originate?)

= = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = = = = = = =
Archive, a previous version.
Note the section titled
See for yourself. A Deleted File is Not Deleted
(An experiment: dd if=/dev/sdc1 bs=16065b | hexdump -C | grep 'Zmy Zfacts')

When you delete a file, you do not delete the file
How to Wipe Data: Logic behind a zero-fill.

Contents
-- How to Delete Data from Your Hard Drives & USB Drives
-- History
-- Deletion: This will explain the issue
-- Preparing a drive for new partitioning & formatting
-- Methods of performing a zero-out of (or a zero-fill on) your drive
-- See for yourself. A Deleted File is Not Deleted
(An experiment: dd if=/dev/sdc1 bs=16065b | hexdump -C | grep 'Zmy Zfacts')
-- References (the classic sources for this)
-- SEAGATE's excellent explanation of Zero Fill

How to Delete Data from Your Hard Drives & USB Drives

Answer:
Zero-out the drive: Perform a zero-fill to the drive.

Question:
How can you delete data/partitions from your hard drive to ensure (with probability close to 1.0) that no one can retrieve the data or would expend the effort (time, equipment, expense) to retrieve the data?

An easy, quick fix? Perhaps. You can google on this and run into just about anything you are looking for. You have to decide for yourself based on all that is written and sold on the subject. Personally, I believe what I wrote above as the answer, and I've given you some key references to look at for yourself.

- - - -
History

It started with the classic voodoo formula(s) of Peter Gutmann in his “Secure Deletion of Data from Magnetic and Solid-State Memory,” to which later he wrote a “moderating” Prologue. All sorts of commercial cleaners have quoted Gutmann and used his methods (e.g., the multiple, sequential, structured overwrite passes). Daniel Feenberg with the National Bureau of Economic Research wrote his rebuttal of Gutmann's paper, and it seems to make the most sense, which Starman takes pretty much as his position. It's all in the References--and there is some interesting reading, notwithstanding whatever the scientific and clinical truths may be.

- - - -
Deletion: This will explain the issue
In a certain real sense, when you delete a file, you do not delete the file.

When you perform a “delete a file,” you are merely deleting the name of the file or the database references (pointers) to the file; same goes for “deleting a partition”: You are simply deleting the partition entry in the Master Boot Record (or Extended Partition records). In both cases, the data in the file or partition remains on your disk.

In practice, properly deleting data, rendering it essentially unrecoverable, is done using either software or physical means. Using software, the best way to delete the data seems to be to simply overwrite the bytes with zeros (or with random numbers). Using physical means, the best way seems to be using a sledge hammer followed by extreme heat (e.g., by blow torch); and somewhere I've read that is the recommended method used by the DoD. If you are feeling paranoid or extra cautious, you can perform more than one overwrite pass on your disk/partition/file to ensure it is “gone.” You might overwrite it with zeros, then random numbers (and, perhaps, zeros again).

- - - - -
Many “issues “ involved when we talk about “deleting” files. This is not our topic here, but to alert you to the ideas, here's a quote from Feenberg (see References):
“ ... modern operating systems can leave copies of " deleted" files scattered in unallocated sectors, temporary directories, swap files, remapped bad blocks, etc, ... “ A good example is encryption: when you encrypt a file, do you ever think about deleting (zero-ing) the original text file?

- - - - -
Preparing a drive for new partitioning & formatting

This is another reason to wipe the drive (zero-out the drive, or zero fill it), especially so if you may ever need to recover data/partitions on that drive (as it is easier to do if there are no lingering remnants of prior partition table information, especially so for prior extended partitions).

- - - - -
Methods of performing a zero-out of (or a zero-fill on) your drive
Ways to write zeros to a file, to a partition, or to an entire drive

--- dd command
Read my How-To on it and follow up the references given there:
http://kubuntuforums.net/forums/inde...opic=3117215.0

Very easy to do—one dd command to zero-out a disk, a partition, or a file. On one test, I used a one-line dd command to write zeros to a 160 GB Seagate SATA HDD; it took 45 minutes. Keep in mind that dd works bit-by-bit, and thus, is quite effective in overwriting the drive.

--- dcfldd: the souped-up DoD version of the command dd (which gives you a progress report as it goes).

--- Knoppix Live CD: Run dd from there. (See References.)
If you need root privileges at the command line, sudo su always works.
If you must mount a drive, right-click the Desktop drive icon, select Mount.
To see a list of packages installed in Knoppix, at a terminal type
dpkg --get-selections > list_of_programs
(Then open Konqueror > Home > and you'll see the text file list_of_programs under the root home. Mine had 1343 programs listed on the CD (use Edit > Find Line).)

--- Run dd from any Linux Live CD, including your Kubuntu Live CD.

--- Your hard drive manufacturer may have a utility to zero-fill the drive.
Seagate does, on its DOS Seatools CD. Seagate also has an excellent description of zero fill on its knowledge base support page. It's so good, I decided to reproduce it at the end here.

-- And possibly other methods, such as dban (see References—and Starman's Caution!)

= = = = = = = = = = = = = = =
See for yourself. A Deleted File is Not Deleted

To keep it simple, safe, manageable, and fast, I did this with a 2 GB flash drive.
While in Kubuntu, plug in the flash drive, let it come up, say OK, then close the flash drive window. To see how Kubuntu sees it, run
sudo fdisk -lu.
Mine is seen as /dev/sdc.
Zero-out the 2 GB flash drive:
dd if=/dev/zero of=/dev/sdc
Output (note that it took about 11 minutes):
dd: writing to `/dev/sdc': No space left on device
4030465+0 records in
4030464+0 records out
2063597568 bytes (2.1 GB) copied, 659.81 seconds, 3.1 MB/s

Partition it using GParted: K > System > Partition editor > Device > sdc.
Make a 1 GB, FAT32 partition, sdc1. (You will be asked first to set a Disk Label – say Yes.)
Re-run sudo fdisk -lu:
Disk /dev/sdc: 2063 MB, 2063597568 bytes
255 heads, 63 sectors/track, 250 cylinders, total 4030464 sectors
Units = sectors of 1 * 512 = 512 bytes; Disk identifier: 0x000479e1
Device Boot Start End Blocks Id System
/dev/sdc1 63 2040254 1020096 b W95 FAT32

Cylinder size:
63 sectors (per track) * 255 heads = 16,065 sectors per cylinder.
1 sector = 512 bytes = b (“b” is the abbreviation for 512 bytes).
=> 1 cylinder = 16,065b bytes (= 8,225,280 bytes)
=> it's a handy “block size” to use (since a partition contains a whole number of cylinders)

OK. Have a look at it.
dd if=/dev/sdc1 bs=16065b | hexdump -C
That prints to the screen the locations (“offsets”) (hexadecimal in the left column), the contents in the main columns, and a (somewhat) “regular” (ASCII) format in the right section. The dd command “copies” (and processes) data in blocks of 16,065b bytes at a time. You should see a bunch of zeros. If there are too many ending zeros, they are represented by an “*”.

Put a text file in the partition sdc1:
On Kubuntu Desktop, right-click, Create New > Text File; name it Financial dataWW.
Open Financial dataWW and type: Zmy Zfacts.
Open the sdc1 icon, drag/copy the file Financial dataWW into it.
Have a look at it. Close sdc1. At Konsole, you can type the same hexdump command as above, or this one:
dd if=/dev/sdc1 bs=16065b | hexdump -C | grep 'Zmy Zfacts'
126+1 records in
126+1 records out
1044578304 bytes (1.0 GB) copied, 117.039 seconds, 8.9 MB/s
001ff400 5a 6d 79 20 5a 66 61 63 74 73 20 0a 00 00 00 00 |Zmy Zfacts .....|
NOTE: grep searches the hexdump for Zmy Zfacts; it found it at location (“offset”) 001ff400.
Or, do a FULL dump: dd if=/dev/sdc1 bs=16065b | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00004030 ff ff ff 0f 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00004040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000fca30 ff ff ff 0f 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000fca40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
001f5400 42 61 00 57 00 57 00 00 00 ff ff 0f 00 7c ff ff |Ba.W.W.......|..|
001f5410 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
001f5420 01 46 00 69 00 6e 00 61 00 6e 00 0f 00 7c 63 00 |.F.i.n.a.n...|c.|
001f5430 69 00 61 00 6c 00 20 00 64 00 00 00 61 00 74 00 |i.a.l. .d...a.t.|
001f5440 46 49 4e 41 4e 43 7e 31 20 20 20 20 00 00 1a 7f |FINANC~1 ....|
001f5450 48 38 48 38 00 00 12 7f 48 38 0c 00 0c 00 00 00 |H8H8....H8......|
001f5460 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
001ff400 5a 6d 79 20 5a 66 61 63 74 73 20 0a 00 00 00 00 |Zmy Zfacts .....|
001ff410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

==>>> Do you see anything on the right that looks familiar? (You should!)

Now delete that file from sdc1 (open sdc1, right-click on the file, Move to Trash), and run the hexdump again:

dd if=/dev/sdc1 bs=16065b | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
001f5400 e5 61 00 57 00 57 00 00 00 ff ff 0f 00 7c ff ff |.a.W.W.......|..|
001f5410 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |................|
001f5420 e5 46 00 69 00 6e 00 61 00 6e 00 0f 00 7c 63 00 |.F.i.n.a.n...|c.|
001f5430 69 00 61 00 6c 00 20 00 64 00 00 00 61 00 74 00 |i.a.l. .d...a.t.|
001f5440 e5 49 4e 41 4e 43 7e 31 20 20 20 20 00 00 1a 7f |.INANC~1 ....|
001f5450 48 38 48 38 00 00 12 7f 48 38 0c 00 0c 00 00 00 |H8H8....H8......|
001f5460 e5 2e 00 54 00 72 00 61 00 73 00 0f 00 e4 68 00 |...T.r.a.s....h.|
001f5470 2d 00 31 00 30 00 30 00 30 00 00 00 00 00 ff ff |-.1.0.0.0.......|
001f5480 e5 52 41 53 48 2d 7e 31 20 20 20 10 00 00 e3 80 |.RASH-~1 .....|
001f5490 48 38 48 38 00 00 e3 80 48 38 0d 00 00 00 00 00 |H8H8....H8......|
001f54a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
001ff400 5a 6d 79 20 5a 66 61 63 74 73 20 0a 00 00 00 00 |Zmy Zfacts .....|
001ff410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00200400 2e 20 20 20 20 20 20 20 20 20 20 10 00 00 e3 80 |. .....|
00200410 48 38 48 38 00 00 e3 80 48 38 0d 00 00 00 00 00 |H8H8....H8......|
00200420 2e 2e 20 20 20 20 20 20 20 20 20 10 00 00 e3 80 |.. .....|
00200430 48 38 48 38 00 00 e3 80 48 38 00 00 00 00 00 00 |H8H8....H8......|
00200440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
==>>> Look down the right column—see anything familiar? (You should!)

Or, simply run the targeted search for the key phrase Zmy Zfacts:
dd if=/dev/sdc1 bs=16065b | hexdump -C | grep 'Zmy Zfacts'
And get this output:
mike@mike-desktop:~$ dd if=/dev/sdc1 bs=16065b | hexdump -C | grep 'Zmy Zfacts'
126+1 records in
126+1 records out
1044578304 bytes (1.0 GB) copied, 136.503 seconds, 7.7 MB/s
001ff400 5a 6d 79 20 5a 66 61 63 74 73 20 0a 00 00 00 00 |Zmy Zfacts .....|

=> CONCLUSION: Looks like our deleted file data is not deleted.
You can continue experimenting. Next, I saved a new text file in sdc1, looked at it, and one can see how the two data files show up, with some of the first file (Financial dataWW) being overwritten.

Another way to verify that a deleted file is not deleted: PhotoRec
Delete a file from your /home, then use PhotoRec to recover files of that type (text, odt, jpg, whatever type the deleted file is). PhotoRec will (probably) find the file you thought was deleted. The file was only deleted in your filesystem; it was not deleted from your disk.

= = = = = = = = = = = = = = =
References

Secure Deletion of Data from Magnetic and Solid-State Memory, Peter Gutmann
http://www.cs.auckland.ac.nz/~pgut00...ecure_del.html
(*** Read his updated Epilogue!)

National Bureau of Economic Research, Daniel Feenberg
Can Intelligence Agencies Read Overwritten Data?
http://www.nber.org/sys-admin/overwr...a-gutmann.html

How To Permanently Erase Data from a Hard Disk, Daniel B. Sedory (starman)
http://www.geocities.com/thestarman3/asm/mbr/WIPE.html

Helix Live CD
http://www.e-fense.com/helix/contents.php
(with the special dd version dcfldd)

Knoppix
http://www.knoppix.org/

DBAN http://dban.sourceforge.net/
(wipes hard drive – Caution: Starman cautions you to be careful configuring your command statement! dban may try to wipe ALL your drives!)

PhotoRec
http://www.cgsecurity.org/wiki/PhotoRec

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

SEAGATE's excellent explanation of Zero Fill
(www.seagate.com)

Quote:
How Do I Low-Level Format a SATA or ATA (IDE) Hard Drive?
Answer
* What does "low level formatting" a SATA or ATA (IDE) drive mean?
* Why would I want to Zero Fill my drive?
* How do I Zero Fill my drive?

What does "low level formatting" a SATA or ATA (IDE) drive mean?

Actually the term "low level" is a bit of a misnomer. The low-level process first used years ago in MFM hard drives bears little resemblance to what we now call a "low-level format" for today's SATA and ATA (IDE) drives. The only safe method of initializing all the data on a Seagate device is the Zero Fill erase option in SeaTools for DOS. This is a simple process of writing all zeros (0's) to the entire hard disc drive.

Why would I want to Zero Fill my drive?

The most common reasons to Zero Fill a SATA or ATA (IDE) hard drive are:

* to remove a virus that cannot be removed without destroying the boot sector.
* to change from one operating system to another and wish to remove everything from the drive.
* to erase confidential information for privacy reasons.
* to scan for bad sectors that can be detected and replaced with good spare sectors when writing to the sectors.

By design, modern disc drives maintain spare sectors for reallocation purposes. Usually, sectors become difficult to read long before they become impossible to read. In this situation the actual data bytes in the sector are preserved and transferred to the new spare during a sector reallocation. Similarly, when a disc drive writes data (like a zero fill erase procedure) and encounters a problem, the drive firmware retires the problem sector and activates a replacement before giving successful write status.

How do I Zero Fill my drive?

* Zero Filling a SATA or ATA (IDE) drive destroys 100% of the data on the drive. Make sure the drive is completely backed up before proceeding.
* The Zero Fill erase option in SeaTools for DOS is the best method for use with Seagate hard drives. Some system BIOS may include a Low-Level Format option; these should be avoided, as they may produce undesirable results.

SeaTools for DOS can be downloaded from the SeaTools homepage. It includes three Erase (Zero Fill) options. Zero Fill writes zeros in each data sector for the complete capacity of the drive and cleans up most defects.

The download routine for SeaTools for DOS creates a bootable CD or floppy diskette. Boot from the CD media or diskette to start SeaTools for DOS. After startup, it is a good idea to test your drive. The Basic Short Test takes less than a minute to complete. The Basic Long Test can take several hours to complete, depending on the capacity of the drive. When you are ready to erase the drive

select the drive you want to erase. Then select one of the three zero fill Erase functions.

Erase Track ZERO: Erases just the first 63 sectors on the drive which takes less than a second to complete. This procedure removes the Master Boot Record (MBR) and Partition Table. This will cause the drive to look "empty" to a new installation of the operating system.

Timed Erase: Erases sectors for various time limits up to 5 minutes. These options will overwrite the sectors at the beginning of the drive where the majority of the static operating system files reside.

Full Erase: Erases every data sector on the drive and takes a long time to complete. This procedure can easily take several hours to complete. The advantage of this option is to discover and reallocate any defective (hard to read) sectors to good spares. This option comes closest in concept to the original idea of a low level format.

When the process completes, reboot the system from the operating system install CD and follow the instructions to prepare (partition and format) the drive and install the operating system.

[END OF SEAGATE's TEXT]

**Qqmike** · Jun 12, 2011, 10:29 AM

Re: Privacy Cleanup 101

Disk/Partition Full! Warning! What to do about it

Checking your space: ls, df, du
Konsole: configure history (# lines to show)
A decision tree
References

Checking your space: ls, df, du

ls and du: work relative to the directory you issue them from
df: works from any directory you are presently in

ls -al
List all files (in the present working directory) in long form and shows you their size. A quick way to check things. First, change directories (cd) into the directory (folder) you wish to check.
See man ls.

df -hT
A quick way to see your mounted filesystems, the space Used and Available, your root (/) and /home directories. You can issue this from any directory and get the same result.
See man df.

du
Shows you the disk usage of each file. Change into the directory you wish to check. du will check it and subdirectories recursively. So you run it, study the output, pick a directory from the output to investigate further, change directories into that directory (using cd), run du again, study the output, etc. Try these now, first changing into the root directory (cd /), then after changing into your home directory (cd ~ , or: cd /home/your_name).
du -sh is a summary (-s) only, in human readable form (-h)
du -h shows directory details (and subdirectories).
du -ah shows (all = -a) files
See next topic about configuring Konsole.

Konsole: configure history (# lines to show)
When you issue a command that prints a large number of lines, you can scroll up to see lines that have scrolled off the screen; or use Up arrow or Page Up. The default is to show you 1000 lines this way. If you need more (e.g., using du in certain cases), you can configure Konsole to show you them all:
Open Konsole, Settings, History, History Configuration, Set Unlimited, OK.

Disk/Partition Full! Warning! What to do about it: a decision tree

-> Applies to your hard drive or flash drive or external USB drives.

If you fill up your Kubuntu partition (or a separate /home partition), it may become impossible to work in the operating system. And if you were to re-boot, you will not be able to log in to your KDE (and you'd have to work only at a command line). To be safe, some experts recommend not exceeding 85% full (and at that point, you should start deleting files you do not need).

If this happens to you, what must you do?
=> You must delete some files
from your Kubuntu root partition or from your /home partition.

Things to check when your disk/partition is full or you receive a warning message
> Root's home: /root
> Trash
> Check package archives (APT, Advanced Package Tool)--see below
> Remove old kernels?
> Privacy 101 checklists (especially things like large email archives)

Tools to use: ls-al, df -hT, and du -sh, du -h and du -ah)

The culprit is often the home of root: /root. When working or messing around, as you have invoked root (using sudo or kdesudo), you may have inadvertently saved a large amount of data to root's home (this can occur, for example, when using various programs, like PhotoRec).

Also check the Trash, including its actual location:
/home/your_name/.local/share/Trash/files and /home/your_name/.local/share/Trash/info.
And check the Trash in root's home, /root.

Check package archives (APT, Advanced Package Tool). But read man apt-get first.
At Konsole, use some/all of these these commands
sudo apt-get clean
sudo apt-get autoclean
sudo apt-get autoremove

Old kernels -- use your package manager to remove old kernels and their (many) files (linux-image and linux-headers).

And, of course, check the items listed under Privacy Cleanup 101.

Decision Tree: What to do when you get disk or partition full

Step 1 Rescue your data
If the data stored on the drive/partition is important to you, copy it off now, as soon as you realize there is a problem. Boot into a live CD or any OS on your hard drive.

Live CD, working from: mounting.
sudo fdisk -lu to see how the drive/partition is named (e.g., sda2, sdd1, etc.). Suppose it appears as sdxn.
sudo mkdir /media/sdxn
sudo mount /dev/sdxn /media/sdxn
When you are done working, unmount it and exit:
sudo umount /dev/sdxn1 /media/sdxn
exit

To open Konqueror as root (if necessary):
kdesudo konqueror (or try kdesu konqueror for older Kubuntu versions)

Step 2: Are you able to boot into the Kubuntu partition? If not, go to Step 3.
If you able to boot into your Kubuntu, then:

Boot into it. Find the folders/files containing your data, delete/remove any data you don't need.
Checklist:
> Root's home: /root
> Trash
> Privacy 101 checklists (especially things like large email archives)
Tools to use: ls-al, df -hT, and du -sh, du -h and du -ah)
Remember to use the manual pages; e.g., man ls, man du, man df
Use df, ls, and du to see if your efforts to free up space were successful.
If you are satisfied, re-boot; hope for the best.

Step 3: If you are NOT able to boot into your OS.
Now, this is a problem, but it is often solvable.
Symptoms
When you try to boot into Kubuntu, you get strange error messages. (Popular ones are "No write access to /.ICEauthority"; "Could not start ksnserver"; or "Disk full" messages). Or, you hit the log-in screen but are bounced back to a blank screen or to the log-in screen again (log-in looping).

Solutions
Remove excess data from the Kubuntu partition and your home partition
As in Step 2, you must try to delete/remove as much unneeded data as possible. But since you can't log in, you'll have to do the work using a live CD or by booting into another operating system on your hard drive. In either case, you must access the partition from where you are, and that simply means you must boot into an OS (on disk or a live CD), run sudo fdisk -lu, then mount the broken partition(s) if it is not automatically mounted, then open it and see the files on it (doing this either at the command line or from Konqueror/Dolphin).

Dropped to a prompt
Perhaps you can almost log in, but can't, and you are dropped to a prompt or are able to get a prompt.
In this case, you may be able to do the work at the command line, using commands like cd, pwd, ls -al, and rm (or rm -r dir). See the tips in Step 1. Remove as much data as you can.

Try now to re-boot
If you can, you are done!
If not, perhaps something got damaged and must be fixed. Continue:

Step 4: Check/repair the filesystem
Find out how the broken partition is named using sudo fdisk -lu. Let's say it is sdxn (e.g., sda1, sdb1, sdc1).
First, unmount the flash drive!!! <= VERY IMPORTANT!!!
(sudo umount /media/<mount point> or sudo umount /dev/sdxn)
sudo fsck -vt /dev/sdxn
And/or, for ext2/3:
sudo e2fsck -vt /dev/sdxn

After that's done, re-boot to test.
If that works, your are done!
If not, continue:

Step 5: KDE settings damaged
Re-boot, try to get to the log-in screen. If you can't get that far and you've done all the above, you will have to try something else--this guide will not help you further. Post the issue at a forum. See tips below, too.
If you can get to the log-in screen:
At the log-in screen, get a virtual console by pressing Ctrl+Alt+F1.
You may have to log in by typing root. (If you are asked for a password, try yours; if it won't go, try to set a new one: passwd, then make one up.)
Rename your KDE folder (called /.kde):
mv /home/your_name/.kde /home/your_name/kdesaved
(the dot in .kde means it is a hidden file)
Get a graphical log-in screen by pressing Ctrl+Alt+F7.
You may get a KDE wizard to help you build a new KDE configuration and/or a new /.kde folder will be constructed for you and you'll be booted into Kubuntu.
Try re-booting.
If that fails, continue:

Step 6: kdm repair
Boot recovery mode, at the first pause (where you are the root user) enter the command:
/etc/init.d/kdm start
Then perform a normal shutdown/restart and use your normal boot line.
Or, if needed, another idea:
Remove / reinstall kdm and see if that works.
sudo aptitude remove kdm
sudo aptitude update&&sudo aptitude install kdm
Re-boot.

Step 7: KDE unable to start
You try to log in to Kubuntu and you get a message
"No write access to home/user/.ICEauthority KDE is unable to start" and/or then another one saying "Could not start ksmserver. Check your installation"

Possible solution (quote dibl):

You have made the mistake of performing some root operation, or running the X server as root, from your user's home folder, resulting in the permissions on that file being changed to root. To restore them, at the command line you need to stop the X server:
sudo service kdm stop
then delete the two files that are likely "contaminated":
sudo rm /home/your_name/.ICEauthority
sudo rm /home/your_name/.Xauthority
then restart the X server:
sudo service kdm start

log in, and you should be OK. But don't run the X server with "sudo", and don't save files in your user's folder when running as root.

Thanks to dibl, here:
KDE is unable to start (dibl)
http://kubuntuforums.net/forums/inde...opic=3109580.0

References for this problem (locked up booting, broken KDE, or log-in looping)

>>> From dibl: --> These links have changed!!! <--- See How-To's
Top 20 Kubuntu FAQ
http://kubuntuforums.net/forums/inde...opic=3099811.0
FAQ#16. Out of disk space, filesystem full, how can I tell where it went, etc. etc.
FAQ#10: Log-in loop
"I log in, the screen goes black, and then I get the login GUI again / Login Loops but can't log in." There are multiple possible causes, and thus multiple possible fixes. Start here, and check the linked threads if necessary. Do NOT ever perform "sudo" or root operations, such as installing software or saving files, using your user's home directory -- this is a common cause of the "login loop" problem. The permissions on the hidden files .ICEauthority and .Xauthority are easily changed by root use of your user's home directory, and thereafter the user is locked out.
KDE is unable to start (dibl)
http://kubuntuforums.net/forums/inde...opic=3109580.0
>>> From Rog131:
FAQ: Free Disk Space
http://kubuntuforums.net/forums/inde...opic=3086353.0
>>> From Herman:
Fixing filesystems, damaged superblock:
Filesystems and Mounting (and fixing):
http://users.bigpond.net.au/hermanzone/p10.htm
>>> Log-in Loop:
http://kubuntuforums.net/forums/inde...opic=3096050.0
http://kubuntuforums.net/forums/inde...opic=3097104.0
http://kubuntuforums.net/forums/inde...opic=3096050.0
http://kubuntuforums.net/forums/inde...opic=3088389.0
http://kubuntuforums.net/forums/index.php?topic=9765.0

[End of Decision Tree]

------------------------------------------------------
------------------------------------------------------
References

RESCUE Partitions & Data, TestDisk--PhotoRec--Knoppix
http://kubuntuforums.net/forums/inde...opic=3091847.0 )
--> This link has changed!!! <--- See How-To's

Commands at Konsole: Beginners: 3 parts
http://kubuntuforums.net/forums/inde...opic=3117209.0

dd Command
http://kubuntuforums.net/forums/inde...opic=3117215.0

Announcement

Privacy Cleanup 101

Privacy Cleanup 101

Comment

Comment