Fog 1.2 = Issue after issue.



  • I’m going to make a loooong story short.

    Fog 1.2 -
    Dell 9020 machine for imaging.
    Windows 7 64bit - SSD hard drives.

    1. Syspreped and up loaded image with Single disk resizable - Go to deploy = Fail WINLOAD.EXE

    2. Syspreped again upload inage with Multiple Partition Single Disk not resizable - Go to deploy = Works! But now the 250GB hard drive is reporting 491mb Free on a 41GB partition. Don’t know what is up. We have done these machines on the old .32 fog with no issues. We are also having issues with notebooks too. I’ll save that for another post.

    Under Disk Management the lower graphic shows OS (C:) 228.14 GB NTFS but the list above that shows SYSTEM.jpg



  • Because the OOBE experience is actually required for windows to properly adjust to a machine’s hardware, if you want to add software to a windows machine fresh out of the box without even going through with OOBE (which keeps your re-arm count from going to high) I HIGHLY suggest going through with the windows install until asked for a computer name and username, at this point if you hit CTRL+SHIFT+F3 your system will reboot into AUDIT mode, Sysprep will pop up when windows logs in. At this point choose “Enter system audit mode” for the first option and “quit” for the second and hit OK, Sysprep will take a few moments to close and once it’s gone you can do with the system what you will (Drivers, Software, even populating C:/Users/Default/Desktop with any shortcuts the client may need). At this point you can run windows updates (IT IS OK IF YOU NEED TO RESTART YOUR PC FOR UPDATES THIS WILL NOT DAMAGE ANYTHING AS LONG AS YOU CHOSE QUIT IN SYSPREP AS I STATED ABOVE, YOU WILL ONLY HAVE TO REPEAT CHOOSING AUDIT MODE AND QUIT EVERY TIME THE PC RESTARTS) after finishing with EVERYTHING you would like to exist on the computer restart once more, now that we have everything we need we can set it to run OOBE at last, Sysprep will pop up as always under System cleanup action choose “Enter System out-of-box-experience”, and check the generalize box, and for the second option choose reboot and hit OK, the computer will now reboot when the BIOS starts hit whatever key you need to access the boot menu, queue your host to upload the image in the FOG web GUI and boot it to the NIC, this SHOULD pull the image just fine and negate MOST issues everyone seems to be having! Apologies for the multipost…



  • This post is deleted!


  • Edit: Never mind, using FogPrep seemed to get the single disk resizable to actually pull both partitions on my virtual box, still researching more before just wiping my recovery drive… I’m just concerned about the “Active” tag on the Dell partition, as from what I’m told that’s where the boot.ini is stored, even though my C drive has a “Boot” tag…I wonder what Microsoft was thinking when they developed the naming scheme…I’m going to attempt uploading an image off the real computer with Fogprep this time to see if it’ll finally work
    Update: Even after using FogPrep the image fails to deploy, now it can’t even start to even see windows, it just says “A disk read error occurred” right after the dell load screen. HOWEVER FogPrep did indeed pull both partitions like I was going for! I need to find a new Win7 disk, these OEM Dell disks seem to keep trying to put on these stupid recovery partitions and don’t even get me my drivers back…Jayphizzle seems to be right, it is best to remove the OEM recovery partition and use a FRESH Win7 install and finding the drivers yourself…I’ll try installing in Audit mode as I’m running out of options…
    I really don’t remember this being nearly so difficult when I was imaging 20 laptops at a time in Fog 0.32…
    Update2: Realized the whole time I was forgetting to put the computer back into OOBE mode. The image I made in Audit mode works like a charm! just like the good old days! Just ironing out the last of my configurations now and I’ll be happily back to deploying images like no tomorrow!



  • I seem to be having a similar issue with Fog 1.2 on a CentOS 6.6 machine, from what I’m seeing when I set my image for “Single Disk - Resizable” it picks the 5GB system restore partition my Win 7 Pro OEM disks automatically drop in instead, I’m assuming this is because it is first on the disk before my actual OS’s partition? My systems use 250GB HDDs, when I use the “Multiple Partition Single Drive - Not Resizable” option it finds both of the partitions just fine, but I’d prefer to use the resizable option in case if there are any differences in my drive sizes. I was wondering is there a way for me to choose exactly which partition Fog uploads (I noticed this mentioned in the possible features for 1.2)? And if it can’t should I just delete the partition the windows disk put on there? (I just want to be safe before I destroy vital system info, also as I write this I am uploading the full not resizable image just in case, loving the 2 hour wait time for a drive that size! =D)

    P.S. I have avidly been using fog since (I believe) version 0.32B for the business I work for to deploy Win 7 Images with our required software packages and don’t remember running into these problems. I’ve written full tutorials on how to install versions 0.32, 1.01, and 1.2 on CentOS 6.4-6.6 machines. We’re using Fog to deploy the initial image and the German program OPSI to actually push updates/extra software packages after Fog images our systems for a fully automated mass imaging solution! You developers have made my life a lot easier, thank you for your support!


  • Senior Developer

    @OldSkoolMC, post: 36529, member: 22192 said:

    We ended up doing that and that seemed to work. The new FOG doesn’t seem to like the utility partition I guess. Funny thing is that version .32 we were able to image the same systems no problem.

    It’s not really fog not liking the utility partition, but rather the way the partitions are setup.

    0.32 would (should have) have the same issue on the same system because it’s making assumptions on “fresh” installs on 0.32 the same way 1.0.0 thru 1.2.0 do. This of course is in the case of resizable. In the case of Multipart images, FOG 0.32 works because it’s operating on a pure MBR setup, 1.0.0 -> present versions of fog actually can “handle” gpt and it’s because of that that you’re seeing problems. Your out of box system has GPT partition layout rather than MBR partition layout.



  • @jayphizzle, post: 36516, member: 1123 said:

    I would suggest to remove the OEM Recovery partition and install a clean Windows 7 with the newest drivers.

    We ended up doing that and that seemed to work. The new FOG doesn’t seem to like the utility partition I guess. Funny thing is that version .32 we were able to image the same systems no problem.



  • I would suggest to remove the OEM Recovery partition and install a clean Windows 7 with the newest drivers.



  • We had a brand new machine out of the box… installed our software. Did a sysprep and then uploaded the image. The above is the result of deploying that image to a brand new machine out of the box.


  • Senior Developer

    Let me guess,

    You received the machine, sysprepped or what have you, and tried uploading image?


Log in to reply
 

724
Online

38721
Users

10548
Topics

99849
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.