You’ll also want to turn off DHCP in the fog config file, otherwise it’ll just turn back on the next time you update. Here: /opt/fog/.fogsettings look for dodhcp and set it to ='N'

@george1421 We were successful yesterday when we used the image we created on our Stem machine. We were able to do perhaps 4 PC and all worked perfect. To say we were excited at the possibility to knock these out so fast is a gross understatement.

Today using the same image we have the boot issue. Now to be fair perhaps it is a driver issue. I am not sure if we have all possible drivers loaded.

I am 95% sure we tried a capture from the reference image (swap the hard drive with a blank one) and deploy back to the same hardware and it didn’t work. But I might be wrong since we tried maybe 10 different things today on top of trying to manage our 11 store 600 PC environment. It can get a bit confusing at times.

I will try that for sure next as well as making sure we have the right driver packs.

@avaryan not the case

@wayne-workman Thanks…

@jblack said in Database Install blank page:

MariaDB [(none)]> CREATE DATABASE fog
->

There is a ; missing to complete this SQL query and make it actually run. But as we see the connection is fine I think we can at least rule out a general mysql/mariadb connection issue. Although this is no prove that PHP is actually able to connect.

The problem is your Windows DHCP server is already handing out Boot info.

Your client sees this info and tries to boot from it immediatly.

ProxyDHCP can only step in and help out if the Network boot info isn’t passed on yet.

Auto logon values are stored in the registry. Run the following PowerShell script to determine your current AutoLogon settings.

$path = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' $AutoAdminLogon = (Get-ItemProperty -Path $path).AutoAdminLogon $DefaultUserName = (Get-ItemProperty -Path $path).DefaultUserName $DefaultPassword = (Get-ItemProperty -Path $path).DefaultPassword $AutoLogonCount = (Get-ItemProperty -Path $path).AutoLogonCount Write-Host "Current AutoLogon Settings:" -ForegroundColor Yellow Write-Host "AutoAdminLogon: $AutoAdminLogon" Write-Host "DefaultUserName: $DefaultUserName" Write-Host "DefaultPassword: $DefaultPassword" Write-Host "AutoLogonCount: $AutoLogonCount"

Output from my Windows 10 1607 laptop:

Current AutoLogon Settings: AutoAdminLogon: 0 DefaultUserName: Administrator DefaultPassword: AutoLogonCount:

AutoAdminLogon has two states. If it’s 0, then it’s disabled. If it’s 1, then it’s turned on.
AutoLogonCount indicates the remaining number of automatic logons. This number decreases by one every time the computer restarts, until it reaches 0. When it reaches 0, it changes AutoAdminLogon to 0 and clears the DefaultPassword. Setting this to any number below 0 will effectively set your computer to automatically logon forever.

@sgwk said in Hyper-V Virtual Machine (gen 1) hangs with “Booting from SAN device 0x80”:

@tom-elliott It is gen 1. I tried Refind_efi and it did not work.

Sometimes the basics need addressed. So, there’s two exit type options per host. One for legacy/BIOS mode and one for uEFI.

If your changing the bios one only, but the VM is factually uEFI, then no change will appear to happen. Because fog directs uEFI machines to use the uEFI setting.

So please check this too.

Multiple Partition Image - Single Disk (Not Resizable)
Partclone Compressed

@labanh This is strange indeed. You might want to take a look at the apache error logs. Might shed a light on what was wrong. See my signature on where to find the logs on your FOG server.

EDIT: Tom just suggested that this might have been caused by Ubuntu’s unattended upgrades! Good point. Keep that in mind.

@entr0py What exactly do you mean by “…but the partitions never resize”? What exactly is the outcome after cloning the image to disk? You made sure the image type is set to resizable?

Please post the contents of d1.minimal.partitions and d1.fixed_size_parts as well!

From the picture you posted it looks as if there is an issue with the d1.original.uuids file. Please post the contents of this file too.

Please read through this thread as well and pay attention to Tom’s last comment.

@jim-graczyk said in FOG installed on small VM. Possible to drag and drop images when needed for deployments?:

Wayne is an expert, so maybe my approach is more work.

My suggestions take into consideration the present skill level of the person doing the operation. Adding a virtual disk would certainly work.

@george1421 Thanks everyone.

@crbarahona Is the OS configured as a Legacy (MBR) style image or is it configured as a UEFI style image? It, at least seems, to me to be Legacy style windows image as you are using the SANBOOT/GRUB_FIRST_HDD to work on both 1604 and 1703, but it almost sounds like 1703 is forcing some form of UEFI stack to the disk. (Maybe 1703 is changing the disk to a “dynamic” disk changing how the disk is partitioned without losing the data.) – (Doubt it as changing to GRUB works okay – then again GRUB is a proper bootloader and might not be hitting the constraints the bios is handing out as iPXE could be).

I really don’t want to think this is an iPXE issue considering the iPXE code did not change one bit. If it were an iPXE specific issue, the problem should be present on the same system regardless of what OS you deploy/use on it. The only variable that’s changed here is the OS on the client machine so it must be something that OS is doing.

The next question is more direct, I think.

If you deploy the 1604 image to a machine, boot into Windows, then deploy the 1703 image to the machine is this issue immediate? (When the machine reboots after the post deploy does it boot into windows or is it immediately broken?)

If it boots into windows 1703 and then fails on any subsequent reboots I would think there’s something Windows is doing regarding firmware which could be causing the problem. (It could even be something like the firmware to the NIC changing how iPXE is passing to SANBOOT, meaning iPXE might be able to do something to check and fix this.)

If it doesn’t boot immediately following deployment, then I believe the issue is how the disk is “laid” out.

I know there’s a lot of information here, just trying to get a full picture.

Trying using noapic as a kernel argument.

@noelpd OK have someone login and then tail the apache error log we print debugging info there .

rhel/centos: /var/log/httpd/error_log
debian/ubuntu: /var/log/apache2/error.log

From there we can understand what is going wrong. We have tested the ldap plugin against openldap, but we have had more success (of course) with MS AD.

I should also add that replication works as it should as well.

@avaryan FWIW, you can start with a online generator to build your basic win10 unattend.xml file: http://windowsafg.no-ip.org/win10x86_x64.html To that we add in the section to load the drivers from a known location. We have to do this because some driver are needed for the OOBE process (we use a single image developed on a vm for all computers in our fleet) to run successfully. Then in the setup complete we use dism to inject any drivers missed during the initial OOBE process (mainly because some hardware is hidden behind other devices that needs it driver loaded first).

In our deployment process we use the unattend.xml file to connect to AD and not the fog client. We calculate the target OU based on several factors that is calculated at deployment time. This dynamic OU selection isn’t possible using the standard FOG environment. So we use a post install script in fog to update the system’s host name, location, timezone, OU location and a few other things that escapes me right now.

Since we use MDT to build our reference image you don’t need to mess with audit mode to default user profiles that is managed by the mdt process.

I’ve remoted in we are checking a change to see if the replication of sub sub sub folder stuff will work appropriately. Right now it’s in the middle of file 1.6million (I don’t really know but it’s a lot of them).

At least it appears to be checking the files iterative now.
Once it completes the first check, I’ll restart the service and hopefully it will work. It will take a while of course .

@tom-elliott

Tom,

We’re good on the cancellation issue, but I’m still seeing a series of packets with the same start time and ever increasing durations times for each subsequent snapin.

I didn’t get that you made a change. I doubt I can be of any help with the code, but I’ll look.

The screenshot above is a single deployment of an image with several snapins. There’s a reboot after 0-W7PostImageCleanup and another after 1-UACDisable. So there are 3 “series” of snapins in this deployment.

2017-08-10 12:24:36 (2 snapins)

2017-08-10 12:25:28 (1 snapin)

2017-08-10 12:26:14 (6 snapins)

All scheduled as part of the image deployment and all separated only by reboots implemented by FOG as part of a snapin.

Jim