We did a similar thing for our old images, I copied the images directory to a different machine and ran the installer. I had to add the images manually as described above. I ran into a couple of problems along the way…

[LIST=1]
[]Make sure you have the filenames correct or you’ll get error messages about having to upload before downloading (see [URL=‘http://fogproject.org/forum/threads/updated-from-32-to-1-1-0-wont-let-me-create-deployment-task.10743/#post-29652’]this thread[/URL])
[]If your images were created with partimage make sure you use partimage to deploy them (rather than partclone)
[/LIST]
It sounds like you might have an issue with 2. There is a setting in the configuration options under “Fog Configuration->General Settings”, called FOG_LEGACY_FLAG_IN_GUI. This setting adds an “Image Manager” option to the images, which allows “PartImager” to be selected as the imaging tool instead of partclone.

Having said that partclone seems to be miles ahead of partimager in terms of features so what we did was to deploy our old images with partimage then create a new image on the fog server and upload them with partclone.

It sounds like the problem is with the DHCP service rather than Fog. Your Fog install could be fine, but if there is a problem with DHCP your clients won’t even try to talk to fog.

One thing to try might be sniffing out some of the DHCP traffic on your network to confirm that it looks it should. Wireshark should help there. My hunch from what you say above is that your Citrix setup might have a DHCP service somewhere which is handing out DHCP leases in competition with your FreeBSD box. If that is the case, and your client gets it’s lease from that other DHCP server then it wont work.

Oops, there shouldn’t be a colon at filename
[CODE]host tfptclient {
hardware ethernet 00:24:43:C3:A4:DC;
next-server 192.168.0.19;
filename “undionly.kpxe”;
fixed-address 192.168.0.210;
}[/CODE]

How far PXE boot does it get?, do you see the iPXE stuff? Also, I think the filename you need in option 67 is “undionly.kpxe” not “pxeboot.0”. Fog 0.32 used “pxeboot.0” but I don’t think fog > 1.0 does so your stanza might look like

[CODE]
host tfptclient {
hardware ethernet 00:24:43:C3:A4:DC;
next-server 192.168.0.19;
filename: “undionly.kpxe”;
fixed-address 192.168.0.210;
}
[/CODE]

I got caught out by the name change as well.

In case anyone else is interested in doing this I’ve updated my instructions on the fog wiki to describe
[LIST]
[*][URL=‘http://fogproject.org/wiki/index.php/Include_SystemRescueCD’]how to include SystemRescueCD [wiki][/URL]
[/LIST]
You [I]can[/I] do it by just booting from the CD instead, but we found it a really handy addition for resetting admin passwords, fscking filesystems, recovering broken systems etc. so we put it into fog.

It sounds like grub might be messed up, I’ve seen this quite a lot on 0.32. The short answer is that if you don’t have a big investment in your current fog setup, replace it with 1.1.0 and things should start to work (they did for me). The long answer is much cooler here it is…

You need to reinstall grub but to do that you need the linux system mounted. To get around this chicken-and-egg problem you need to boot from a liveCD then switch to the linux system with chroot. I use systemrescueCD to fix things like this, there are instructions on the [URL=‘http://www.sysresccd.org/Sysresccd-Partitioning-EN-Repairing-a-damaged-Grub’]sytemrescueCD website here[/URL]. Here is a summary, the lines starting with a “#” are my running commentary…

[CODE]

I’m assuming your disk shows up as /dev/sda, if not change it as appropriate.

Mount the root partition somewhere (assuming single partition setup)

$ mount /dev/sda1 /mnt/windows

Mount the proc, dev and sys filesystems inside the linux root

$ mount -o bind /proc /mnt/windows/proc
$ mount -o bind /dev /mnt/windows/dev
$ mount -o bind /sys /mnt/windows/dev

Chroot into the linux system with a bash shell (systemresuceCD uses zsh which probably won’t be available in the chroot)

$ chroot /mnt/windows /bin/bash

Reinstall grub, you should get a success message or there is a problem with the grub configuration.

$ grub-install /dev/sda
[/CODE]

If you have a different partition setup there are some modifications to the mount steps but that is basically it, again the [URL=‘http://www.sysresccd.org/Sysresccd-Partitioning-EN-Repairing-a-damaged-Grub’]systemrescueCD page[/URL] has good information on this. It also tells you how to get out of the chroot and then unmount everything, but I usually just hit Ctrl-D then reboot. The system should boot into grub now.

We had to do this so frequently that I actually added systemrescueCD as a boot option in the fog menu. It lets you run filesystem checks and reset passwords etc very easily - just make sure the entry is password protected.

I hope this helps, but as I said at the top, try fog 1.1.0; the grub and linux partition handling is much better, I have a bunch of linux images working now for RHEL, Mint and Ubuntu.

Is it possible that the kernel and init are for different architectures? It looks similar to [URL=‘http://fogproject.org/forum/threads/problems-inventorying-a-hp-450g1-with-0-33b.10157/’]this forum post[/URL].

Thanks Tom. It looks like RHEL7 released today as well, good timing!

Redhat are moving their default file system to xfs (from ext4) in RHEL7. I’m guessing this will mean all of the RHEL derivatives (Centos, Scientific Linux, …) will follow suit. Partclone supports xfs, but at the moment the fog upload scripts are falling back to partclone.imager and taking taking a raw image of the partitions. I’ve tested the following patches and they seem to allow xfs to be handled correctly, please consider them for inclusion.

[CODE]===================================================================
— src/buildroot/package/fog/scripts/bin/fog.bkup (revision 1801)
+++ src/buildroot/package/fog/scripts/bin/fog.bkup (working copy)
@@ -943,6 +943,8 @@
fstype=blkid -po udev $win7sys | grep FS_TYPE | awk -F'=' '{print $2}';
if [ “$fstype” == “ext4” ] || [ “$fstype” == “ext3” ] || [ “$fstype” == “ext2” ]; then
fstype=“extfs -c”

•                            elif [ "$fstype" == "xfs" ]; then
  

•                                fstype="xfs -c"
                            elif [ "$fstype" == "ntfs" ]; then
                                fstype="ntfs -c"
                            elif [ "$fstype" == "vfat" ]; then
  

[/CODE]

and

[CODE]Index: src/buildroot/package/fog/scripts/bin/fog.upload

— src/buildroot/package/fog/scripts/bin/fog.upload (revision 1801)
+++ src/buildroot/package/fog/scripts/bin/fog.upload (working copy)
@@ -261,6 +261,10 @@
fstype=“extfs -c”;
echo $fstype;
sleep 10;

•                elif [ "$fstype" == "xfs" ]; then
  

•                    fstype="xfs -c";
  

•                    echo $fstype;
  

•                    sleep 10;
                elif [ "$fstype" == "ntfs" ]; then
                    fstype="ntfs -c";
                    echo $fstype;
  

[/CODE]

I’ve tested upload and download against RHEL7 (release candidate 1) images and everything seems to work.

-Ian

P.S. I’m new here (but not to fog), so if I’m doing something wrong, please let me know.

[url=“/_imported_xf_attachments/0/954_fog-upload-xfs-support.patch.txt?:”]fog-upload-xfs-support.patch.txt[/url]

I had an identical problem in similar circumstances, check that the “Image Path” matches the actual directory path on the disk of your fog server, in my case I had changed a “w” to a “W” in the on disk filename so fog wasn’t finding it.

Before I noticed this mistake in my case I fixed it in a hackish way which might also work for you: Basically I tried to trick fog into thinking that the image had already been deployed by doing this

[LIST=1]
[]cp -rp /images/LHSLenovoTC7373AMU64Bit /images/LHSLenovoTC7373AMU64Bit-old
[]Upload of whatever was on the client into LHSLenovoTC7373AMU64Bit
[]cp -rp /images/LHSLenovoTC7373AMU64Bit-old /images/LHSLenovoTC7373AMU64Bit
[]Download of the actual image onto the client
[/LIST]
I’m sure there are better ways of doing this, but it worked for me.