@pmonstad said in not possible to capture images, database connection error:
Deploy works OK
That still makes me think its an ftp issue. Really if its a database issue I would think the FOG console would have issues or … deploy may work since it only uses kernel parameters.
I could see registration fail if there were database user account issues.
For clarity I run FOG under centos running on ESXi 5.5. I don’t have this kind of issue.
I know this was a long thread and I kind of skimmed it.
When you setup your linux server you should set the network adapter to e1000, you can use vmxnet3 if you install the vmware tools first. Its always has been a pain to do so I just use the e1000 driver. I seem to recall a bug with the e1000 driver with either the GA release of 5.0 or 5.5 that caused the virtual nic to hang under heavy load. That issue was fixed with a ESXi update. Is you ESXi server up to date with patches?
Please help me understand you say you can’t access the FOG server. I understand if you can’t access it via the network, can you log into the console directly using vmware configuration client? Or is the vmclient frozen? If you can log in from the console then I would sure check the logs in /var/logs to see if there is any indication of what happened. I would also try to restart the network services (from inside the fedora OS) to see if you can get it back online. I have see where two hosts having the same IP address will take a server off line like this.
It would be interesting to see what happens to this vm if you shutdown all FOG services at the end of the day. Is the VM still on the network in the AM?
[soapbox] While I understand the techie needs to run fedora, why are you using a desktop OS instead of a server OS? Would you load MS SQL server on Windows 7 for your enterprise application? Please pick stable rhel or centos over fedora. Yes I know it works, but why not use the right tool for the job.[/soapbox]
First of all, since the image is getting to the target system this is not a FOG issue.
I’m going to suspect a driver issue either with the sata controller or with the storage device. Reading between the lines it sounds like you might have a single image you are deploying to all computers on your campus. How are you injecting the model specific drivers into your image?
At the screen where its updating the registry, can you press Shift-F10 to open a command window? Can you inspect the log files in c:\windows\panther and c:\windows\panther\UG<something>? Does these log files give you any hint to what went wrong?
What is your storage device on this Lenovo? Is it a HDD, SSD, or NVMe drive?
@Wayne-Workman said in FOG Imaging Over MPLS:
Throwing options out there… Intel NUC with a 120GB drive, fanless, for 230 bucks. You could totally make these into fog storage nodes (George already did, I think).
http://www.thebookpc.com/product-p/de3815tykhe.htm?gclid=CMKPvuSQvc4CFQuLaQodNsUEhA
Yeah. probably not those. We used them for a few digital signage projects. They are a bit sluggish with the single core atom processor. (windows performance index of 1.1) You can get a dual core celeron with wireless and bluetooh card build it for just a little more and they are smaller: http://www.thebookpc.com/product-p/dn2820fykh.htm?gclid=CKTtmP2Rvc4CFQaQaQodiNkLYg
Or an i3 for about $270USD https://www.amazon.com/Intel-D34010WYK-DisplayPort-i3-4010U-Consumer/dp/B00F3F381A
You have to understand these are kit computers, you also need to purchase ram and a hard disk (SSD) to make it a complete bit of kit.
I can’t say for sure but RC10 seems to cause some issues more than RC9 did.
Can you run the following command from the command window
yum install php-bcmath -y
FWIW when I run that on my production server (centos 7.2.1511) it says the file it needs in the remi-php56 repo.
Sorry for being difficult here.
I see a contraindication in your statement as I read it.
I’m still trying to drive to the root either the server (vm client) is hanging or the virtual NIC is hanging/off line)
@LibraryMark said in iPXE and Reboot Restore Rx
:
Is this file (ipxe.kpxe) updated from time to time? And what’s the difference between it and ipxe.kkpxe?
The short answer is yes. Each time the FOG image is rebuilt (by the developers) the latest version of iPXE files are updated. So if you just updated to RC7 then you would have the latest build of iPXE.
That’s strange that changing the ipxe file from .kkpxe to kpxe would impact the exit modes. But if you have it working and the .kpxe file works for all systems then take the win and move on to the next issue.
Great job, because from the research I did so far this was going to be an interesting time to find a fix.
@Wayne-Workman Just for clarity here…
The exit mode in FOG, tells the iPXE menu what to boot to next when you select boot from hard drive. This is a FOG specific function and nothing to do with the computer or its firmware.
If you want to change the Dell bios settings, you can do that from windows (I just found a rhel download too)using the Dell Command and Configure tool (a.k.a CCTK). We use CCTK on our custom firmware update usb. We F12 boot to the usb into a WinPE environment that configures the boot order to the USB on next boot then installs the bios update. Upon reboot it boots immediately to the usb and the WinPE environment. Then it resets the boot order to hard drive, network and then configures the PXE on next boot option where it reboots and then pxe boots.
While that was a long way about tell you its possible to change the boot order via a script, it is possible. Understand this only works for Dell enterprise systems. I can’t speak for other vendors.
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=X0TCK
http://en.community.dell.com/techcenter/enterprise-client/w/wiki/7431.dell-client-command-suite
@Kris-Phillips Can you do this for us?
Remove the image, or register a new host, but don’t assign an image to it.
Then from a browser key in http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=<mac_address_of_system_registered> and press enter. That should create the ipxe boot menu in the browser. If you are doing this on a deploy image task then deploy the image and do the above step. The developers will probably need to see where its breaking in the iPXE menu (even though this is through a deploy, ipxe is used on bootup then it loads the FOS Engine to deploy the image).
I’m still seeing a conflict here. But lets run with it.
The console is frozen (which might indicate the vm has crashed because the console is isolated from any running application like FOG. Even if something was consuming 100% of the CPU the console should still respond, although slowly). Assuming that the vm client has hung, the network stack is still operational (which is responding to a ping). Based on my experience this is a unique situation that should not be.
Lets see if we can acquire a bit more info. Looking at the ESXi console (not the vSphere Web interface accessed by a browser) when that VM is unresponsive is the vm tools reporting to ESXi correctly (summary tab). Is that VM posting any alerts to ESXi (alarms tab). When the vm is in this lost state what does the Consumed Host CPU value show (Summary tab)? Is it high, low, or about the same as when its working correctly? There has to be some external indication that this server has gone away.
I’m still have the feeling that you might have a machine with the same address out there causing problem. That would explain the FOG server dropping off the network (hanging) but still pingable. Plus this is a new installation and not something that has been in place for a while. All other VMs are running without issue on the same hypervisor, All of this is making me think there is some external source at play here. Understand this is just an attempt to read the tea leaves based on what you’ve said this far.
While I don’t use this function so I can only guess what it does (like a software install or a forced reboot?). I can suggest that the user be prompted to do what ever, the user should have the option to delay it up to the maximum the admin has set for the job. I.E. your computer must be rebooted. The user is notified every 10 minutes up to the 4 hours max the admin has set. When that time is reached the action is carried out and the user can’t stop it. That is typically how managed deployments work with the commercial applications. With most commercial applications the user is allowed to adjust when the nag messages appear up to the max dwell time then the job is forced.
FWIW: The fog 1.2.0 installer is not compatible with Ubuntu 16.04. But if you follow these instructions to download 1.3.0-rc8 then use the command switches with the 1.3.0 installer it will work better for you.
https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk
You will want to be on 1.3.0 if you have current hardware, win10 support, gpt disk format, or NVMe drives, plus many feature and speed improvements. That is all included in the 1.3.0.
Cross linking threads, the experience seems to be similar: https://forums.fogproject.org/topic/10432/i-would-like-a-add-a-new-hdd
@jbsclm said:
@x9rok
It is some while since I last used it, but from what I remember, if there was no task for the PC you should get the FOG menu, which would then time out after the period set in the FOG GUI, if you didn’t select an option.
If you don’t get the FOG menu then it may be that the ipxe script needs changing to pass extra parameters to boot.php.
OP: From my post below the boot.php script is looking for the mac parameter to be passed to it. Without that I might understand why you are getting a different reaction.
http://${nextserver}/fog/service/ipxe/boot.php?mac=${net0/mac}
Right now its now clear of its a fog issue or windows imaging issue.
On your reference image disabled the fog client service and don’t have your setupcomplete.cmd file enable it. On your vm sysprep the image and have it shutdown. Then repower the VM without using fog to capture and deploy it. You need to see if on the same vm you can prepair an image, sysprep it, wake it up and it restores correctly. Use vm snapshots so that you don’t loose your efforts in setting up the reference image.
You should also look at the windows setup logs in the c:\windows\panther directory to see if you can pinpoint where the error is being triggered. But I’m with Wayne here, I think it is a driver issue that is causing you pain, probably video. If you look at the device manager after you reboot it, is there any indication of a failed driver?
I can say I use a process that roughly resembles what you are doing, except I’m using MDT to create my reference image in an automated manner. So it goes from DVD to a full reference image with the windows updates and base applications. This is done on a VM (as it should be done). From there I use FOG to capture and deploy the image. I also have a FOG post install script that injects the proper drivers into the image before the first OOBE boot. I use an unattend.xml file to set certain system parameters and I have the unattend.xml file connect the target computer to AD in the proper OU (the OU location is set by the fog post install script modifying the unattend.xml file before the first oobe boot). It is quite a complex dance, but the process does work.
The FOG client needs to be included in the reference image (with the service disabled) before you capture it. Posts deployment you would use the setupcomplete.cmd file to reenable the service. This keeps the fog client for executing commands to early in the OOBE install process that causes an install failure.
With that said you can include (inject) the fog client install post imaging with a fog post install script. This script would (in concept) copy the msi from the fog server to the target computer and then append the msi install commands to the setupcomplete.cmd file that will be executed once the OOBE process is complete. But the FOG server does not do this out of the box.
@tom-elliott While I’m not using a LVM disk deploying a 50GB image to a 25GB target computer seemed to work. I still have a 1.4.4 build on my fog server. I just copied over the inits.
jondoe@jondoe-VirtualBox ~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
sda 8:0 0 25G 0 disk
├─sda2 8:2 0 1K 0 part
├─sda5 8:5 0 1021.8M 0 part
└─sda1 8:1 0 24G 0 part /
jondoe@jondoe-VirtualBox ~ $ df -h
Filesystem Size Used Avail Use% Mounted on
udev 474M 0 474M 0% /dev
tmpfs 100M 3.6M 96M 4% /run
/dev/sda1 24G 5.3G 18G 24% /
tmpfs 496M 92K 496M 1% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 496M 0 496M 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
tmpfs 100M 20K 100M 1% /run/user/1000
jondoe@jondoe-VirtualBox ~ $
@Sebastian-Roth I followed your instructions for creating a uefi boot drive. The creation process worked like a charm. Once the directory structure and file inserted on the flash drive, the usb drive was available in the bios as a viable uefi boot device. Selecting the flash drive from the boot menu worked (the selection process).
BUT the system was in the same state as pxe booting the device. So no luck for us, we have the same results. The positive note is that now we know its NOT a PXE issue.
My setup wasn’t so old school. 8GB cruzer fit formatted with fat32. Then the folders created with one of the .efi files from this thread.
@MattPayerle said in windows could not complete the installation:
Its still not clear if this is a fog problem (which I’m thinking not) or a reference image creation issue. Of course you would have a snapshot before you sysprep (so you can restore the vm after this test), but sysprep the image on your reference image and then just boot your reference image back up. Does it startup without issue? This will test without fog in the picture. You are just syspreping the reference image and then booting it up through OOBE.
As for the logs in panther, they end with .log as well as there is a folder with DG or DC in the name there are logs in there too. You may have to copy them to the desktop to be able to view them. But they should give you an idea of what is going on with the OOBE process.
well the first one is stopping probably because you are telling it the nfsroot is an http path not an nfs mountable path. The protocols are different.
In your second section does /fog/kickstarts/centos6.cfg exist? But you are booting centos 7??
Here is a guide for pxe booting centos 7 that may get you closer. http://www.tecmint.com/install-pxe-network-boot-server-in-centos-7/
Your imgargs approach is right for additional kernel parameters. Also I would avoid the || read void tags at the end remember you are dealing with an iPXE boot loader and not syslinux. I would also move your files out of the /fog path. You have an apache web server create a new parent directory called /bootimg or what ever and put your boot OS files under that like /bootimg/centos (also watch your case, its easier to use all lower case).
If you want to see how the FOG developers download the FOS kernels you can key in http://<fog_server_ip>/fog/service/ipxe/bootp.php?mac=<registered_device_mac_address> You will see the kernel args and structure that iPXE needs.