Part 1 of this series dealt with how to rescue a failing hard drive by copying files to a second local hard drive. Carla Schroder walks through network rescues, Windows machine rescues, and fixing the MBR in the final part of the System Rescue series.
In part 1 of this series
we learned how to rescue a failing hard drive by copying files to a second local hard drive. You can also copy files over the network, which is useful for nearly any problem, whether it's software or hardware. You need a second PC running sshd
. Suppose the second PC is named filestore
. Boot SystemRescueCD on the sick computer, then use the scp
command to copy your important files:
% scp -pr /home alrac@filestore:rescuedfiles/
preserves modification times, access times, and modes. This only makes sense on Linux file systems. -r
, or copy all the contents of a directory.
SystemRescue CD even rescues Windows, both FAT filesystems and NTFS. There is a bit of misinformation about NTFS support in Linux being unsafe, but thanks to NTFS-3G Linux supports both reading and writing to NTFS safely.
If all you want to do is copy files from an NTFS partition, go ahead and mount the partition read-only:
% mkdir /mnt/ntfs
% mount -t ntfs /dev/sda2 /mnt/ntfs -o ro
Using your own device name, of course, which you can find with fdisk -l
. ls /mnt/ntfs
then displays your Windows files. Then you can copy the files to an existing Samba share. If you need to find your Samba shares, use smbtree
% smbtree -N
\\XENA anonymous file server
\\XENA\IPC$ IPC Service (anonymous file server)
\\XENA\common_share anonymous share for all users
means don't ask for a password. If you need a password don't use -N
. This example shows a single Samba server with a single file share, common_share
, in the workgroup GROUP1, on host Xena. Next, mount this share on your SystemRescueCD computer, and mind your slashes:
% mkdir /mnt/commonshare
% mount.cifs //xena/common_share /mnt/commonshare
% cd /mnt/commonshare
Now you can copy files back and forth with the cp
command. If you have enough disk space on your Samba server you can grab the entire Documents and Settings folder, which holds the data files of all the local Windows users:
% cp -r /mnt/ntfs/Documents and Settings/ .
The trailing dot is a shortcut for "current working directory". The easy way is to use tab-completion, so after typing "Doc" hit the tab key and it will auto-complete the file name. It will also enter backslashes, so it looks like this:
/mnt/ntfs/Documents\ and\ Settings/
If you want to edit some Windows files, then you need to use the NTFS-3G driver:
% ntfs-3g /dev/sda2 /mnt/ntfs
Then you have several text editors to choose from: vim, Joe, nano, qemacs, and zile for the console, and Leafpad and Gvim for WindowMaker. It also includes a hex editor, hexedit.
When you run a multiboot system, sooner or later you're going to hork the MBR (master boot record). Windows lusers reformat and reinstall; ace Linux gurus perform skilled micro-surgery. If Windows takes over the MBR when you don't want it to, or a new Linux installations steals the MBR, boot SystemRescueCD and fix it this way:
First zero out the MBR, and preserve the partition table:
% dd if=/dev/zero of=/dev/hda bs=446 count=1
The MBR is 512 bytes, and the first 446 contain the boot records. The remaining 66 bytes contain your partition table, so you don't want to erase that. (If you're thinking wow, this seems rather quaint and archaic, you are correct. The x86 architecture still thinks it's running MS-DOS. And that is why modern operating systems contain so many kludges just to boot successfully.)
It's usually not necessary to do this when Linux controls the MBR, but it doesn't hurt anything and it's good to know how to do it. If you want Windows to control the MBR, then you do need to zero it out before installing Windows, or before running any Windows boot fixit tools.
OK then, enough of that dull Windows stuff. Let's get back to nice sane Linux and open the GRUB command console:
Probing devices to guess BIOS drives. This may take a long time.
[snip boring stuff]
Now find GRUB's stage1 loader:
grub> find /boot/grub/stage1
If there is more than one, which there often is on a multiboot system, you need to know which one you want to use. (If you pick the wrong one, just boot SystemRescueCD and do it over.) Now enter the root partition:
grub> root (hd0,3)
Filesystem type is ext2fs, partition type 0x83
Then run GRUB's setup command:
grub> setup (hd0)
Checking if "/boot/grub/stage1" exists...yes
Checking if "/boot/grub/stage2" exists...yes
Checking if "/boot/grub/e2fs_stage1_5" exists...yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 15 sectors are embedded.
Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,3)/boot/grub/stage2
When you reboot you'll be welcomed by your familiar GRUB menu.
In these two parts we've just scratched the surface of what you can do with SystemRescueCD. You can also rescue RAID and LVM volumes, do secure erasures, snarf up Windows passwords and edit the Registry, edit any Linux/Unix file, run benchmarks, burn in new systems, run virus scans, extract Windows CAB files, create and unpack compressed archives, and lots more. If you're not happy with the stock package selection, visit the Howto page to learn how to create your own customized rescue CD.
Carla Schroder is the author of the Linux Cookbook and the newly-released Linux Networking Cookbook, and is a regular contributor to LinuxPlanet.
This article was first published on LinuxPlanet.com.