<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hard Drive on Michael’s Domain</title><link>https://jeltsch.org/en/tags/hard-drive/</link><description>Recent content in Hard Drive on Michael’s Domain</description><generator>Hugo</generator><language>en-us</language><copyright>Copyright © 2002 - 2026 Michael Jeltsch.</copyright><lastBuildDate>Fri, 24 Jul 2026 00:18:18 +0300</lastBuildDate><atom:link href="https://jeltsch.org/en/tags/hard-drive/index.xml" rel="self" type="application/rss+xml"/><item><title>How to manually encrypt a second hard drive in Ubuntu 20.04</title><link>https://jeltsch.org/en/how_do_manually_encrypt_a_second_hard_drive_in_ubuntu_20_04/</link><pubDate>Fri, 19 Nov 2021 00:00:00 +0000</pubDate><guid>https://jeltsch.org/en/how_do_manually_encrypt_a_second_hard_drive_in_ubuntu_20_04/</guid><description>&lt;p&gt;You have added a second hard drive to your encrypted Linux system. The Debian installer makes it easy to encrypt during system installation, but how do you encrypt this new drive?&lt;/p&gt;</description></item><item><title>How to erase hard drives (shred, dd)</title><link>https://jeltsch.org/en/how_to_erase_hard_drives_shred_dd/</link><pubDate>Sun, 25 Jan 2009 00:00:00 +0000</pubDate><guid>https://jeltsch.org/en/how_to_erase_hard_drives_shred_dd/</guid><description>&lt;p&gt;You could write zeros to the whole hard drive&lt;code&gt;dd if=/dev/zero of=/dev/hda&lt;/code&gt;For newer versions of dd, you can monitor the progress:&lt;code&gt;dd if=/dev/zero of=/dev/hda status=progress&lt;/code&gt;However, it has been recommended to write a few passes of random noise (n = 3 is the default). If the writing process entirely got rid of the magnetic history and your source of randomness was perfect, a single pass would ALWAYS be enough. In reality, you only need n&amp;gt;1 if you are dealing with the state secrets since recovering anything after an n=1 erase requires special equipment which you cannot buy in any store. &lt;code&gt;shred -vfz -n3 /dev/hda&lt;/code&gt;&lt;/p&gt;</description></item><item><title>Hardware (harddisk) failure (dma timeout error, dma_timer_expiry)</title><link>https://jeltsch.org/en/hardware_harddisk_failure_dma_timeout_error_dma_timer_expiry/</link><pubDate>Wed, 04 Apr 2007 00:00:00 +0000</pubDate><guid>https://jeltsch.org/en/hardware_harddisk_failure_dma_timeout_error_dma_timer_expiry/</guid><description>&lt;p&gt;A while ago our server seems to have a hard disk failure as the following error messages kept coming up: &lt;code&gt;hda: dma timeout error: […] hda: dma_timer_expiry: […]&lt;/code&gt; We exchanged the 20 GB HD against my old Mac&amp;rsquo;s 4.7 GB HD and reinstalled the system. A friend of mine tried the &amp;ldquo;broken&amp;rdquo; 20GB HD on a Windows system and said it works fine. We put it back as a secondary drive to our server and everything went OK for another 6 months until a similar message started appearing during booting: &lt;code&gt;spurious 8259A interrupt: IRQ7 hdc: read_intr: status=0x59 {DriveReady SeekComplete DataRequest Error} hdc: read_intr: error=0x04 {DriveStatusError} ide1: reset: success&lt;/code&gt; and during shutdown: &lt;code&gt;hdc: status timeout: status=0x80 hdc: drive not ready for command ide1: reset timed-out&lt;/code&gt; Additionally there were strange clicking sound appearing. And there is also a problem with spinning down the hard drive: it never did spin down anymore which made the server quite loud during the night. Since RedHat&amp;rsquo;s default 2.4.20 kernel doesn&amp;rsquo;t support laptop mode, we decided to switch the distro. I exhanged that drive for a 6 GB drive and newly installed Suse Linux 9.1. When I copied over the data from the 20 GB drive to the 6 GB drive there were three or four files that I couldn&amp;rsquo;t copy (IO failure). Now I wonder whether the 20 GB drive is really broken or not. From all symptoms it seems very likely yes. Although if its just DMA failure messages, they can be switched off by turning off DMA mode (given as boot parameters: &lt;code&gt;ide=nodma noapic apm=off&lt;/code&gt; That makes obviously performance worse. DMA means Direct Memory Access and it means that data can be moved from the hard disk to another place (e.g. memory or another disk) without the CPU being involved (which makes it much faster and frees the CPU from unnecessary work.&lt;/p&gt;</description></item></channel></rss>