NOTE TO EVERYBODY WHO IS NOT ME: You can ignore this post. It's just random notes that I need somewhere safe. However, as of Dec 2006, it no longer applies, I use a modified version of SaraB.

Ghost really doesn't like my combo of SATA, IDE, LVM, and whatnot. To get the IDE (hdb) backup copied to the SATA (sda) I had to:
1. GHOST /FDSZ /IAL image /boot from hdb (Drive 4) to an image.
2. Put a partition on sdb (good thing it was empty)
3. Re-run ghost, copy image to sdb (not sda2 where it should be!)
4. Boot from CentOS install DVD with kernel command line:
linux rescue hdb=noprobe noexec=off noexec32=off
(took ~2 hours to find out the last two stop grub 0.95 from segfaulting on an install!)
5. mount up /dev/sda2 (destination) somewhere. Go into that directory and wipe it clean.
6. From that directory: dump -0 -f - /dev/sdb1 | restore -rf -
7. Relabel sdb1 so we don't have two /boot partitions!: tune2fs -Ljunk /dev/sdb1
8. unmount /dev/sda2
9. chroot /mnt/sysimage
10. grub --no-floppy
root (hd0,1)
setup (hd0) <== kept segfaulting here on SATA drive until noexec flags from above.
[Don't use grub-install that bombed too!]

OK, that's all the scraps of paper I can find. I really need to get a backup system running on this server before I migrate to it!

Yet more problems with Ghost… LVM crashes it with some nasty error about sectors that were in the negative billions. Anyway, tell it to just blindly copy Linux partition sectors (which sucks):

ghost /FDSZ /IAL

The Symantec 'knowledge base' has this ​this useless link.

The 'solution' is "Symantec is investigating this problem to determine a resolution. This document will be updated when new information or a solution is available." - They have said this since at least version 6 - search their site and see at least 4 different Ghost versions saying that they are looking into it!

My situation, and fix, hope it works for you… NAV Pro 2K4 had crashed a few days before (it only happened that once) and I never shut off my desktop. Well, what was happening was the dump file was spanning at the 2GB mark. NAV has hooks in the OS that do RPC calls when the file is closed, telling NAV to scan it. Since NAV wasn't running, the RPC call was timing out. By time the RPC call failed, the Ghost client had given up the ghost (ha!) failing with error 19922.

A simple reboot fixed it, but it still took me about 3 hours of being very worried to fix, because I had made a major change to my network since the last backup…

1. Ghost 7 doesn't do ext3. I had a hint of this moving from 30G to 40G but it is now verified. It makes fsck.ext3 core dump. Not a pretty sight. I was very afraid that I lost my firewall forever.
   1. You can fool 'mount' but not 'fsck'. You can do 'mount -t ext2' to mount ext3 as ext2. If you do 'fsck -t ext2' on corrupted ext3, it will still crash knowing it is ext3.
   2. 'tune2fs -O ^has_journal /dev/hda7' will convert an ext3 partition (eg hda7) to ext2. Since Ghost copies ext3 as ext2 (which corrupts the special journal) this is required.

bad = I am about to try to resize an ext3 partition. Ghost hosed that job up so bad that fsck actually SegFault'd!

​http://www.gnu.org/software/parted/parted.html

​http://www.gnu.org/manual/parted-1.6.1/html_mono/parted.html