After having this BOINC machine basically down for a while I decided to give PCLinuxOS another go. I plugged in an external USB drive, inserted my Terabyte Image for Linux CD and rebooted. Once it was off I kicked off a bare metal backup and went about my business. A bit later I walked over and looked at the screen. I had never seen the backup spit up this dialog. It told me there were bad sectors on the source drive and wanted to know if I wished to abort or ignore. I chose to ignore.
When the backup completed it informed me there had been 72 bad sectors. Not cool. If memory serves me right, I purchased a pair of these drives from Newegg (back when I still did business with Newegg) and the other one died when I was working on a contract at Leo Burnett. It didn’t die, it infuriated. Started developing bad sectors. Between two back to back runs of a surface analysis and bad sector mapping utility it developed another 64 bad sectors. So, time to conduct the experiment.
Booting my SystemRescueCD I started the desktop then, in the terminal window used
fdisk -l
to see how this boot identified the drives. After that I dug out the command everyone needs to have squirreled away in a text file.
sudo e2fsck -cfpv /dev/sda1
Why in a text file? Because you simply don’t have time to read the manual and identify which parameters you need. I didn’t need the sudo with the rescue CD because you are already running as root, but, you need it if you are booting from a “live” image. If you have some overriding desire to know what the switches mean, keep this in your text file with the command.
The parameters have the following meanings: “c” searches for bad blocks and adds them to the list, “f” forces a check on the file system, “p” repairs anything that can be safely repaired and “v” is verbose mode so you can see the command progress.
If your drive is of any significant size, kick this command off, go to a meeting, go to lunch, attend another meeting after lunch and then hope it is done. I didn’t time it, but it took a few hours to grind through the 1TB. Eventually I got a report which showed 31 bad sectors. The number did not match what Image for Linux reported, but there are a few things I do not know.
- When Image for Linux found the bad sectors did the S.M.A.R.T. drive already add them to the map?
- Did Image for Linux do anything about bad sector mapping to help me out?
- Just how intensely, if at all, does e2fsck scan empty space?
Here’s the trick. Most of you skip the next, and most important part. It doesn’t matter what OS you are running or who made your crummy machine, as soon as a bad sector mapping utility completes you have to run it again. Most of you, myself included during my younger days, will continue on just as happy as if you had good sense. Major mistake. Modern hard drives don’t politely fail. In the old days we got a nice screaming head crash and the drive would smoke (removable platter drives) and generally stop spinning. More recent drives seem to have either grease or glue which starts flaking off and skipping along the surface of the platter. The only way to identify this problem is to endure back to back bad sector runs. My second bad sector run completed hours later and showed 30 new bad blocks.
Now it really makes sense to test PCLinuxOS again. I’m going to have to shrink this partition down as small as possible to hopefully remove the number of bad sectors in the backup AND so I can potentially lay it down on a smaller drive. What __really__ sucks about ext4 is no backup software seems to have the ability to image a giant, barely used partition and let you restore it to a smaller, but more than large enough drive. I used to be able to do this with every other file system, even OS/2 stuff, but ext4 well and truly screwed the pooch here. Linux distros seem to be moving to this in droves and it is designed in such a way no backup software can really deal with it. Ext3 does not have this problem.
So, with SystemRescueCD still running, I started GParted and resized the partition to 4Gig. Yep. A bare bones KDE Neon with BOINC and a token few other packages can fit in 4Gig and still have free space. Once a new backup was made, the drive was tossed into my electronics recycling pile.
Took two tries installing a new drive. No, I haven’t forgotten how to do it. I sorted through my shelf of “spare” drives and grabbed the smallest SATA. I couldn’t remember where that 160Gig drive came from. After I installed it I had to take it out and finally put a sticky on it. The drive originally came in this HP 8300 Elite and it has some form of Windows on it. Keeping the drive around until I run into the last company on planet Earth still using Windows AND they happen to be willing to pay what it costs for real talent.
Second drive had a sticky. It came out of an AMD Quad-core I no longer own which used to run Mint 17 which is what booted up. I then booted from SystemRescueCD and waited for it to tell me there were no new bad blocks on this 250Gig drive. I then booted from my PCLinuxOS disk. When I first tried this distro a few weeks ago the “live” disk couldn’t find my LS-120 and I got a fatal error at the very end of the install. Now that I know I had an intermittently failing IDE cable and errors cropping up on the hard drive, I felt the distro deserved another shot. Besides, I had the best backup I could of the KDE Neon image which had been running there, but, the backup was going to be “iffy” because mapping out bad sectors doesn’t restore what used to be at that sector.
There was great joy and happiness when the “live” disk found my LS-120, mounted the SuperFloppy I put in and allowed me to copy a file to it. So, I clicked on the install and made selections, answered the typical install questions, told the install to wipe and use the entire drive, then waited. Eventually, right at the end of the installation process I saw what I feared.
The "draklive-install" program has crashed with the following error: open2: exec of /mnt/install/bin/grub2-mkpasswd-pbkdf2 failed at /usr/lib/libDrakX/bootloader.pm line 1827. ...propagated at /usr/lib/libDrakX/any.pm line 267. Perl's trace: drakbug::bug_handler() called from /usr/lib/libDrakX/any.pm:267 any::installBootloader() called from /usr/lib/libDrakX/any.pm:237 any::setupBootloaderUntilInstalled() called from /usr/sbin/draklive-install:340 main::setup_bootloader() called from /usr/sbin/draklive-install:71 main::install_live() called from /usr/sbin/draklive-install:43 Used theme: Breeze Please report this to the PCLinuxOS forum.
Adding insult to injury, during this process, my favorite mouse (my Logitech LX3)started to bite the big one. Hard to know at first. Just seemed like bad Web connections and randomly busy computer when clicks started to fail intermittently. Then, on the final day it was every other click. Soon, about one in three clicks worked.
Part of my mind was beginning to wonder if the most energetic and incompetent hacker had managed to get a logger on my machine. I mean, you’ve all heard about keystroke loggers. Those work well when it comes to penetrating the machines of people who don’t do much. But, other than for software testing a single application, what would a mouse logger be good for? you would have to have a full snapshot of the running machine at each click to know which application was currently in the foreground and where the mouse clicked in the app. At least when my rational mind took over, that was what I deduced.
So, rummaging through the shelf of “spares” I brought out the best of a bad situation, some little half-mouse which disappears under my hand and weighs something like .02 ounces. When I plugged it in it had no clicking problems.
Sigh… That LX3 had just the right weight and was just the right size. Guess what? Logitech doesn’t make the thing anymore. Just a few scammers trying to sell used ones as “new” for $127 or more dollars.
Sigh…losing your favorite mouse is like losing a dear friend.
On the amusing side though, any yutz putting a key logger on this machine would be getting 10,000 words worth of keystrokes the days I’m really in the zone. I gotta wonder if their code wouldn’t have:
char keyStrokeBuff [2048];
Oh well. The forum appears to have an answer for this issue.
https://www.pclinuxos.com/forum/index.php/topic,144350.0.html
In a week or two, when the current crop of BOINC work units have cleared out of the machine, I will go through this again.
I feel your pain. Back in the summer of 2012 I was getting SMART messages from my primary Windows-7 box. I ordered the drive and had it sitting on my desk then got side tracked for about 6-weeks on a big project with my employer. Needless to say, the drive totally-failed which caused me to install a new copy of Windows-7 on the new drive just so I could boot. I tried to retrieve the data from the old drive but it appeared totally pooched. That’s when I remembered someone telling me about the cooling trick. I unplugged the drive then stuck it in the beer fridge for a few hours then plugged it back in (SATA cable hanging out the side). Presto: I was able to mount the drive then start dragging and dropping folders from from old to new. About a 200 MB into the this the process the transfers started to slow down. So I grabbed two bags of frozen corn from the fridge then stuck the drive between them like a little ice-cream sandwich.