Best posts made by george1421

@aruhuno The devs worked on the init scripts over the weekend. Since you just upgraded to the current trunk release, does the network interface come up when you try to register this Lenovo today?

If the updates inits do not work. Could you repeat the same steps from earlier with this modification?

Use this udhcpc command
udhcpc -i eth0 --now

Then when the command times out (or better picks up an up address)
cat /sys/class/net/eth0/carrier

If the carrier value is still 0 wait 30 seconds and issue the udhcpc command again. What they were looking at is to find a way to detect if the network adapter has a slow startup. They are working hard to find a way to get these network adapters to init right.

Another quick command you can run from a linux command shell would be

showmount -e localhost

That should show you the nfs shares currently enabled. If the /images share is available, then check into directory file ownership and permissions.

@cojohnson If you are getting a white (blank) page any time you interact with the fog management GUI then the apache web server has had an error in the php code. Please review the apache error log (for rhel based systems) /var/log/http/error_log for debian based systems (guess) /var/log/apache2/error.log?

I agree its best practice to not connect the reference computer to the domain and use sysprep to prepare the reference image for image capture. I know some people say that sysprep isn’t necessary if you are capturing and deploying to the same hardware model, but if you have a mix of hardware sysprep is the best way to ensure you image works across the computer fleet.

I can see AO relationship issue with previous deployed machines as you roll out new ones if you had the reference image connected to the domain and you didn’t sysprep it before you captured it.

@Sebastian-Roth The only thing I can think is that iPXE is not that smart to support 802.3az protocol but the 4.x linux kernel drivers are. That may explain while the older linux kernels worked on this box (because they did not support this feature).

I guess I have to just throw this out since you are starting with a new deployment.

Is there any thought of changing your OS from Ubuntu to Centos? In my test environment I’ve spun up about 10 - Centos 6.7 systems with FOG in the last 2 weeks and deployed all of the trunk images without any deployment issues. In monitoring this forum for the last few weeks the majority of the install issues appear to be with the Debian based systems. I’m not saying that one OS is better than the other, but if the goal is to test FOG, then switch OS for the test and work out the kinks with the specific OS deployment later.

@John-Johnson just for clarity the power shell script that ArrowHead-IT posted (same as what I posted only through the link) corrected your issue? You were able to update your win10 with all of the updates from the internet and you applied the adobe updates? I just want to ensure your workflow was the same and the only thing you changed was the powershell script.

@boeleke I can say if you want a bit more exposure to WDS/SCCM and some clonezilla for your paper, you might want to make a post on spiceworks, in the community there. Most of the people on this forum have migrated to FOG for one reason or another. For contrasting views I would surely ask you main question again over on spiceworks. You might want to make your OP there not FOG centric.

I have both centos 6 and 7 I can test one give me a minute to finish my first cup of coffee.

This is more of a discussion than a help request.

We had an issue where we ran out of disk space on one of our test environment FOG servers. The problem started when we uploaded more host images than we had space on the FOG server. Searching the FOG server we saw that the host images are stored in /images and the snapins are stored in /opt/fog/snapins. Both of these folders exist on the root file system. Coming from old school unix we would typically create the /opt and /home not on the root file system because these directories typically grow the most. And on the older unix file systems if you fill the file system the OS crashes very badly.

(note for any of this thread to be understandable you need to read from the bottom of this thread to the top since the later posts appear first)

@Wayne-Workman Good catch, not the one I was thinking about but that is also one that has an impact based on storage node availability.

Web Interface -> FOG Settings -> General Settings -> FOG_QUEUESIZE defines how many unicast sessions are allowed at one time.

How many images are you talking about. It may be quicker to just charge through and manually copy and paste the information between the FOG server. If you are talking about 20 or more images then we can work out some solution to export the info from the database. But you will have many less future troubles if you just go the copy and paste route between the webguis.

While this is a bit off point, I did find the issue with my script.

Win7
/ntfs/Windows/System32/sysprep (folder)

Does not equal

Win10
/ntfs/Windows/System32/Sysprep (folder).

Ugh case sensitive paths and windows consistencies.

I have a similar request to what I understand you want to do.

https://forums.fogproject.org/topic/6014/create-the-concept-of-a-foreignmasterstorage-deployment-node

You can get pretty close by using the location plugin by installing a deployment fog server in each location. Then from a master deployment server you can move files to the site deployment server via the normal storage node replication. This is not a typical setup but I can get the images deployed to the sites this way. The only issue is getting the database entries from the master deployment server onto the site’s deployment server database. I can do this by scripting, but its not built into the logic as of yet.

With FOG you can not share out a mounted share in NFS (like windows). Right now you have very limited (no) options other than adding more disk space to your FOG server.

FWIW, with XP you can only be a nfs client and not an nfs server. So you are stopped there too.

@adukes40 Ah ok. I see bits of my script and from the wiki page where I started. https://wiki.fogproject.org/wiki/index.php?title=Auto_driver_Install Nothing wrong with that at all.

The results are the same, the path is a little different. Also for both my posted bits of script and from Lee’s script this will only work with Dell computers, If you use Lenovo or others the system name is located in a different element of SMBIOS. That is why in my script I pick up the manufacturers name so I can create a switch statement based on the manufacturers name to look in the other spots when required.

@george1421

For clarity the command Tom provided didn’t return any value, but it did set me on the right path (so to speak).

Well its not as clean as I hoped, but this command will return what I want.
find /ntfs -type d -iname "sysprep"|grep ystem32

For what ever reason sysprep exists in System32 and SysWOW64. Either way the above command will return the proper case regardless of the target OS.

[edit] And this command will find the proper unattend.xml regardless of the case.
find /ntfs -type f -iname "unattend.xml"|grep ystem32
[/edit]

I found this bug report for 14.04 of ubuntu.

https://bugs.launchpad.net/ubuntu/+source/php-apcu/+bug/1422484

In a nutshell the fix seems to be:

sudo apt-get purge php5-apcu
sudo service apache2 restart

Not a FOG issue more about ubuntu.

@KnightRaven I was able to access our document managment system and pull the bits out I needed to create a process out of my instructions. I should be able to test this later tonight.

copype amd64 C:\winPE_amd64
copy "C:\Program Files\Windows AIK\Tools\PETools\amd64\winpe.wim" C:\winpe_amd64\ISO\Sources\Boot.wim
copy "C:\Program Files\Windows AIK\Tools\amd64\Imagex.exe" C:\winpe_amd64\ISO\

# Download http://downloads.dell.com/FOLDER03652574M/1/WINPE3.0-DRIVERS-A20-CT5DP.CAB
# Extract to c:\winpe

mkdir c:\img
imagex /mountrw C:\winPE_amd64\ISO\sources\boot.wim  1 c:\img

# Inject the x64 drivers from the extracted Dell cab file
DISM /Image:c:\img /Add-Driver /Driver:c:\winpe\x64 /Recurse /ForceUnsigned

notepad  C:\img\windows\system32\startnet.cmd

  @echo off
  echo Setting up WinPE
  wpeinit

  echo Warming up the network interface
  net use z: \\<server_name>\<share_name> /user:<uid> <pass>
  z:
  setup.exe

# This command unmounts the wim. If you want the wim alone its this directory C:\winPE_amd64\ISO\sources\boot.wim  

DISM /Unmount-WIM /MountDir:c:\img /commit


# This will covert the wim into a bootable iso image. 
oscdimg -n -bC:\winpe_amd64\etfsboot.com C:\winpe_amd64\ISO C:\winpe_amd64\winpe_amd64.iso```

Understand that you are attempting to use an OEM license for this right?

Windows OEM licenses doesn’t support the rights for imaging. So to remain compliant with the windows EULA you can not use FOG or any other imaging solution to deploy images. You can purchase a single Microsoft volume license and then deploy OEM licenses of the same version and remain compliant. For example if you purchase 1 Windows 7 Ultimate VLK license you may deploy Windows 7 Ultimate OEM licenses to as many systems where Windows 7 Ultimate OEM licenses were originally installed.

Here is a document that Chris (from Microsoft) put together in regards to this question, since it is asked so frequently. https://community.spiceworks.com/how_to/69219-reimaging-rights-how-they-apply-to-your-licensing