Greetings!

["Simón A. Ruiz"]

Joshua Olstad wrote:
> Simón,
> 
> I work for a school district in Exeter NH and we are using Ghost with
> all our Windows boxes (we actually just upgraded to the latest version
> of Ghost).  Currently we are working on bringing more Linux boxes in,
> mostly thin clients with K12ltsp, but I have some standalone linux
> boxes that I would love to be able to Ghost.  Do you have any
> documentation on how you got Ghost and Edubuntu working?  I have done
> some searching on my own but really haven't found much.  All I find is
> that Ghost supports Linux cloning but not how to do it.    Anything you
> can offer would be greatly appreciated.

Not knowing how familiar you are with Ghost, or what you've tried, let 
me start at the beginning and tell you my experience of Ghost. If you 
have more specific questions I could probably be more helpful.

First of all, we were given PC DOS boot floppies with Ghost installed. 
We booted to the floppies, that had drivers and such to be able to log 
on to the domain in order to mount a Samba share as a local drive, and 
then ran Ghost from the floppy; this setup allowed us to run the Ghost 
Client on the machine and either create an image out of the local hard 
drive to that Samba share or restore an image to the local hard drive 
from the Samba share.

This was much faster than using the Ghost for Linux bit-by-bit cloning I 
started off doing, let me tell you, about 600%-700% better. And doing it 
over the network, I didn't have to physically open up the workstations 
and mess around with the hard disks. This method is fine for certain 
uses, but the extent to which I wanted to use Ghost was too much for the 
system to handle. I could image a whole classroom in about an hour and 
half, but it took my entire concentration for that whole time to set 
everything up correctly to work.

The most important hurdle I had to get over in being able to image 
Edubuntu onto a hard disk that had already been used for Novell Linux 
Desktop was the Bootloader and the Master Boot Record.

When Ghost makes/restores an image from/to a hard disks, it ignored the 
first few kilobytes of the hard disk which is where GRUB resides. Since 
Edubuntu relies on GRUB to boot, when I imaged a hard disk, initially, 
it would not boot.

Doing some research, and with some help from my local Linux Users Group, 
  I figured out how to fix the problem after imaging by running a couple 
simple GRUB commands. My research (Wikipedia article on GRUB) convinced 
me that if I just directly copied the first 61 512-byte sectors from the 
original hard disk onto the new hard disk, then it would have the same 
effect as the commands I was running in GRUB.

A few people in my local Linux User's Group expressed concern at messing 
around with the data at that level, but I felt pretty confident in my 
theory so I tried it (by "dd if=/dev/hda of=boot bs=512 count=61" on the 
original Edubuntu machine and "dd if=boot of=/dev/hda bs=512 count=61" 
on the target machine) and it worked.

I could overwrite that chunk of data on the target hard disk before 
Ghosting the hard disk, and GRUB would work fine, and then on that hard 
disk I wouldn't have to worry about it again, because the master boot 
record was set correctly.

I had to do that on all the workstations manually before using Ghost was 
a worthwhile way of cloning Edubuntu onto workstations that had before 
been Novell Linux Desktop machines. Then I went through and manually 
configured each workstation after Ghosting it.

After getting Edubuntu out to all the classrooms, and the chore it was 
to do so, I made my mind up that the next time I went through that would 
be the last time. So I designed the partition structure I described in 
an earlier e-mail to make the workstation self-Ghostable, and 
self-configurable.

Those were long weeks filled with headaches; my boss actually ordered me 
to take a few days off when he saw how frustrating the whole problem was 
becoming to me. But I made it through the whole problem with a working 
solution, though it didn't look much like what I had expected when I began.

With GhostCast Server, which we received from the corporate IS 
department when I asked about it, everything became exceptionally 
easier. GhostCast Server, which is running on my workstation in my 
office, allows us to connect an indefinite number of clients to a 
GhostCast Session and, using MultiCasting, they all receive the image at 
full-speed.

Using the original solution, running each client as a separate Ghost 
session, imaging a dozen workstations slowed the imaging process from a 
10 to a 30 minute proposition, since the image data was being 
transmitted to each workstation independently). So using GhostCast 
Server upped our efficiency several thousand percent when imaging all 
126 workstations at once.

Now on Friday afternoons, I send the workstations a remote command and 
go home. The command makes them: change the default boot setting, reboot 
to Ghost, run Ghost re-imaging partition hda2 (~10 minutes), reboot, 
realize on Linux bootup that they've just been re-imaged ("Hey, my name 
is nordx--image again!") so they use values saved on partition hda3 to 
rename themselves and configure themselves to print to the room printer, 
then shutdown for the weekend.

-- 
   ___
  (   )   Peace, Paz, Paix, Shanti, Mir, Shalom and Salaam
   \ /
 >=-Y-=<                  Simón A. Ruiz
    |                    Technology Aide
    |              Bloomington High School North
    ^