Archive for July, 2006

Transferring data off that old MFM or RLL drive

Wednesday, July 26th, 2006

ST506 is an interface consisting of a 34-pin control cable and a 20-pin data cable. MFM drives are ST506 drives that formatted with 17 sectors per track and RLL drives are those formatted with 26 sectors per track. It is possible to format any RLL drive as MFM, and any MFM drive as RLL. A drive not certified for RLL formatting may lose data when formatted as RLL, however.

PC/XT and AT machines are different, and so are the controllers designed for each. A 16-bit controller (i.e. designed for an AT) usually does not have its own BIOS, because the AT BIOS has built in INT13 support for hard disks. (Many AT compatible BIOSes have a built in surface scan and low level format routines.) 16-bit BIOSless ST506 controllers should be interchangeable with a given drive. There are a few exceptions where a particular controller will write the formatting information in an incompatible fashion (example: WD1006V-SR1).

However, in general no controller with an onboard BIOS is interchangeable with any other controller with an onboard BIOS. Since PC/XT machines have no INT13 BIOS, 8-bit cards designed for use with a PC/XT will always have an onboard BIOS that is required to low-level format the disk, making it imperative that any drive that originated in a PC/XT be matched with the controller that low-level formatted it in order to be able to read the data on the drive. The same goes for the limited number of 16-bit controllers that had an onboard BIOS with a low-level format utility. If a drive is formatted with a standard AT BIOS, however, any other standard AT BIOS should be able to read the low-level format.

Here is a book with a fascinating chapter detailing low-level formats and other little-known facts about older drive technology.

(If you wish to have an arsenal of controllers for attempting to deal with bare MFM/RLL drives formatted with XT controllers, start with a DTC 5150(X/CX) and WD1002-WX1 MFM controllers, and a WD1002(A)-27X RLL controller. From there, ST11M/R, WDXT-GEN series, DTC 5160 series, WD1002(A)-WX2, WD1004(A)-27X, OMTI 552x series, Adaptec ACB-2010 and ACB2072 series,and XEBEC 1210/1220 are other common XT controllers.)

When you have a controller/drive combination that has its own BIOS, you don’t have to worry about the drive types defined in the AT BIOS. Those are only used by the INT13 interface built into the BIOS. When a controller BIOS is invoked at boot, it installs its own INT13 routines, making the built in INT13 routines irrelevant.

In the case of a 16-bit BIOSless controller, however, it is necessary to know the C/H/S geometry of the drive in order for it to be used. If the battery in the system has died, you can try to guess the parameters by trying all the built in types (all besides type 47) that have a formatted size equivalent to the drive’s size. For example, a ST-251 40MB MFM drive is usually formatted as 860/6/17, which corresponds to Type 40.

If guessing all the built in types doesn’t work, it is probably a user defined type which will be impossible to guess. To rescue the parameters, you can run the Spinrite utility and near the beginning of the operation it will tell you that the CMOS geometry does not match the formatted geometry, and it will tell you the formatted geometry. You can then enter this geometry as a user defined type, and the drive should then be accessible.

Sometimes drives will be accessible but impossible to boot from for various reasons. Just because you cannot boot from a drive does not mean that you should not boot from a floppy and attempt to access drive C:.

Cabling is important to check. Have a few sets of cables around. The cables may have rotted and will cause behavior like DOS “not ready” errors and intermittent operation.

Usually you would disable the floppy controller on the ST506 controller board so as not to conflict with the floppy controller already in the system. However, some ST506 controllers have built in floppy controllers that cannot be disabled. In this case, you’ll have to hook up the floppy drive to the ST506 controller and disable the system floppy controller. If the controller is an older model, you should verify that it supports the type of floppy drive you are connecting to it (most will support standard 1.44MB drives though). The system BIOS must also support the floppy drive type that is connected.

It is usually difficult to put a ST506 drive and controller in the same system as a modern IDE drive, due to BIOS issues. Also, depending on the system, the ST506 controller may not even work due to incompatibility with the system BIOS and timing issues (disabling internal and external caches and maxing out I/O wait states may help). Also, the BIOS in a modern system may simply hang when confronted with a particular drive or controller, making it impossible to use them in that system. So you will need another mechanism to transfer the files off the drive.

If the filesystem is readable, you can use a null modem / laplink program (such as INTERLNK, Laplink, Fastlynx, LPTransfer) to transfer the readable files to another computer. Or set up an IPX network using a packet driver or ODI, and use IPXFER or similar to transfer the files. Or use the backup/restore utilities that come with DOS to transfer the data via floppies. You could also use a parallel port zip drive with the associated DOS utilities (GUEST.EXE). Another option is use an ISA NE2000-compatible network card with jumpers for the I/O base address and IRQ, a NE2000 packet driver, WATTCP, and SSHDOS. (This may be all possible to fit on a single floppy disk.)

If the filesystem is unreadable (the C: drive exists, but errors occur when you attempt to obtain a directory listing), or if the files you are interested in cause errors like Sector not found or Data error when attempting to read them, Spinrite is the best program to salvage the data. Run Spinrite on Level 2 (Recover data), and it will do its best to recover and relocate the data so that the file can be accessed again.

If the MBR/FAT areas of the drive are unreadable, and Spinrite can’t recover the data stored on them, the prognosis is somewhat hopeless. The best you can do here is to take a raw image of the filesystem and transfer it elsewhere for analysis. Then the disk will need to be low level formatted to possibly be used again. Just because an old disk is unreadable doesn’t mean the disk itself is unfit for future use. The low level format on a MFM/RLL drive will drift with time if the recorded data is not refreshed on a regular basis (such as with Spinrite’s level 3 option). This is not a failure of the drive itself, but rather a maintenance failure.

The controller, if it has a BIOS, will usually have format and/or diagnostic routines in the BIOS that can be called by the user. To locate the BIOS, you can use a utility like Quarterdeck’s Manifest that will map the area between 640K and 1MB. Then you can use the DOS debug utility to dump any areas that Manifest reveals as option rom areas. The most common region where controller BIOSes would be mapped is in the C800-EFFFh region, at multiples of 400h. (The Video bios usually lives at C000h and the system BIOS at F000h). In Debug, just do:


- d c800

for the suspected area. You should see a 55 AA for the first two bytes, then if you continue to – d then you should see text that gives away the nature of the ROM in that area. If you don’t see 55 AA, or if you see all FF’s, there is no ROM that begins at that address.

Once you have located the controller BIOS’s base address, you will then want to use Debug to jump to the diagnostic routine. This is almost always located at offset 5. (The first two bytes are the option ROM ID bytes 55 AA, and the next two bytes are a JMP to the BIOS initialization routines; offset 3 is invoked by the system BIOS when it is scanning option ROMs.) So if your controller is at CC00, for example:


- g=cc00:5

For 16-bit controllers that do not have a BIOS, you can low-level format the disk using a utility like WDFMT, or the BIOS’s built in format utility. You should low level format the disk first, then perform a media analysis. You can do the low level format repeatedly if the media analysis continues to show too many bad sectors. (This may be necessary on drives which have been in storage for a long time.)

After you have formatted and allowed the media analysis to fill the defect list, and optionally entered by hand any manufacturer defects listed on the drive label, then you should fdisk and DOS-format the drive. When the DOS-format encounters a sector which has been marked bad by the low-level media analysis, the sector will be unreadable, so DOS will mark the whole cluster above it as bad. ST506 drives do not “hide” their low-level defects with an internal reallocation pool like modern drives do, so it is normal for a perfectly working ST506 drive to have several kilobytes worth of bad clusters.

The next thing you should do after low-leveling the drive is to run Spinrite at Level 5 (Restore good sectors) several times. If the results are stable after several runs, then the disk is ready for use. Remember to consider thermal issues as well as mounting issues (the drive should be screwed into the mounts and mounted in the same horizontal/vertical position that it will be used in) when deploying the drive.

8-Bit / XT IDE disks

These types of older disks use an 8-bit interface and are thus incompatible with typical IDE controllers (which use a 16-bit interface). Some of them can be jumpered either for 8-bit or 16-bit operation. If you take an IDE disk out of an older system for data recovery and it appears that the drive does not respond in a newer system, make sure that it is not set for 8-bit operation. (A tell-tale sign will be that it was hooked up to an IDE controller with an 8-bit edge connector.)

set_rtc_mmss: can't update from 9 to 54

Tuesday, July 11th, 2006

If you recently messed with your CMOS clock or had a dead battery, you might notice the NTP client spamming your console with these messages. The problem is that there is too much of a time difference between the CMOS time and the Linux time for the client to reasonably update the CMOS clock. (Perhaps your CMOS clock is not set to UTC.) Anyway, if you don't have any other annoying operating systems to worry about, just run /sbin/hwclock –systorc and they should be synced back up.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0012.2/0222.html

Debian apt-get and pdiff

Saturday, July 8th, 2006

Recently Debian's apt-get received a feature that many were awaiting; the ability to download incremental updates to the Packages file in a given repository. The files are downloaded as *.pdiff and applied one by one to the Packages file.

Unfortunately, the pdiff merging process is extremely slow on a lower-end computer. This behavior can be disabled by adding the following line to your local apt.conf (or placed into a file dropped into apt.conf.d):

Acquire::PDiffs “false”;

Suggestions for improving your Debian package

Saturday, July 1st, 2006

– Better pidfile management. Always check if the pid in the pidfile actually corresponds to a running process before exiting, otherwise the pidfile is falsely stale. Better yet, you could use /proc/self/cmdline to make sure the pidfile corresponds to a process image of the program you are actually interested in – some other program could have claimed the same pid. This is a rare case but makes things more robust. For compatibility, write the process cmdline on the next line of the pidfile.

– When checking that a user owns a file or directory, consider simply opening that file RW or touching a temporary file in the directory, instead of performing a UID or GID check. UID and GID checks do not take ACLs into account, which is an issue with most network filesystems as well as many modern local filesystems.

– Add a /usr/share/bug entry, especially if your package has conffiles and potential local modifications.

– Add an /etc/bash_completion.d entry, this is useful for all those bash users who live in a terminal window (i.e. that have a rodent allergy).

– Make sure you have a /usr/share/menu entry.