Ah, didn’t realize there was an update. I’ll give that a try. We have 3 new models of laptops and tablets and this is the only one that gave us trouble that’s what’s so strange. Even our older models worked like a charm all the way back to v.32.
I’ll update more when I update.
Sorry, here’s the basics
FOG 1.1.2
OS Windows 7
Image Type Single Partition, resizable
Lenovo T440 laptop
This is a from scratch build, deleted all partitions, reformatted drive, installed windows on a single partition and went to upload.
Upload was successful and machine still boots, just now stuck with a 35 gig hard drive instead of 500 with no way to resize it lol.
Prepped a T440 image master device
Uploaded the image successfully
Booted the master device that the uploaded image was pulled form, disk size has been reduced to image size.
Diskpart.exe will not resize it, Disk management will not resize it, I’m not sure where to turn with this one, this is totally new, I’ve never had this problem before. Our school is 100% Lenovo so I’ve seen plenty of other issues with MBR’s that were screwy but this one is driving me nutty.
Hi Klaus, probably already too late here but for notifications sake, I’m able to do the X230’s no problem. I had to restructure the master to a single partition and make sure the boot flag is set to the primary OS after Windows 7 sets up it’s utility partition. I also changed the AHCI settings to compatibility mode. Other than those things it went smoothly.
I’m trying to image a Windows 2003 server running on a Dell Power Edge 860. I can successfully boot to the FOG PXE but it errors saying “Hard Drive Not Found” since this is a fully functional server, I’m assuming this is a RAID driver issue with FOG. Does anyone have any ideas where to go with this next, I’m not having any trouble with the rest of our workstations, a mixture of Lenovo tablets, laptops and workstations, just the Servers we have which are a mixture of 2003 and 2008 (14 in total ).
FOG Server:
Ubuntu 11.04
Fog Server .32
[B]UPDATE[/B]: Ok, so after a lot of struggling, and some physical and OS changes, here’s the final solution (at least I hope so). I rolled back the OS via complete reinstall of the OS to Ubuntu 11.04 as 10.04 didn’t include the NIC drivers for this new of a motherboard and I wasn’t going to try and compile drivers for the Network Card (I already have enough on my plate without that task).
I also physically moved the FOG server into a rack in the server room and am direct now into the Pro Curve which eliminates any in wall wiring or cabling issues with it in my office. So far I’ve uploaded 2 of the problem images in less than 12 minutes and downloaded and imaged 2 PC’s with the troublesome X201 image in less than 10 minutes each with no trouble on either one.
Unfortunately I was so exasperated with the issues I ran across I didn’t do this in stages to find out what the actual problem is so I’m not sure this post will be useful for anyone looking at the same issues.
One thing I wanted to ask, what does mounting the NFS volume actually indicate, since I was able to successfully mount it and copy down the image with a very respectable speed? Basically does that indicate network problems or FOG problems? I’m sorry I’m not following the diagnostic pattern on this test.
Regardless of all of this thank you both for your help with this, I’m pretty sure I’m back and imaging happily.
I actually haven’t tried reversing the install, but maybe that’s the way to go and I haven’t changed any of the Kernels, so far this is the first time I have had any trouble with our network or the FOG server. I’ll have to try and find the older versions of the Ubuntu downloads, as I’m pretty sure I don’t have a CD of it.
[B]UPDATE[/B]:
Started over with a completely new installation of FOG server, same IP address, did not migrate the images, used the master computers for each image to create new images. Uploaded a new image from the X201 master which went much faster and then attempted to download to 2 different X201 machines (all have the same hardware) and both of them bomb out at different points during the deployment. This is the only image that doesn’t complete and they stop at different points during the deployment. I tested the NFS setup again with the same results, took about 11 minutes to copy this image straight down to the desktop. These images were working like a charm from our initial temporary FOG server, so the only thing that’s new is the new FOG server.
Any ideas? Reloading our machines from scratch is a nightmare with all the additional software and I have to get a bunch of these machines knocked out soon.
[quote=“djm79, post: 8686, member: 1568”]Are you imaging from the same access layer switch all the time or are you moving between two different switches? I only ask because a had a very similar problem with one of our Cisco POE switches. I would take the laptop and move around and check the switches move outward from the FOG server until you get back to your access switch where you are having the slow imaging. Mine was a cheaply done uplink into a a 10/100 port instead of a gig uplink. Try that out and let us know how it goes.[/quote]
Actually the FOG server and I are in the same switch, basically our IT office is run off the main Pro Curve and both the FOG server and my imaging station are in the same office. At some point in the future I would like to be able to use the VPro chips and RDP over KVM and remote into a machine and image straight from the users location if there is a problem but for right now, I’m removing the machine, bringing it to the office and imaging from here.
An interesting thing to note here is we use primarily Lenovo workstations and laptops, I have 3 laptop images, an X230, and X200 and an X201. Both the X200 and the X230 both deploy pretty well and there’s generally no issues, it just seems to be the X201s that are the problem. This could be the image or the hardware or the fog server is my thought but not sure what to think anymore as I’ve gone round and around on this.
Ok, so the problematic image’s size on the hard drive was about 42 gigs, instead of 50. When I transferred down to my Macbook, it took about 11 minutes while uploading it through FOG took about an hour. The network is basically made up of HP Pro Curves with fiber run between the buildings (12), completely gigabit all the way throughout.
The FOG server is a brand new custom box with a 6 core AMD Chip and 4 Gigs of DDR III with a Terabyte SATA II hard drive in it.
So, does this mean that the FOG server is working correctly and I have a network problem or does this indicate a problem with the FOG Server?
Ok, I just realized the mistake. I forgot the colon after the IP address. Its working now and I’m connected to the share with my Macbook and I’m trying to copy the image down now.
I tried another image that wasn’t having an issue and brought down an 11gig image in between 3 and 4 minutes, the one that is a problem is our main image and is quite large, over 50 gigs. I’ll report back here after finding out what happens with it.
Ok, I tried running in debug mode but it hangs at different points during the deployment but everything up until that deployment point works fine. It’s been different percentages 30 percent, then 82 percent, then the last one was 9 percent. I’ve tried to mount the image using
mount -o soft,intr,rsize=8192,wsize=8192 192.168.10.168/images/ nfs-test
but receive the following error response:
mount: special device 192.168.10.168/images/ does not exist
but, using the showmount command returns the following:
root@FOG-SRVR-01:/home/fogadmin# showmount -e
Export list for FOG-SRVR-01:
/images/dev *
/images *
So I know that the images folder is a valid mount point. I’ve also tried mounting the path all the way up to and including the image file, but receive that same error message.
Any ideas?
I’ve never tried mounting one of these. Is there a walk through on the wiki somewhere? Thanks in advance.
Hi there,
Like many I ran Fog for the first time on a basic desktop just to make sure it would work. Well it worked like a champ, a few issues here and there but for the most part did everything I needed it to. So, as with many, I upgraded to a much bigger piece of hardware and began with migrating everything over.
I’m not sure where I screwed up but I copied the /opt/fog folder over intact from the old servers hard drive slaved in, I used phpmyadmin to dump and import the old database (sorry I still like a GUI when I can get it). I used the same IP addresses on both, the same login and just changed the outside user’s password, not the fog user password but apparently that’s what the TFTP server uses, so I had to reset that in the back end after clients could register but I could not start a task because of the TFTP failure. That fixed the TFTP failure and the first 2 machines I queued began their boot process.
The image is an XP image with Office, Adobe CS3, and antivirus and updates installed, that’s it, really straight forward and one I’ve used hundreds of times, about 20 gigs resized. The first client is only handling about 50 Mib/min (estimating 6 hours to complete) and the other one starts, transfers about 50 MB and then stops, says it’s still running but isn’t transferring any data. With the old box with lesser hardware I could use this same image and deploy 5 at a time in about 12 minutes to the same lab not using multicast. The network isn’t the issue because all of the switches are the same, the only hardware difference is the new Fog server. Apparently there’s something else I’m missing on the migration here. Any ideas?
[B]Basic info:[/B]
Fog Server 0.32
Ubuntu 11.10 (same on both old and new)
FogAdmin (outside Ubuntu user)
IP address the same
Fog Server name is identical