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
^
--
edubuntu-devel mailing list
edubuntu-devel@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/edubuntu-devel
