[News]

News

[Stats]

Stats

1. SMART failure. The drive firmware itself reports it is bad. This can be detected with Linux tools (none that I am aware of are included in Damn Small Linux). Unfortunately, older drives don't support SMART.

You may want to check out the Ultimate Boot CD (http://www.ultimatebootcd.com/), it has a good assortment of disk diagnostics, several of which do read SMART data, and others that can do other things. Also includes some of the manufacturer's diags too. And yes, DOS-like shells to look around at the disk contents if it is healthy enough to support that.

2. Bad sectors. If SMART doesn't exist or isn't enabled on the drive, these can often only be found during a full format or read/write surface scan. You could test a hard drive that you don't have data on by doing

Code:

dd if=/dev/random of=/dev/hdX bs=512k

but may take awhile. A fast computer/drive should be able to do about 2 GB a minute; I wouldn't even want to guess how it'd do on a 486.

If you are trying to identify bad sectors you probably want bs=512 without the "k" here, add a "count=2M" for each GB of drive size... but still expect it to be slow.

You could get it to run substantially faster by substituting /dev/zero (alternately prepare a small file to use repeatedly instead) for /dev/random... the constant takes minimal compute cycles, while "random" is a fairly compute intensive algorithm, bad enough on a Pentium but would be really horrendous on a 486.

After that, the time needed depends somewhat on the chipset/bios and what transfer modes are supported. On my 486DX50 (bios limits it to mode 2) it took 50.3 hours to zero a 80GB drive... that's somewhat less than 2GB/hour, nevermind per minute. Also note that DSL seems limited to 32GB and could not do the entire drive, I had to use ttylinux, see my other post. It might be worth some googling to find a distro that includes ddrescue, it has special options for dealing with damaged drives.

3. Electrical failure / bad firmware. Since the drive won't be detectable, there's no way for Linux to detect that it is bad.

Depending on the make/model of drive and what its problem is, sometimes the manufacturer's diagnostic can do some testing even when BIOS can't see it, this can be worth a try. Check their website for details or try UBCD.

I recently tried out the DSL 0.4.11RC2 (as a liveCD, not any HD or USB install) on a VERY old (as in, it has reached the legal drinking age...) desktop and was shocked to see it actually load X , quite impressive considering the limits of this old box ! I have however found a few issues as well.

The box in question has the old-school 486DX50 processor, from the time before the clock-doubled variety became more common. RAM started out at 8MB but has since been maxed out at 32MB on the mobo; there is a slot for expansion to 64MB but that would require a proprietary and undocumented card only produced by the mobo company that folded more than 20 years ago and I have never been able to find it. The mobo is a combo VLB (Vesa Local Bus) and ISA rig, 3 slots of VLB and 4 of ISA. One VLB slot has the IDE controller (dual channels). The video card in an ISA slot is one of the infamous Diamond cards, don't remember the exact model number right this minute but it does do 1280x1024, I think at 24bit color, in Win3.1. There is no PS2 port available, so the keyboard has the old style largish AT connector, and the mouse (a 3 button type, I think it takes the Mouse Systems driver in W3.1) is on serial COM1. And of course no SDcard reader, no WiFi, no SATA ports, no USB ports of any flavor, no FireWire, no AGP, no network card, no internal modem, no PCMCIA, indeed not even PCI slots and it predates PlugNPlay. There is a Teac 6x IDE CDROM (one of the older ones that were read-only, not burners, and CD-only, not DVD).

Normally it has 2 IDE hard drives, the original 210MB (remember when that much space was considered very generous?) with DOS 6.22/Win3.1 installed, and later I added a 6.4GB drive (and when this was unimaginably humongous?) partitioned 3 ways - one partition is a backup mirror of the DOS/Win3.1 install, one left mostly empty for data storage, and the third set up for dual booting Linux Slackware 2.3. However for the task at hand these two drives are temporarily removed.

BIOS does not support booting from CDROM, there is no network card, and the installed hard drives are removed so I have to use a floppy bootdisk (didn't see one in the RC2 so had to borrow the image from older 0.4.4 - hoped this would not cause any issues, it seems to have worked).

Speaking of BIOS, that is the reason I picked this geriatric machine for the task at hand.... malware cleanup. I wanted a safe place to run dd and zerofill a 80GB hard drive (out of a 2005 vintage IDE based laptop) without risk of infecting the cleaning machine. I had started out using a Debian liveCD with the HD in the original infected laptop but soon found out this particular malware will implant itself into BIOS. Simply zeroing the drive is NOT enough . Even if the BIOS is reflashed afterward, if the drive is still present the malware may return. These parts must be cleaned separately before putting them back together! And that is the attraction of this old hardware... it is so old it does not support BIOS flashing (this old beast has a ROM chip - changing BIOS requires REPLACING THE CHIP ) and does not have any network card/wireless option ROM so the malware can't go there!

The X desktop is some weird ugly colors that don't have very good contrast or visibility - like dark olive drab text on a deep navy blue menu that is VERY hard to read. It doesn't seem likely that anyone would have chosen these as standard colors; I'm assuming it doesn't quite understand the graphics card settings with the default boot parameters. So I thought I would try to adjust some of the settings.

After a brief amount of poking around the desktop to see what is there I was soon unable to select menu items with the mouse. The cursor still moved around the screen and items could be highlighted, and I got a "clicking" sound, but no action. After leaving the desktop environment I saw a bunch of messages about "respawning too fast, disabled for 5 minutes" and also "no more processes at this runlevel" or something like that . Could not do a proper shutdown at that point so ended up just powering off. Given the nature of my application, I could not allow it any swap space. I figured it had run out of available RAM so I tried to lighten the load.

Oh yeah, before I forget - while booting there was a point when it gave an error message something like "invalid mode" - after some tinkering I found the screen where it would list some video modes and want a number entered. The thing I eventually found workable was to enter "scan" instead of a mode number, this gave some choices that were not on the original list. I ended up using either "9" or "b".

After some research I found the cheatcodes I wanted:
   dsl 2 fromcd dma nopcmcia nousb noagp base noideraid noapm noapic nomce nosound nofirewire nodhcp nosmp
This allowed me to work awhile in textmode without the "no more processes at this runlevel" problem. After poking around to find proper device names for the HD I typed
   dd if=/dev/zero of=/dev/sdc bs=512 count=80M
and waited a long time. After more than 17 hours (but less than 20 hours) I saw that it had simply returned to the command prompt without printing any exit status , also no error messages.

Given the earlier problem of not enough RAM (?) for X, and especially the nature of my task, I was a bit paranoid about this unexpected behavior. Not the time (actually finishing turns out to take somewhat longer than that) but lack of the usual status output. I thought I remembered from poking around a bit with dd using count=1 instead as a test to be sure I had the right device name, it did seem to produce status lines (if the device names were right) that way but not for my big run - or is that just my goofy memory? I surfed around to find that the busybox sourcecode for dd should have printed some status lines on completion so something has indeed gone wrong. I suspect it may actually be a problem with the older 2.4 kernel, and dd calling kernel code that rolls over and dies at a 32GB boundary. This can be a MAJOR issue if anyone else is trying to use DSL for malware cleanup so I thought I should post here to make everyone aware of the limitation.

There was a liveCD of Debian Squeeze lying about that I tried but it would not boot... it gets to the point of "Loading kernel..." and then just hangs, it probably needs the full 64MB RAM they say is required even to boot text mode, but that I don't have. It does work in more modern rigs, just not my target box. (Also on newer systems it does print those status lines at the end of dd that have gone missing from DSL).

A couple more days of research on other liveCDs that might be suitable for my task turned up http://ttylinux.net/dloadPC-i486.html which I downloaded and burned to CD. I wasn't sure the DSL bootfloppy would be compatible so ended up using SmartBootManager (http://btmgr.sourceforge.net/download.html) for that purpose, it did nicely in case you ever drop the bootfloppies from your distro and need to recommend a substitute.

ttylinux ends up with the same device names as used in DSL, (for some reason Debian insists that the proper name is /dev/sda, not sure why it wants to be different on this) so I used the same dd command.

Waited a (very long!) while, and it finished after 50.33 hours and does indeed produce the expected status lines even on my old target box . It also uses the busybox code so I think the difference is that ttylinux is using the 2.6.34.6 kernel (Debian Squeeze seems to be 2.6.32) rather than the older 2.4.31 in DSL.

If I assume write speeds were similar between DSL and ttylinux, then 20 hours would scale to about 32GB when it stopped, interesting since this was one of the older "stop points" in terms of disk drive sizes being supported in BIOS and other places. Definitely a small limit for drives today.

I guess this is all a rather longwinded way of saying I hope you consider upgrading to a 2.6 type kernel for your next release. Since the ttylinux download is only 13MB the kernel obviously CAN be made small with careful module selection that is still suitable for older hardware (granted you are including X where ttylinux does not, but still...). But if it REALLY won't fit your size limit for DSL, then at least for the DSL-N variant. Is saving that last 2MB really so critical considering the functionality tradeoff? Because not being able to zerofill even less than 80GB - which is a very small drive by modern standards - would seem like a major limitation for tasks like malware cleanup, or sanitizing private data, etc. Just thought y'all should know.