Trinity Rescue Kit

[flabdablet]

I mainly use TRK for imaging Windows boxes in the schools where I work. I find it suits me much, much better than proprietary solutions such as Ghost and Trueimage.

I use "mount -t cifs" to connect to the Windows Server 2003 shares where my images are. This works much better than mount -t smbfs, because it supports large files and doesn't suffer from access denials due to W2k3's preference for digitally signed SMB communication.

The TRK 3.2 kernel already includes CIFS support, so it would be excellent if the final version of 3.2 also had the mount.cifs and umount.cifs helpers in /sbin. This would stop me having to remember to add them before updating it, and would make it easier for me to explain the required image creation and deployment procedures to new TRK users.

Many thanks to harakiri for making such excellent tools available.

[harakiri]

Thanks for the story and the tip, mount.cifs and umount.cifs are in there for the next release.

[flabdablet]

Superb! Thanks for that.

If you like, you're welcome to include my little NTFS image creation and deployment scripts too.

One gotcha to be aware of when using partition-level imaging tools like these, as opposed to file-based tools like Ghost, is that the destination drive must be big enough to create a partition of the size saved in the image file. When I originally started messing around with this stuff, I spent a long time fine-tuning a nice Windows XP image for a new batch of allegedly identical new computers, only to have it completely fail to deploy!

I'd created a C: partition on the master machine that filled the entire 40GB drive, and it was just my bad luck that this was a Maxtor when all the others were Seagates. Not a nice way to find out that Maxtor's 40GB drive actually holds almost 1GB more than Seagate's does

You saved the day, though, by including ntfsresize in TRK! I'm quite impressed with the ntfsprogs, and I hope the shiny new ntfs-3g filesystem is as good.

These days I just make small partitions and leave half the drive unused. This fixes the size problem and also allows me to create Linux partitions in the unused space. I use these for holding local images of the Windows partition, giving me a System Restore capability that actually works, which I really need when trying out the latest education-sector software. Until you've seen it yourself, you wouldn't believe how badly some of that stuff can crap up a Windows box.

[harakiri]

You will be very pleased with the next release, there are some new features in it since the beta build 247 which will interest you very much, but I 'm keeping it a secret until the official release.

[flabdablet]

If you've got shiny new toys that want more testing, email me! Cheers.

[flabdablet]

By the way: I should mention that I make fairly extensive use of partimage as well, mainly for manipulating those system-restore-style backups. My imaging scripts are based on ntfsclone because Windows XP boxes are what I work with, so I don't need partimage's support for other filesystems, and I just happened to learn ntfsclone before I learned partimage.

In fact, before I knew of ntfsclone I just used to fill the unused space on the partition with zeroes (using the Windows "cipher -w" command line utility) and then boot TRK and do gzip -9 </dev/hda >/mnt0/image.gz. Slow, but it worked.

Ghost users considering trying out TRK for Windows imaging should know about NewSID: a free tool that does essentially the same job as Ghostwalker.

I put NewSID.exe on Administrator's desktop in the image master machine, and the first thing I do with a newly minted clone is boot it into Safe mode, run NewSID, let it restart Windows when it's done, and then delete it.

You should also be aware that Microsoft does not approve of imaging Windows in a fully-installed state, and if you do it, they won't support you.

[Riley]

Can you elaborate more on how to image windows boxes from a windows server with TRK? I am expert in neither linux nor windows server, and yet I find myself responsible for my school's network (we have 100% windows machines)... specifically, I'm not sure what to do with the mount.cifs and umount.cifs helpers you mention. If I just copy them to /sbin and then use "mount -t cifs", will that be enough to connect to my windows server?

[flabdablet]

Here's a lightly edited copy of an email I just sent one of my colleagues. If you need more details or you have trouble, post back here and I'll help.

I'm going to assume that the images you're working with define exactly one partition on the drive (possibly with unused space after it) and that the Windows file system is NTFS. That's what I use at my schools, and that's what my scripts assume.

First: download these two scripts, and save them on the server share you're going to use to keep your images on:

create-ntfs-image
deploy-ntfs-image
(see footnote 1)

Next: download NewSID.exe from the Sysinternals website and stick it on your thumb drive.

Next: when you make the image, don't make the Windows partition the full size of the disk device - leave yourself some free space after. Unlike Ghost, these tools don't work file-by-file - they work at the block level, and the only things they know about the file system are (a) how many blocks it occupies in total (b) how to interpret which blocks are used and which are free. So if you try to apply an image to a partition that's too small for it, Bad Things will happen.

I got burnt by making a full-size image for one of our Acer machines, only to find that one out of seven allegedly identical machines had a Seagate 80GB drive instead of the Maxtor 80GB drive that the others all had, and that my Maxtor image was about 1GB too big to fit on the Seagate drive Now I just make all my Windows partitions 40GB instead of 80. (see footnote 1)

Next: copy NewSID onto the Administrator's desktop on the machine you're imaging, then defrag the drive and shut the machine down.

Next: plug in a network cable if there isn't already one connected, boot Trinity Rescue Kit, and when you get a command prompt, enter this:

mount -t cifs -o user=UserWithWriteAccessToShare //servername/sharename /mnt0

Note that all the slashes, including the ones in //servername/sharename, are forward slashes, not backslashes. This is a concession that the CIFS mounter makes to bash, the standard GNU/Linux command interpreter (shell), which has a special meaning for backslashes.

You should get a Password: prompt. Type the Windows password for UserWithWriteAccessToShare (which won't echo) and hit Enter. If the mount works, you'll get the command prompt back, with no additional messages. If you're told "Bad FS type" or similar, the version of TRK you're using likely doesn't include the mount.cifs and umount.cifs helpers, and you'll need to get those into /sbin. Post back here if you need help with that.

What the mount command does is make all the files on the specified CIFS (Windows) share available to Linux's local filesystem, under the /mnt0 directory (which is one of two empty directories that Trinity Rescue Kit provides for doing exactly this kind of thing). So if you now do

ls -al /mnt0

you should see a listing of all files in the share you've just mounted (including the create-ntfs-image and deploy-ntfs-image scripts).

Next: do

sfdisk --dump

(note: that's --dump, not -dump). If the machine has IDE drives, you should see a partition list for /dev/hda. If it has SATA drives, you should see a partition list for /dev/sda. I'm going to assume "sda" in the next steps. If you're working with IDE, substitute "hda" wherever you see "sda" in what follows.

Optionally: reduce the amount of space your image is going to need, by deleting the Windows swap and hibernation files (Windows will recreate them on next boot, so this is harmless):

mountallfs -g
rm /sda1/pagefile.sys /sda1/hiberfil.sys
umountallfs

Finally: create the actual image, using

/mnt0/create-ntfs-image /dev/sda /mnt0/name.you.want.for.the.image

The script grabs the first 63 blocks on the raw disk device (/dev/sda), containing the master boot record and the low-level boot code; appends to those an ntfsclone image of the first partition on that disk, /dev/sda1; pipes the resulting mess through the gzip command to compress it; and sticks the output where you told it to. If the output file is on /mnt0, and you've run the mount command above, you should see an image file growing on your server.

When it's finished and the command prompt comes back, you can reboot the imaged machine with Ctrl-Alt-Del to get rid of TRK.

To apply this image to another similar machine:

1. Boot TRK on the target machine
2. Mount the server share in the local filesystem, using

mount -t cifs -o ro,user=UserWithReadAccessToShare //servername/sharename /mnt0

This is similar to the mount command used while creating the image, except that there's an extra "ro" option in the mount options list to ensure the share gets mounted read-only. UserWithReadAccessToShare can be the same user as UserWithWriteAccessToShare; even if the server allows write access for that user, the ro mount option stops Linux even trying to write.

3. Apply the image to the drive, with

/mnt0/deploy-ntfs-image /dev/sda /mnt0/name.you.saved.image.with

You should get a prompt telling you what's about to happen; if it's what you want, enter Y. When the script's finished running, reboot and the machine should be an exact clone of the one you imaged. Boot it into Safe mode, run NewSID, reboot, delete NewSID, rejoin to the domain and you're done.

I like to run NewSID only in Safe mode, because I suspect it reduces the amount of ways that it can possibly go wrong.

Footnote 1: You can open these scripts with Wordpad (not Notepad) to see what's inside them, but don't use Wordpad to make changes in them - you'll mess up their end-of-line markers. GNU/Linux uses ASCII LF ("newline") characters for end-of-line, unlike Windows which uses a CR LF pair. Wordpad can read LF-only lines (Notepad just shows the LF's as little black boxes) but will always write out CR LF at the end of each line, and the unexpected CR's mess things up for bash, the script interpreter. Editing bash scripts is generally a job for Linux-based editors, though some Windows-based programmers' editors will also allow you to specify LF-only newlines.

Footnote 2: In fact it might make sense to make the initial partitions even smaller than 40GB. The Trinity Rescue Kit includes the ntfsresize tool, which will allow you to expand an NTFS file system to fill a bigger partition (or, if it's defragmented enough, shrink it to fit on a smaller one). So if you make your initial Windows partition say 15GB, that should be plenty to hold any conceivable set of school software, guaranteed to fit on any new or possibly scrounged replacement drive, and capable of being expanded later if necessary.

[Riley]

Wow, thanks a lot. I'm sure that'll be very helpful. This looks much easier (well, much QUICKER) than using ghost, which takes a dozen minutes just to boot and needs more RAM than some of my lower end computers have (I have to swap RAM around in some computers just to use the #$* software).

Thanks again!

[flabdablet]

It all works well for me. I like that TRK's hardware detection is good enough that it works with every network card I've thrown at it, that it will run on any machine that's good enough to run Windows, that it boots quickly even if I've told it to run in RAM and eject (which is a handy thing to be able to do when imaging a classroom full of machines), and that it's all non-proprietary and open source and I can bend it to my will with a little fiddling. I hope it works for you too.

You speak of low-end machines. Are you running Win98 on some of those? Because if you are, please note that create-ntfs-image and deploy-ntfs-image won't work on FAT partitions. If you need a FAT partition imager, let me know and I'll do a couple of updated scripts based on partimage instead of ntfsclone (both are included in TRK).

If you want to do it without scripts:

dd if=/dev/hda of=/mnt0/name.for.hda.bootblocks.image bs=512 count=63

will make an image of the first 63 blocks on the primary IDE drive (which includes the partition table, first-stage boot code, and any second-stage boot code);

dd if=/mnt0/name.of.saved.bootblocks.image of=/dev/hda bs=512 count=63
sfdisk --re-read /dev/hda

will deploy those boot blocks to a new hard disk, giving it the same partition layout and boot code as the original.

Having dealt with these low-level issues, you can then use

partimage

to start up a nice interactive partition imaging tool, which can create or deploy efficiently compressed images of any disk partition in a heap of filesystem formats.

Here is some stuff I posted elsewhere that covers figuring out how TRK is going to name your disk devices and their partitions.

Enjoy!

[Riley]

Thanks so much for your help!

I am running into a problem - though I thought I downloaded the latest version of TRK (I have 3.2), I am indeed getting an error when I try to mount my ntfs network share. I enter:

mount -t cifs -o user=UserWithWriteAccess //servername/sharename /mnt0

and get a "wrong fs type" error. You mentioned that maybe I don't have the mount.cifs and umount.cifs helpers - if I just put those in /sbin before I burn the CD, should that do the trick?

Thanks again~

PS: I see now that there is a beta for a newer build of 3.2 that supports ntfs more thoroughly - I'll just download that.

PPS: Same error with the beta 3.2... but I notice that [u]mount.cifs are still not in /sbin. I'll go back to trying to add those to the CD image...

[Riley]

Ok ~ I feel dumb, but I can't figure out how to add anything to the CD. I tried using trk2usb to get trk onto my usb stick, but my usb stick apparently has some U3 trickery going on that makes it an invalid block device... sorry to beg for help here, but I'm stuck, and I'd love to get rid of norton

[flabdablet]

The way I've always done it is this:

I've got mount.cifs and umount.cifs on my USB thumb drive, under /Installers/Samba. So I boot TRK, stick in the thumb drive, and do

mountallfs
cp -av /sda1/Installers/Samba/*.cifs /sbin
umountallfs
chmod +x /sbin/*.cifs

That last step is more or less reflex; since my thumb drive is formatted FAT, everything on it gets executable permissions by default and cp -av preserves these - but I've been bitten before by cifs helpers ending up non-executable after being copied from an NTFS filesystem (symptom is that mount -t cifs fails completely silently), so I always do the chmod thing to be sure.

Then I'll use

updatetrk

to create a new TRK .iso image including virus scanners and their updates and the cifs helpers, burn that to CD, and use that for my imaging stuff. I haven't played with booting TRK from a thumb drive yet.

If you're working on a machine with a SATA hard drive, your thumb drive will likely show up as /dev/sdb1 instead of /dev/sda1, and mountallfs will mount its filesystem as /sdb1 instead of /sda1.

If your thumb drive doesn't work at all from inside TRK, you can use wget to download the cifs helpers straight into /sbin from the web:

cd /sbin
wget http://www.samba.org/samba/ftp/cifs-cvs/mount.cifs
wget http://www.samba.org/samba/ftp/cifs-cvs/umount.cifs
chmod +x *.cifs
cd
updatetrk

and you're done. You can skip the updatetrk step if you're happy to do the cifs helper installation dance every time you use TRK until harakiri releases the next version, but the updated TRK really is nicer - virus scans are a lot quicker because you've already got most of the updates, Captive NTFS works without needing to be configured, and mount -t cifs just works.

I've actually found updatetrk to be a little fragile if you've not got a rock-solid network connection, because the virusscan script it invokes deliberately cripples wget's error-recovery strategy (I don't know why, and I've whinged to harakiri about it). If you're running updatetrk and you have download breakages during it, try this before running updatetrk:

vs="$(which virusscan)"
sed '/wget/s/-t 1 //' <"$vs" >/tmp/vs
sed '/wget/s/-T 5 //' </tmp/vs >"$vs"

Mind how you go with this - single quotes and double quotes have different meanings and must be entered exactly as shown.

The other thing that's broken updatetrk for me before is running it on a Windows box with a swap file smaller than 300MB. If updatetrk complains about being unable to find a valid pagefile.sys, that's most likely what's wrong.

Let us all know how you get on.

[harakiri]

The default timeout for wget is 900 seconds.
I have to find a balance between usability and user specific situations. So that 's why the timeout got built in.
Personally, I have a very slow responding proxy server here at work but wget mostly gets through with the timeouts I 've given it. Next release of TRK will have the ability to specify the timeout yourself. So if you really want to set it to the default, you 'll have to specify a timeout of 900

[Riley]

Hey, I updated the iso and everything works great! Thanks so much for your help. This will end up being a timesaver for me, and as a full-time sysadmin and a full-time teacher, I can always use that. Thanks for a great tool harakiri!