At least with the Anritsu MG3700A, trying to replace the hard drive is fraught with problems. I've wasted money buying all manner of flash drives, and it has mostly been a bust.
There is some sort of race condition in the portion of firmware that loads the waveform from the hard drive to its waveform RAM. If the data arrives from the hard drive too quickly, the (VxWorks-based) firmware locks up.
PATA is hard enough to find. CompactFlash seems to be one of the few remnants of the standard. Alas, nearly all the cards still in production tend to be too darn fast at transferring data.
I've acquired a supply of used conventional mechanical 2.5" PATA hard drives, and these work reliably without issue. However, these too will eventually die. I've heard of lubrication issues with even brand new hard drives that have been kept in storage, so that is something else to worry about.
One piece of good luck was that Anrtisu used a VxWorks-flavored FAT32 file system.
If one just wants to do a binary copy of two hard drives that have the exact same size (or to make an exact backup), dd is a straightforward option.
If cloning drives of different sizes and the file system is something like FAT or FAT32 or NTFS, I had very good success with using an old copy of Norton Ghost 8.3 (DOS-based) that I bought many years ago. Your mileage may vary.
The Ghost CD came with bootable floppy images and these could be used on a PC with IDE controllers. However, both of those (floppy drives and IDE ports) are not plentiful these days.
The open-source QEMU works wonders, though, and came to the rescue.
Here is an example command line syntax, where GHOST.IMG is an 2.88MB bootable floppy disk image and "src.bin" and "dest.bin" are images of the two emulated hard drives:
qemu-system-i386 -no-kvm -boot a -fda ~/GHOST.IMG -hda src.bin -hdb dest.bin
As might be suspected, "-boot a" indicates to boot from A: drive (fda). I found that I had to use "-no-kvm" on my Linux machine; your mileage may vary.
One can also use /dev/sdX arguments for the -hda and -hdb parameters to access drives directly, but then one has to run qemu as root to access those devices. (I'd welcome a solution where I didn't have to do that.)
What is great about the QEMU approach is that one can use USB-to-IDE adapters to mount drives and or CompactFlash cards. From the perspective of the software running on QEMU, it is just accessing another IDE drive.
In my experience, Norton Ghost did a great job of copying the filesystem and adjusting for differences in drive sizes (up or down). (In comparison, Clonezilla can't even copy to a destination drive smaller than the source.) Norton Ghost also kept partition volume information the same on the destination, preserving what VxWorks expected.
So, copying the hard drive was straightforward. Getting the replacement hard drive to work was not.
In buying different drives, it is not at all clear what the differences are between them.
What I found very helpful was the Linux utility "hdparm". Ideally, one wants the version that supports both of these command line arguments:
hdparm -I /dev/sdb
hdparm --Istdout /dev/sdb
The former outputs a human readable interpretation of the drive's response to the IDENTIFY DEVICE (ECh) ATAPI command. The latter outputs the raw 256 word data in hex form. (Some Linux LiveCDs use a limited version of hdparm that only supports the former. Presumably, all the relevant information is in the former, but I prefer the notion of having an exact bit-for-bit copy.)
Using hdparm with a USB-to-IDE adapter is NOT an option in my experience. The USB mass storage specification doesn't try to reproduce this functionality.
The two solutions I found that did work were:
1) Find an old computer/laptop with IDE ports. Plug the drive (with necessary adapters) into the computer. Boot off a Linux Live. Run hdparam and save the results to USB flash drive.
2) If dealing with a CompactFlash card, try using a Thinkpad X20-series laptop. These had a proper IDE-to-CompactFlash bridge and appear compatible with hdparm.
If you have test equipment with a hard drive AND you feel comfortable with being able to remove the drive without damaging the test equipment, the hard drive, or the warranty sticker, it seems worth considering:
a) making a sector-by-sector backup of the hard drive
b) using hdparm to make a copy of the IDENTIFY DEVICE table
That way, you *might* stand a fighting chance of being able to replace the hard drive.
However, in my experience, even though I had both (a) and (b), I still had no end of trouble coming up with a solution.
As mentioned in Part 1, there is a firmware bug in the Anritsu MG3700A where it will lock up if the data being read from the hard drive arrives too quickly.
Using the hdparm utility and trying many drives, I found that the factory-provided mechanical hard-drive supported Ultra-DMA modes. However, I have to presume that the seek times of the mechanical drive were enough to slow down the data. If I used a modern Ultra-DMA flash drive, it would cause the Anritsu firmware to lock up.
Through experimentation and hdparam, I found that low-end (and often past end-of-life) CompactFlash cards that ONLY supported PIO and Multi-DMA transfer modes seemed to be slow enough that they didn't trigger the Anritsu firmware bug.
The downside is that these low-end cards don't come in anything near the capacities of the original mechanical hard drive (40GB).
Home
Help
Search
Login
Register
