Apologies in advance, my responses and comments are in-line -- quotation is via the usual greater-than and greater-than-space-greater-than. However, this can be a complicated topic, so reading through all this stuff may be worth it (I hope so). On Fri, Sep 28, 2012 at 04:09:27AM -0700, Tony Baechler wrote: > I have to respectfully disagree with you on several of your points. I'm > writing from my own experiences having just replaced a bad drive and having > used Linux for many years now, both on a server and desktop system. Thanks for the respect; there's not enough of that going around now-a-days. And, disagreement and discussion/argument is something I welcome (as it's how intelligent people interact, as opposed to, say, violence...), and it's how people can learn from one another. As to longevity, I'll just say that my oldest linux system still running as of today was installed in December 1994. However, my experience with Linux is mostly server. > >2. A command everyone should know is: dmesg > > That command prints out all of your boot-up messages. The identity > > of drives will either be in lines beginning with "hda:" "hdb:" (etc.) > > for IDE drives, and lines containing "Vendor:" and/or "Model:" for > > scsi/sata drives. > Yes, dmesg is a good idea, but with any newer kernel, it doesn't use the > hda and hdb syntax at all. I've found that hdparm is more reliable and > gives more information. Yes. But I did state that "Vendor" and/or "Model" should appear. In any case, scanning "dmesg" output will almost certainly show the identity of attached drives, even if that info is not in as obvious a place as mentioned. In my experience, hdparm sometimes doesn't work, particularly so on drives that are not IDE/PATA (I have a couple of running systems, e.g. SuSE 10.0, installed early 2006, where hdparm doesn't work on my SCSI drives). Moreover, hdparm might not be installed, whereas dmesg will always be installed. dmesg provides low-level information from whatever the hardware reports, so I don't see why that information would ever be less accurate than hdparm (or sdparm). I agree that hdparm will certainly give much more information, and typically more useful, too. > >5. Make sure you get a replacement drive that is at least as large as your > > old drive. You should be able to clone your old drive completely to > > your > > new drive using ddrescue or dd-rescue; these cousin commands are based > > on > > "dd", but continue on in the face of errors, and use strategies like > > copying from the end towards the beginning, and in chunks, to > > absolutely > > maximize the amount of data copied. After doing that, your new drive > > will be exactly the same as your old drive (including the logical > > damage, > > which will at least no be afflicted with physical error problems), and > > you should be able to even boot both systems just as before. > > You can also fsck the new drive, as it won't get confused by > > hardware failures any more. > > While this is generally correct, you're making two wrong assumptions. > First, that doesn't work on all filesystems. Specifically, XFS doesn't use > fsck. The way to fix an XFS volume is with xfs_repair. The second problem I assumed that the OP was not using XFS (a poor choice unless you're mostly concerned with very large files), as that doesn't seem to be the default for his Arch distribution (inasmuch as Arch actually even has a default for anything). The "fsck" was suggested by the OP, by the way, not me. And, fsck.xfs shouldn't hurt anything, although it doesn't fix anything, either; since xfs is repaired on mount, the "fsck"-like repair would've autmatically fixed the damage (absent the physical disk problem), and so the fsck.xfs would just be a null operation; discussing fsck in the context of this problem wouldn't depend on whether xfs was in use or not. > is with Windows. I promise you that on Windows 2000 and up, and in > particular with XP, dd and similar won't work. For the Linux partition, Here again my experience is different. I have transplanted a Windows XP "Home" edition twice (from one computer/disk to another disk/same computer, to another disk/another computer) using only dd-rescue. > ddrescue is great and I would highly recommend it. I prefer it over dd > because it does rescue more files and gives a progress report while still > being fairly fast. On newer versions of Windows, it won't boot if you do a > straight dd copy. You have to change a registry entry first. I found this > out when I had an unbootable Windows system after doing a full copy. My experience does not match yours; i.e. "it worked for me". The opaqueness of Windows-based installation is a pox upon humanity. FWIW, my successes were all on Dell systems, and the only problem I encountered was the switch from PATA to SATA (due to a hiccupping SATA driver). > >6. Actually copying the drive could be tricky for you, depending on > > what hardware you have available. A USB drive converter is the least > > common denominator, but it's deathly slow. A separate "work space" > > system on your local network would be better. > > If you use Image for Linux or Windows, you can copy to a USB drive or via > the network. > > >7. For future reference, there are various partition cloning/backup > > systems for Linux that support Linux and Windows partitions, and are > > very fast (mostly because only blocks that are actually being used are > > copies, and blocks in the free list are not). > > OK, what are they? They aren't partimage or Clonezilla because I looked at > both of those. Clonezilla is very slow and requires booting from a live > CD. Partimage is similar. I didn't find any open source backup programs > that have as many features as Image for Windows or Image for Linux, are > completely accessible with screen readers, offer good compression, make > bootable restore DVDs, can copy to either internal drives, USB drives, DVDs > or over the network and offer a boot CD with Speakup already included. If > you know of any free backup software with that feature set and without a > lot of bugs, I'm very interested. Oh, and the Image suite gets updated > fairly often and frequently gains new features. Yes, I realize that it's > commercial, but I really haven't found a free alternative with the same > features and the same level of accessibility. I'll try to address all of your points, but firstly I will say that my perspective is that the OP will need sighted assistance; replacing the hard drive isn't something that a blind person can do by himself (yet). Therefore, booting from a live CD/USB shouldn't present too many issues, assuming a sighted helper. That's why my response didn't factor in screen reader accessibility as a critical requirement. Had the OP stated (or implied?) such a requirement, my response(s) would probably be a bit different. Moreover, in the case of a damaged drive, trying to carry out operations (copying, clone, etc.) on the same drive from which you are booted is something that should be avoided unless there are absolutely no other alternatives. Therefore, I assumed that the hard drive was going to by physically removed, and this cloning/recovery/backup/copy/whatever was going to take place on a completely separate machine (which adds a somewhat different set of additional questions), or that the failing machine was going to boot live CD/USB, with the new drive attached (somehow!) to the same machine, with the failing drive still in it (or, with the new drive installed inside the machine and the failing one taken out and somehow attached). I have nothing against commercial software, but the bug levels of such software are only slightly better than most widely-used free software, in my experience. Further, I usually advocate trying something free and likely reliable (cf. widely-used) first; the results may very well be satisfactory right away. Free software such as partclone gains new features similar to commercial software; again, my response was not to claim that your commercial solution was not better (for many scenarios I'm sure that it is, in fact, better), but simply that free software might just be good enough; the OP would also learn more about Linux in general, and not have to commit time to learning a particular piece of software for this one time and one purpose. I've used clonezilla "live" on occasions, and I found it to be no slower or faster than any other program. It just copies blocks off a drive, and there's not a whole lot of calculation that a slow laptop CPU or small-ish laptop memory to slow down the process. I do maintain that USB-anything is going to be slow, due to USB not being very efficient for bulk transfers. Clonezilla actually uses the "partclone" command (I think), which is a separately obtainable command-line (I think) program; it seems that "partimage" has stalled in development, and "partclone" may have taken up the mantle. Partimage claims to have speakup in some random branch as early as 2002, BTW. Since partclone appears to be command-line, then it can be used with any running system, so if that running system has speakup or screen reader, it can then be used as such. I also see that the fabulous system-rescue-CD has had speakup since late 2008. I don't understand why sysrescd includes both partimage and partclone, excepting perhaps for completeness' sake. sysrescd is probably the first tool to which I turn when I need to do a quick initial diag/repair of a dead or failing system. I haven't ever done anything like this, but it seems to me that sysrescd/partclone, with speakup and/or a sighted helper, would be a free and quick way to accomplish the OP's needs. If, upon cloning the disk this way, the new disk failed to boot (Windows and/or Linux), then there's little lost, and the OP could then try other possibilities, including your commercial software suggestion. The OP's choice of Arch Linux is interesting, as it suggests (to me) that he is willing to get under the hood and tinker. Running *any* CD/USB live distribution (vinux, or arch live, or no doubt a number of speakup-enabled live CD/USB's) would be enough to get the OP to a speakup command line, and from there utilize (possibly after additional downloads) various Linux tools, ranging from dumb (dd-rescue) to smart (partclone). Although I am not blind, I run almost exclusively in 25x80 command-line mode, and I've fixed/rescued innumerable systems in that mode. In short, if your impression is that my position that the commercial software suggestion is in any inferior, that's not what I meant, and that's not what I think. Rather, a Linux-specific solution consisting of free software was my suggestion as it usually is, in fact, good enough. In this particular case, since the OP was set on buying a new drive, there also would be no harm in trying various cloning scenarios to the new drive, with a quick test to see the results. As I stated, I've had success with just copying Windows (XP) systems with just dumb cloning/block-copying; my experience with Windows (as a long-ago Windows programmer) strongly suggests that such dumb copying stands a good chance of working (admittedly, there are innumerable reasons that it would not work, but there's not a guarantee of failure). P.S. there are many google hits on: "windows xp" clone disk OR drive "dd" Some report failure. But many report success. I believe that the most common failure modes are where the disk geometry is changed or the cloning is only for the Windows system Partition. However, in this case, the OP was contemplating replacing the drive with the exact same model (currently, used ones are going for $36, shipping included, on eBay). Moreover, since drives larger than about 20GB are usually LBA-addressed rather than CHS-addressed, the geometry (mostly) doesn't matter under Windows XP. Finally, since the cloning is for the entire hard drive, including the boot sectors and such, the chance of failure is further decreased (as opposed to cloning only a particular partition). -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York _______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/blinux-list