First thing, when you clone your Linux hard drive with Ghost or Drive Image (or any other imaging software) you might not be able to load Grub. Usually just running some Grub commands off a Linux System Rescue CD will fix it. I think most any bootable Linux Live CD will work. You would run these commands:

After boot, run “grub”. (the following lines are from the “grub>” prompt.)

……………………

find /boot/grub/stage1

    (hd0,0)

root (hd0,0)

setup (hd0)

quit

……………………

You would replace “root (hd0,0)” with whatever is output from the find command above. The above assumes you have /boot on the same root partition.

On IPCop, boot is on a separate partition. So you need to be a little fancier. The key is to tell it what device to use. In the example below, we will assume we know what drive the boot record is on. (hd0,0). Also note, that IPCop because IPCop has boot on a separate partition, running the find command would be like so:

find /grub/stage1

Ok, so using the device command, and since we know our root is on hd0 …
(all on the grub prompt)

……………………

device (hd0) /dev/hda

root (hd0,0)

setup (hd0)

quit

……………………

 

Now grub should load ok. This would apply to most images/clones made, I think. But, now, what if your distro uses symlinks to represent your hard drives? I ask, because this stopped me from running IPCop off an image. Took me a while to realize two things.

1. IpCop uses symlinks for /dev/harddisk instead of /dev/hda. (Can someone tell me why they do that? Why change that? Every other Linux distro I have used uses /dev/hda1 for the first partition on IDE drive.)
2. When I cloned the system, the grub.conf (also known as menu.lst on other systems) listed the root filesystem as /dev/hda4, and yet, there was no hda4 in dev directory. It didn’t even exist on the old drive, so I have no idea how IpCop was booting!

Solution to #2 above was again to boot to a Linux Live CD, mount the boot partition on hda1, edit grub.conf and change all the /dev/hda4 entries to /dev/hda3, where the root filesystem actually resided.

On number #1 above, I don’t think fixing it actually caused the system to boot, but I did it anyway. While booted to the Live CD, I edited the /etc/fstab file on the hard drive and changed all the entries for /dev/harddisk1 through 3, to point to /dev/hda1 through 3. There is probably a reason for them doing this, but ya got me why. ?? Changing this might bite me it the butt some day, but for now, it boots beautifully!

Oh, and one might ask, why make a drive image of IPCop when they provide a backup and restore feature using floppy? Well, here’s why: 1. I have a ton of add-on programs installed, and they don’t backup. 2. I like an image better than a floppy!

IpCop is an awesome system, and I’ve had zero problems with it over many years now. But, it doesn’t do enough by itself. I mostly like the BlockOutTraffic addon you can install, giving you detailed control over all communication. I also modify the SSH setup to work the way I like it, using certificate auth and custom ports for several users tunneling into our networks. (works way better than VPN!) On some networks, I have to use PopTOP, the PPTP addon for Ipcop VPN. (not by my choice, it’s a requirement by an application we use.) All these might not backup to a floppy, and it’s so fast to make a Ghost image of the drive. You just have to spend a few extra minutes during restore.

Note: I was using IPCop 1.4.16 during all this.

EDIT 10/22 (later that evening…)

For IPCop, YOU MUST boot to an existing drive on /dev/hda that contains a working copy of IPCop and have your newly cloned drive operational as /dev/hdc. When you run grub, and then all the device, root and setup commands, you need to do it like so.

……………………

device (hd0) /dev/hdc

root (hd0,0)

setup (hd0)

quit

……………………

Notice the /dev/hdc above? Don’t ask me why, but when you try to run this from a Live CD, it won’t work. I really would like to know though, because the fact that it doesn’t work drives me nuts. There must be a simple explanation, and I know it’s just my ignorance of the grub boot loader, but this shouldn’t be needed. (and yet it is!) I just don’t have time to figure it out, when I can simply boot an IPCop as hda and run this quickly. Sometimes it is easier to not ask why, and move on. So make a note of this, YOU MUST boot to and IPCop OS with your new drive installed, then run the grub setup. Stupid, but at least it works.

I fought with this one for a while, like several hours. I installed the pptp addon for IPCop, which, by the way, you must Google for. I installed version 0.2.9 (pptpd_0.2.9.tar.gz) and found that on a forum somewhere. If you go to the addon’s from IPCop, you will only find 0.2.6, and that wont work with 1.4.13 or higher. (I might have that version a bit off, but I think that’s right) So Google for that file and you should find the file and ftp server IP. I don’t want to provide that, because I don’t have permission to do so.

Anyway, back to the problem. The pptp addon installed just fine on IPCop, and the admin web gui showed the correct items. I could not, however, get Windows to connect. I always got a 619 error, like that is helpful! On the IPCop /var/log/messages, I found this:
pptpd[5740]: GRE: read(fd=5,buffer=804dc00,len=8196) from PTY failed: status = -1 error = Input/output error

You can see the details on the pptpclient help page:

http://pptpclient.sourceforge.net/howto-diagnosis.phtml#read_eproto

 

I didn’t know how to do their troubleshooting, especially on IPCop. But then it occurred to me, find pppd, and ask it for help!

I ran this: /opt/pptp/sbin/pppd –help
Returned: /opt/pptp/sbin/pppd: error while loading shared libraries: libpcap.so.0.8.3: cannot open shared object file: No such file or directory

Ah-HA!!!

Run this on IPCop 1.4.15 while in the /usr/lib directory: ln -s libpcap.so.0.9.5 libpcap.so.0.8.3

BINGO! Windows can connect! From Vista no less!

Oh, and I know that PPTP is not the best as far as security goes, but it is the only thing I can use. I am running several Wifi Palm devices with a PPTP client on them for Hotsyncing on the Internet. I realize there is another product available that uses IPSec, but that is quite expensive per device. Plus that solution might run into a lot more hassle for the users while on the road trying to connect over hotspots, because IPSec may be blocked. PPTP is just more compatible. I’d really prefer to have an SSL based VPN on the Palm, but I don’t know of one available. So, for now, I’ll at least suffer with PPTP instead of opening my hotsync up to the world. Not perfect, but I can lock down the connection with IPcop too. (sounds like another blog… J )