No. of Recommendations: 6
My laptop hard drive started to malfunction when I was at a trade show in Vegas a couple weeks ago. I had to use the command line to patch things up enough to keep going, and I had to give my presentation with a visibly malfunctioning system. Such fun.

When I got home I ran diagnostics on the system and concluded that the HD was going out - the bad blocks list was starting to grow quite quickly.

Now, this system isn't important; reloading it is no big deal since I keep nothing original or important on it. Nonetheless, the time to reload packages and service packs and so forth is time I would rather not spend. Also, the Win XP install information is a hidden partition on the HD. I have it backed up, but still losing it could prove a big problem.

So, I decided to image the HD, then load the image on the new HD.

I can't use Ghost for this because I was going to image the HD to a Linux partition on a different machine (DADSBOX) and Ghost doesn't support this. Also, Ghost has rather limited capabilities when you are using a network, requiring both the source and the destination machines to be booted into DOS. Naturally, since this is a laptop, I can't have both drives plugged into the laptop, and plugging both drives into another computer requires reconfiguring another computer, which is (to say the least) a nuisance.

So, I decided to do it with Knoppix, running Knoppix on the laptop and connecting with my Linux machine (could as easily have been a Windows machine) to shove the data across the LAN to the intended destination.

So I loaded Knoppix on the laptop, opened a console window on the laptop, changed to root, and created a mount point on the laptop for the space on DADSBOX that I wanted to access:

mkdir /mnt/space

Then I mounted the share on DADSBOX (which is shared through SAMBA with the name "Share", but if this had been a Windows box could have been my C drive, or E drive, or whatever):

smbmount //dadsbox/space /mnt/space -o username=jiml,password=mypassword

Then I imaged the drive from the laptop to Space on DADSBOX. As I did it, I broke it up into 100 meg files rather than try to have one big 30 Gig file on DADSBOX:

dd if=/dev/hda | split -b 100000000 - /mnt/space/LTRecover.
img.

This didn't work because of bad blocks on the old HD; when it hit the first bad block there would be a read error and the transfer would stop. So I reran it with the flag set that continues even with a read error:

dd conv=noerror if=/dev/hda | split -b 100000000 - /mnt/space/LTRecover.
img.

So, this command ran for about 4 hours and moved 30 gigs to the partition Space on DADSBOX.

I then swapped the hard drive, reloaded Knoppix, opened a console window, changed to root, created the mount point, mounted Space on DADSBOX, and imaged the entire thing back to the new hard drive, reassembling the files as I went:

cat /mnt/space/LTRecover.img.* | dd of=/dev/hda

I then booted the laptop into Windows XP to make sure it worked. It did work. I scheduled a complete surface scan using chkdsk to correct all the errors that have to be there, and as I write this that run is underway. There are lots of errors, but this doesn't surprise me because the old HD was going down quickly. I expect chkdsk will recover almost all the data without incident, and as I have said, there is nothing really critical here anyway; everything that matters is stored someplace else.

Now, the hidden partition that contains the system install/recovery stuff did fail to restore properly; the partition boot sector is badly corrupted, so I just reformatted that partition and when Chkdsk is done I will simply load the backup copy onto the partition.

In any case, this proved to be a pretty straightforward operation that demonstrated a capability that otherwise would have been painful, which is why I posted it here.
Print the post Back To Top
No. of Recommendations: 0
That is great! I was wondering, however why you didn't use partimage? Could have saved you a little work. Might also have been faster because it would have compressed the image before transfer (transfer less data).

-Matt
Print the post Back To Top
No. of Recommendations: 1
That is great! I was wondering, however why you didn't use partimage?

Three reasons. First, familiarity. I have dd and I use it routinely, so why not. The time isn't an issue; I start the transfer running then go do something else.

Second, I wasn't imaging partitions, I was imaging the entire drive.

Finally, partimage isn't too good on NTFS file systems.
Print the post Back To Top
No. of Recommendations: 0
Hmm... I understood about half of what you said, but it sounded really good. :)

Glad it worked.

Lady I, hasn't learned her Linux speak yet.
Print the post Back To Top
No. of Recommendations: 0

Lady I, hasn't learned her Linux speak yet.

That is why I gave a command by command layout of how I did it. Following the commands, with changes appropriate for the particular installation, will let anyone do it.
Print the post Back To Top
No. of Recommendations: 0
Of course I'm OORFTDAlready, but I had to say thanks for the post!! I might swipe this later to add to my web site.

ßillƒ
Print the post Back To Top
No. of Recommendations: 1
I might swipe this later to add to my web site.

If you do, attribute it and please correct the typo.

Exercise for the student: What typo?
Print the post Back To Top
No. of Recommendations: 1
Hey Jim,

If you do, attribute it...

Always!

...and please correct the typo.

*riiiight*

Hopefully you mean this one?

...everything that matters is stored someplace else.

...everything that matters are stored someplace else.

The only other thing I could see that "looked" suspect to me, even though I don't know anything about Linux, is;

cat /mnt/space/LTRecover.img.*

Does the ".*" after "LTRecover.img" mean to copy and assemble everything in the ".img" folder (or the "LTRecover.img" folder.)?

ßillƒ

P.S. I figured you'd e-mail me and say Yea or Nay. And if it was Yea, I would ask then if you would look it over for any corrections you'd want made before I swiped it. :-)
Print the post Back To Top
No. of Recommendations: 1
*riiiight*

Hopefully you mean this one?

...everything that matters is stored someplace else.


nope.

The only other thing I could see that "looked" suspect to me, even though I don't know anything about Linux, is;

cat /mnt/space/LTRecover.img.*

Does the ".*" after "LTRecover.img" mean to copy and assemble everything in the ".img" folder (or the "LTRecover.img" folder.)?


It means to concatenate every file that starts with "LTRecover.img.". The split command (which was used when copying the data from the dying HD to its storage place) generated 100 MB files that started with suffix aa, then ab, then ac, then...etc. So I have a total of 301 files starting with the name LTRecover.img.aa and proceeding from there.

Actually, there are two typos of significance. One is this (which occurs in two places for reasons mysterious to me - something to do with the copy/paste I did of the command line:

The text says:

dd if=/dev/hda | split -b 100000000 - /mnt/space/LTRecover.
img.


when it should say:

dd if=/dev/hda | split -b 100000000 - /mnt/space/LTRecover.img.

The biggie, though, is here:

I wrote:

Then I mounted the share on DADSBOX (which is shared through SAMBA with the name "Share"

when I should have written:

Then I mounted the share on DADSBOX (which is shared through SAMBA with the name "Space".
Print the post Back To Top
No. of Recommendations: 0
Hey Jim,

Hopefully you mean this one?

...everything that matters is stored someplace else.


nope.

I know my Grammar rots, but I should also know better than to try and use Grammar Check when I don't know my Grammar. :-)

The text says:

dd if=/dev/hda | split -b 100000000 - /mnt/space/LTRecover.
img.

when it should say:

dd if=/dev/hda | split -b 100000000 - /mnt/space/LTRecover.img.


LOL, I saw that, but didn't figure it was worth mentioning as I figured it was a formatting issue, not a typo. I knew it should be all one line.

The biggie, though, is here:

I wrote:

Then I mounted the share on DADSBOX (which is shared through SAMBA with the name "Share"

when I should have written:

Then I mounted the share on DADSBOX (which is shared through SAMBA with the name "Space".


Figures! I tried reading and re-reading this line several times because something didn't "look" right, but I don't know SAMBA, let alone Linux, and couldn't "see" that mistake. I kept looking at the next line, "smbmount //dadsbox/space /mnt/space..." and wondered if the "smbmount" might be wrong, but just couldn't figure this one out.

Thanks for informing and educating me. Now, if I can just remember any of this at a later time...well, I guess that's why I wanna swipe your post, so I can remember it later. <bg>

ßillƒ
Print the post Back To Top
No. of Recommendations: 0
While on the subject of Knoppix:

Jim once wrote:

You can mirror a drive using Knoppix and the dd command. For example, if your original disk mounts as HDA and your intended destination disk mounts as HDB you would clone the whole thing by this command from Knoppix:

dd if=/dev/hda of=/dev/hdb


Would this command work with Linux 2K4 ?

~aj
Print the post Back To Top
No. of Recommendations: 0
Would this command work with Linux 2K4 ?

What is 2K4? Do you mean 2.4 ?

If so, then sure. The dd command is not part of the kernel and should not be affected by the kernel version.
Print the post Back To Top
No. of Recommendations: 0
Would this command work with Linux 2K4 ?

What is 2K4? Do you mean 2.4 ?

I wonder if he's talking about PCLinuxOS 2K4 that I have listed on my site?

http://www.williamaford.com/DiagnosticTools.php

http://www.pclinuxonline.com/pclos/index.html

ßillƒ
Print the post Back To Top
No. of Recommendations: 0
"I wonder if he's talking about PCLinuxOS 2K4 that I have listed on my site?"

That's the one. Will it work for that?

~aj
Print the post Back To Top
No. of Recommendations: 3
Figures! I tried reading and re-reading this line several times because something didn't "look" right, but I don't know SAMBA, let alone Linux, and couldn't "see" that mistake. I kept looking at the next line, "smbmount //dadsbox/space /mnt/space..." and wondered if the "smbmount" might be wrong, but just couldn't figure this one out.

Actually, the command sequence displays a capability of Linux that simply does not exist in Windows, and a person who has learned computers using Windows may have a bit of trouble grasping the concept. In fact, it points to the most serious design deficiency in Windows (other than security), one which Microsoft really should fix and I don't understand why they don't fix it.

In Windows, you refer to hard drive partitions by a drive letter; C:\, D:\, etc up to Z:\. The drive letter refers to a physical location on a physical device. Software packages therefore must refer to the same physical device, to identify their own locations and the locations of data.

Because the software is referring directly to a hardware device, it is very difficult to move that software package because when you do all of the references to location break. This, as every Windows owner knows, is why you usually just reinstall the package if you want to move it to a different location in the system. This is clumsy, archaic, crude, and primitive.

Linux (and Unix, and OSX, and every other OS in the world) uses a concept that is referred to variously as "virtual device" or "mountpoint". A closely related and similar concept is the "symbolic link". Basically, you define a location or a label (how it works varies from OS to OS - in Linux you define a location - a directory to be exact) and that label points to the physical device. All software points to the label. Then, if you want to move something, you move it and just change what the label points to, thus updating all physical location references.

In Linux, physical devices all have references that are found in the /dev/ directory. So, for instance, the first hard drive (hda if IDE, sda if SCSI) will be identified to the system as /dev/hda (or /dev/sda). This is an absolute reference to a physical device. The first partition on drive hda will be called hda1. Thus, typically, /dev/hda1 would correspond to C:\ on a Windows system.

By convention, in Linux, there is another directory called /mnt/ and it is in this directory that all system level mountpoints are kept. The mountpoint is the location that all software will use when referring to a physical hard drive partition.

Thus, knoppix will create a directory /mnt and will place in it a directory called hda1, and you will refer to this as /mnt/hda1. You need to link /mnt/hda1 to the physical drive /dev/hda1 and you typically will do this with the mount command. Actually, Knoppix will handle it for you, but Knoppix does it using the mount command.

Then, all software will refer to /mnt/hda1 and the system will translate this to /dev/hda1. I might create a mountpoint in /mnt called - say - BusinessDatabase and then mount the partition that contains my business database so that I would always refer to my business database by accessing /mnt/BusinessDatabase. Thus you could see that I could easily change where /mnt/BusinessDatabase pointed if I reorganized the system and moved the database to another hard drive and a bigger partition.

This is enormously more flexible than what Windows does, and yet Windows could implement it in a fashion that is transparent to the user and the software; it would only show up when it came time to move things around.

Now, in the particular series of commands I depicted in this thread. I first created a mountpoint called space in /mnt - thus creating the reference /mnt/space.

Then, I mounted a partition on another computer using a mechanism that is compatible with Windows networking. This mechanism is called SAMBA, which is a package for other operating systems (I have installed it in Unix, AmigaDOS, Atari, BeOS, and of course Linux) that implements the Windows SMB networking system.

I mount that partition with the smbmount command (which is, effectively, "mount an SMB share"), and as it happens that share was a linux share that was being shared using SAMBA on the other computer. The name of the share was "Space" which is just how I choose to have people on my home LAN see it when they wish to access my system remotely. Since I was already sharing it using the Windows mechanism so that the Windows systems on the LAN could access it, it just was simplest to mount it using the Windows mechanism even though both machines were Linux.

Anyway, this is what the smbmount command did. The command said "take the network share named Space and located on Dadsbox, and map it to the local directory /mnt/space using the username jiml with the appropriate password". This made it effectively a local file space, exactly as it would be in Windows if you did a "map network drive".

On a linux system that was genuinely installed, rather than running from a CDROM, the installation would make it easy enough to do a "map network drive" pretty much the same way you do it in Windows, but making this work was inconvenient using knoppix because Knoppix is just a "guest". Rather than configure Knoppix so that is was more comfortably resident on the system and the LAN, it was just easier and quicker to use the command line.

So, having then done a "Map network drive" to make the remote share local, I copied the contents of the hard drive by referring directly to the hardware (/dev/hda) to the local mountpoint (/mnt/space) which caused the data to be shipped across the LAN to the location on DADSBOX.

Actually, technically, I ordered the dd command to extract data from /dev/hda and to ship that data directly (pipe it) to the split command, and I told the split command to chop the file into 100 Meg chunks as it came in, then to save it as /mnt/space/LTRecover.img.xx where xx is a suffix defined by the split command. The command showing the pipe is the vertical line symbol |.

Then, bringing the data back to the new hard drive, I told the cat command to concatenate all these files and pipe the output directly to the dd command, which was told to write the data directly to the hard drive /dev/hda.

So, this command

dd if=/dev/hda | split -b 100000000 - /mnt/space/LTRecover.img.

exactly says:

"Read data from the device /dev/hda starting at the beginning and going to the end, and pipe that data directly to the split command. The split command will accept input from a pipe (this is what the - that is by itself just before the /mnt means), will break that data stream up into 100000000 byte chunks, and will then store them at the location /mnt/space with file names prefixed by LTRecover.img." (note the trailing period is significant and quite important).

Also, this command

cat /mnt/space/LTRecover.img.* | dd of=/dev/hda

exactly says:

"Concatenate all files found at /mnt/space and prefixed by LTRecover.img. in proper order and pipe the output directly to the dd command. The dd command will write that data stream to the physical hard drive /dev/hda starting at the beginning of the drive and proceeding to the end of the drive or until the data stream ends."

This concludes today's lesson in Linux.

:-)
Print the post Back To Top
No. of Recommendations: 1
That's the one. Will it work for that?

I would expect it to. I can't really envision a Linux distro that is intended to facilitate maintenance that wouldn't include the dd command.

dd is low-level and very powerful because it reads from and writes to hardware directly, completely ignoring file systems. It reads/writes directly to specified locations on a hard drive, which makes it useful for backing up master boot records and partition boot records, and makes it useful regardless of file system.

To fix a partition boot record, for instance, you use dd to write a copy of it off to a file, then edit the file with a hex editor to fix whatever is wrong, then copy the file back to the HD using dd.
Print the post Back To Top
Advertisement