@Sebastian-Roth if I had to guess it’s lvm setup.

@benjamind Do you still get the very same error message (Error returned: <empty>)??

George, I have another question, this time about sysprep. Why do we need to go through OOBE for an installation that is all in the same locale? Wouldn’t it be easier to just generalize and be done? And if doing that, do I still need to disable the Fog Client Service before doing it? Thank you, Dave

@andrewhancock91 I am on the road right now und will be for the next two weeks. Not easy to give you all the details not having my laptop with me. First you should start by searching the forums for “https fog-client” and see if you can find my older posts about why this part is tricky. It’s not a no-go but it will need good planing and manual adjustment - could even compile your own custom fog-client package… For switching back to HTTP for now you’d edit /opt/fog/.fogsettings file, find the line httpproto=https and remove the “s” at the end of “https”. Save and re-run the installer. That should be it. Make you read all you can find on this topic before diving into this again. If you have many hosts with fog-client installed and communicating to your current FOG server already you break this switching your apache config to a different certificate! Feel free to ask here if you can’t find those forum topics.

ill take a look next time i capture. i make sure the actual image size is the compressed, used data from the drives i capture, in the terminal using dh -u. we use a custom sccm image that is based on the stock windows install, which has bitlocker disabled.

@dario-vettore Try testing aß suggested in the wiki: https://wiki.fogproject.org/wiki/index.php?title=Troubleshooting_a_multicast Are you sure there is no firewall between FOG server and the clients??

@TBuzaTechnician You would need to run the mysqladmin command first, then do the command. That should set your mysql password and ensure FOG will install using that now set password. Thank you,

@slipke Well if you wanted to do it in the auto reg it will be a bit harder than manual registration, but here is the curl call in the fog.auto.reg program. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.auto.reg#L73 Before that curl call you will need to collect the serial number of the machine. The trick is the serial number is saved in the smbios in different locations for different manufacturers. If you look at this post it shows you how to get the serial number for the two chassis types I had to interact with: https://forums.fogproject.org/topic/6304/fog-2-0-request-advanced-host-naming/2 It also shows how to create a complex computer name based on several factors on the fly. So you will need to compute/collect the serial number and pass it along with the other arguments to the php file mentioned in the curl call. And then in the php code read that variable and place it in the hostname variable instead of the mac address. If you wanted to do this using the manual registration fog.man.reg where it asks for the user to input the host name into $host just use the dmidecode value to copy the serialno value into the host variable. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg#L161

@GaboGrobier We just recently hat another question on Mac OS X in the forums: https://forums.fogproject.org/topic/13795/server-fog-configuration As well use the forum search. Feel free to ask more specific questions here.

I tried to change that and it did seem to limit the number of computers that can image at once. But it did still allowed 10 computers (I believe that was the amount) to be inprogress as snapins vs checked in or queued.

@rathan While you can. You shouldn’t. Apple has made imaging a dead workflow through a number of things, the most important being the T2 chip preventing netboot/external boot. MDM and DEP is the appropriate way to now provision MacOS devices. Erasing would be done via CMD+R in recovery or by pushing an erase and install from your MDM.

@montesd Ok for that old version of FOG, you need to be on FOS Linux version 4.12.x to have the driver for the I219-LM or i219-V network cards. You can manually download the kernels from here: https://fogproject.org/kernels/ You will want to download Kernel.TomElliott.4.12.3.64 and save it as bzImage and Kernel.TomElliott.4.12.3.32 and save it as bzImage32 Watch your case because it is important. These files go into /var/www/heml/fog/service/ipxe directory. Rename the existing files in case you have to back up. Also you can try the latest kernels with Kernel.TomElliott.4.19.64.64 and Kernel.TomElliott.4.19.64.21.32 but there is no grantee that they will work with the older inits (YMMV). These would latest kernels would supported the newest hardware with the risk of incompatibility with the inits (FOS Linux virtual hard drive).

@jhalbert Understand I’m NOT recommending you turn off spanning tree, only change its mode to one of the fast spanning tree protocols. The fast protocols use optimistic blocking (forward first then listen for BPDU) instead of pessimistic (block while listening for BPDU) that standard stp uses. Is there a way to do it without changing the network, yes but it will require a little work on your part (honestly you need to enable RSTP to fix it for all). You will need to unpack the init.xz file. Its located on the fog server in /var/www/html/fog/service/ipxe directory. The instructions for unpacking and packing the inits are here: https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image Follow the 1.0.0 and up instructions. Once they are unpacked in the unpacked directory you need to edit a file in ./etc/init.d called S40Network. Just before the udhcpc command add in a line that says sleep 27 Save the file and then repack the inits and move to the /var/www/html/fog/service/ipxe directory. What that will do is have FOS Linux pause for 27 seconds on every boot to let the network settle before trying to dhcp boot.

@Bill-Rice You are safe to run the install in /opt/fogproject as needed. I’d suggest Copy the current /opt/fog/.fogsettings file to /root/.fogsettings Delete the current /opt/fog Copy the original server’s /opt/fog to the new server into /opt/fog as well. Copy the /root/.fogsettings to /opt/fog/.fogsettings file. Rerun the install to be on the safe side.

@samuel You can set a kernel parameter in the iPXE menu options to make machines shut down on deploy (or other tasks). Go to the FOG web UI -> FOG Configuration -> FOG Settings -> General Settings and add shutdown=1 to the field FOG_KERNEL_ARGS.

@Sebastian-Roth I believe there is a configuration where you can (ICH9 chipset + virtio-net network adapter)

@danblu3 said in Issues with cloning from 1TB HDD to smaller SSD: deploy began but exited on error 4 Can you take a clear screen shot of the error? The context of the error as well as the kernel parameters might help diagnosing the issue. Also can you post the output from these commands cat /images2/<image_name>/d1.fixed_size_partitions cat /images2/<image_name>/d1.minimum.partitions This will give the geometry of the original drive. Also just be aware that if bitlocker was enabled it could cause issues restoring to a smaller drive, plus you will need to enter the bitlocker unlock key to boot the new target system. Lastly depending on how the data is spread out in the partitions it may not be possible to shrink the partitions to fit the smaller media.