@tandersb 14.04 is not too bad, 16.04 isn’t either as long as unattended updates are turned off. There is a post in the announcements forum to help you unscrew your system from that too.
AFAIK there isn’t a mailing list for updates.
Just use git and do a git pull and then rerun the installer to bring you up to the latest stable. There was quite a few disk related fixes added between 1.3.5 and 1.4.1 that you will probably need if you use single disk resizable.
@tandersb According to your fog home page you are on an older release. And since your version number is a bit crazy I’m going to suspect an RC release. Can we get you to update your fog version to 1.4.4 (svn: 6077). I’m not saying that your issue will be resolved with the update. But if we need to get the developers involved with your issue they will say you need to be on the current release any way.
@dew12 I see in your pcap the pxe process looks good, but there is not tftp asking for the ipxe.efi file. It appears that everything is given to the client.
There was two things that I question.
I need to look over this thread again, but I wonder if dnsmasq is the right tool here. If you need the fog server to give out the dhcp addresses to the clients I think that isc-dhcp may be a better solution. You can do the same with dynamic boot file name with isc-dhcp and is the recommended setup for fog: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1
I need to think about why dnsmasq is being used where isc-dhcp would not work better.
@sebastian-roth Can you tell me how the system picks the size for the root file system. Is it the size of init.xz + some kind of buffer? If I add files to init.xz and then recompact the files it seems to grow some how.
@sebastian-roth OK I will have to look into what I need to install. The code kind of weaves it self into the existing paths.
It would be interesting to know if we could expand the initrd fs to the size of the “ram drive” kind of how FOG does with single disk expandable.
@anthony-delarosa Ok when you are ready we can move forward. These instuctions are not destructive and can be reversed with a comment in a config file and restarting apache.
Here is where I’ve been documenting the config changes: https://forums.fogproject.org/topic/10717/can-php-fpm-make-fog-web-gui-fast
The change to my server has made a difference in web gui response time. But again I don’t have a large campus so its hard to scale how much of a change its made. The instructions I created were for centos 7, but should translate to 6.7 without issue. If you run into an issue I’m spinning up a 6.7 instance of centos just to be sure.
As part of your task. I would like you to track in vmware vm cpu usage to see when you turn on php-fpm if there is a change (in either direction) or no change. There are two parts I want to test one step at a time.
Your vm should have 3-4 GB of ram for this test. If you have more already then that is fine. I just want to make sure we have room to spawn up everything.
@cmtprj if you can, is it possible to get a pcap of the exact communications where you need to key in the tftp IP address? There is something going on there that we need to understand.
I’m working with Dell’s command and control tool kit. I need to be able to install these files in FOS using a postinit script. The FOS root disk is only 109MB in size. I need to expand this disk larger to support a few more files. I assume that the web gui kernel parameter FOG_KERNEL_RAMDISK_SIZE controls the size of the FOS RAM Drive. I do see the updated values passed as a kernel parameter to FOS, but the disk remains the same size.
Am I misunderstanding the intent of this kernel parameter. I could bake the files into the init.xz file, but that would then create a custom init that would need to be updated each time fog is updated.
@thebrennan47 I have a few 7040s in our staging area. I will grab one in the AM and configure it the same as you have outlined above. One question do your 7040s have nvme disks or sata? Ours have nvme (I think).
@sebastian-roth There was a thread today where the OP had a new Dell 7720 laptop. We did have to switch that from raid mode to ahci mode because the workstation was in uefi mode. We may want to dig into why that switch is needed at some point too. I’m not saying the conditions are similar but if the target computer is in uefi mode and raid is enabled its possible that iPXE is having the same issue as FOS.
@sebastian-roth I setup a new dev server last night and installed FOG 1.5.0RC8 on it. I had a test image of Win10-1703 that I deployed to a test laptop (Dell e6430) that was running in bios (legacy) mode. I deployed the image from my production server running FOG 1.4.4 and the image deployed properly and pxe booted properly with the e6430. I then changed the pxe boot server to the FOG 1.5.0RC8 server. Again it pxe booted properly and exited using the SANBOOT option. All defaults for FOG 1.5.0RC8 (TBH I don’t think I configured anything on 1.5.0RC8 post install).
So I can’t prove there is a pxe booting issue as it were. So what does that mean, really nothing. My experience is only one data point in this problem.
Since I don’t have a win10 uefi image (at the moment) I setup a task sequence in MDT to build a Win10-1703-EFI image. That image should be done and ready to capture in about 1hr. I’ll setup the experiment again to deploy to that e6430 in efi mode this time and see what we can find.
You will probably want to deploy the .exe directly in case it does some magic the msi doesn’t. If I had to guess (and it is a total guess since I don’t use snapins) your snapin setup might look like this:
@cmtprj If iPXE asks for a tftp server then your dhcp server isn’t filling out the pxe boot request correctly. You need to have the next-server and boot-file fields set correctly in the dhcp offer header.
What device is your dhcp server?
@george1421 After a lengthy IM session we discovered that their dhcp server wasn’t sending out the boot-file and next-server values properly in the ethernet header. There were dhcp options 66 and 67 being set. This particular pxe booting client was only looking at the etherent header for the boot server info. Once the OP updated his dhcp server the target computer booted correctly into the FOG iPXE menu.
@george1421 Update from IM: The pcap doesn’t reflect what the OP is trying to boot. The OP is trying to boot a lenovo with an intel nic, and the pcap shows an apple trying to boot.
I’m going to send you a message via IM look at the talk bubble at the top of the fog forum tool tray.
If you think you have dhcp setup correctly, and your fog server, dhcp server and pxe booting client are on the same subnet follow these instructions: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Upload the pcap to a google drive or dropbox. Then either post the link here or send it to me via IM and I’ll take a look at what is going down the wire.
@kevinaguiar said in ComputerName in OOBE Windows 10 Pro Sysprep Machine:
Returning to FOG, I thought of solutions like CloneDeploy (http://clonedeploy.org/), where it edits the unattend file, editing the <ComputerName> </ ComputerName> tag and putting the hostname that was defined in Web interface. Is it possible to do something similar in FOG?
Yes you can do this in a fog post install script. That is how I do it in my company. I don’t use fog to rename the computers, because our computer names are calculated based on where the image is deploying, what image type is used and then the asset tag is appended to the end of the that other prefix info. So it is possible to do.
If you have found a solution then great, if not let me know and I will show you how it can be done.
Sorry I had to go to a meeting.
If you are using the dell cctk kit with windows or in a winpe boot drive you can issue a command like this cctk.exe bootorder --enabledevice=hdd,embnic,usbdev --disabledevice=floppy,cdrom to modify the boot order or change other things in the bios. I think we can do the same thing in fog using the linux version and a post install script. It won’t address your issue (that has to be done before FOS boots) but it could provide some interesting options.