@wmw509 Disabling CSM makes sense. I’ve seen a lot of bioses that if CSM is enabled it only lets you use the legacy/bios pxe boot. I’ve had that disabled on all my hardware for so long I forgot it was a thing.

@FOG38640 said in DHCP option 67: Is there an option for FOG to automatically choose between BIOS and UEFI? For what? For the network boot file? If so that is done by your dhcp server. What is your dhcp server? (its been a few days so I don’t remember, a quick scan of the thread didn’t answer that question either) Edit: found it way at the bottom Windows 2019 server. So there is instructions for windows 2012 and later. Hopefully it translates to 2019 dhcp servers. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@Sebastian-Roth said in Feature request for FOG 1.6.x - Support GRUB as UEFI exit mode: So back to my point: Why would you chainload to another iPXE binary again for exiting? I don’t have a specific use case at the moment. So adding additional features without a specific reason may not be as valuable as I initially throught. Also I had a setback with grub. For some reason grub isn’t loading the config file that is uploaded, but using tftp to connect back to {next-server} (guess) and picking up the grub config file I had there. It is picking up the config file from there, I’m just not sure how it knows where to get the file from. Possibly from dhcp request. I’m still working with it, but grub isn’t quite as dynamic as I would have hoped to find uefi boot partitions.

@Matthieu-Jacquart Well that’s really interesting. It is known that Windows 2004 adds another revovery partition to the end of the disk. I have this on my list of things to work on for the next weeks. Though I cannot imagine how removing this partition can cause such issues you described here. It’s really over the top for a Windows installation to boot fine for a couple of times and then fail with such errors if it is for the missing recovery partition I would think. But well, I am a Linux guy and only scratch my head unable to understand the way MS is making up its world.

@altitudehack said in Smart Installer caching credentials causing AD lockouts - maybe?: It’s especially weird because I wouldn’t have been able to actually run the installer as a non-admin … Sorry for pointing the finger at FOG but it’s the only non-commercial software installed on this particular laptop that I installed under my non-admin account. Those two sentences don’t make sense to me. One is saying fog-client was installed using the non-admin account and the other says no. The fog-client installs a service that should run as local system account and not using AD-accounts at all. Though the fog-client is trying to join the domain on every cycle it runs. If your non-admin account is used as AD-credentials (FOG web UI -> host settings -> Active Directory) and the password was changed at some point I can imagine this to happen as described. But the AD-account would have to have rights to join a computer to the domain - don’t think a non-admin account can do this.

@Sebastian-Roth Hello, Sebastian, I believe the reason for why hostnames were not updating was due to the client not being up to date, however, after a name change, AD is still not updating, causing a trust relationship error when logging in and the domain does not change. Also, we a running 0.12.0 client version. Any other ideas on why AD is not communicating correctly? Thanks!

@george1421 said in Multicasting: @Goll420 bitlocker ref: https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/15 Very interesting, thank you. I imagine this was the problem for these machines.

The only way I was able to make it work was by loading the whole ISO file. :hbcd initrd http://${fog-ip}/images/tools/hbcd/HBCD_PE_x64.iso chain memdisk iso raw || boot || goto start by using the WinPE method I was able to boot but it couldnt find bootmgr in the wim file. I then tried to define the bootmgr and I was then getting errors regarding not being able to patch the wim file. in the end I just tried loading the whole Iso like with dban and lo and behold it worked, though it then limits you to a 2gb ram minimum setup.

@Tacolover99 said in New to this: Which I wanted but I notice that the internet was limited connected. So CMD, and found out the Thin Clint also inherited the IP Address from the other thin client. Check the original one and now that thin client is doing the same thing. Not to sure if it is DHCP problem when I cloned it. I think you need to explain this part in more depth. Probably best if you can post some pictures so we know what you mean by “limited connected”, “inherited the IP Address”, “doing the same thing”.

@dtkeith002 said in Acer Aspire A515-55 Connection Timed Out: Does FOG offer the ability to listen on multiple interfaces / ips at the same time? I haven’t dug into the config files to see. If so I can try a direct bridge to the server VM and bypass the network completely. Don’t think it’s worth going down that route. Testing on the same switch as the server should be enough to rule out most of the network related stuff. From the picture we see that it seems to be able to fully download the kernel (bzImage) file but times out on the initrd (init.xz). I would setup a mirror port on the switch and capture traffic on both ends - client port (using a notebook with Wireshark on the mirror port) and directly on the FOG server (e.g. using tcpdump). Use capture filters to restrict traffic to a particular MAC address (ether host aa:bb:cc:11:22:33). Please upload the PCAPs to a file share and post links here. If that doesn’t give us enough insights we might compile debug enabled iPXE binaries to analyze the TCP traffic - though this will a tough job! Have you tried using ipxe.efi yet?

Ran this from the Ubuntu 18 box: root@ubuntu18:~# zstdmt -dc </images/_Windows10Prox641909/d1p4.img | partclone.info -s - Partclone v0.3.11 http://partclone.org Showing info of image (-) File system: NTFS Device size: 9.9 GB = 2412369 Blocks Space in use: 9.6 GB = 2351625 Blocks Free Space: 248.8 MB = 60744 Blocks Block size: 4096 Byte image format: 0002 created on a: 64 bits platform with partclone: v0.3.13 bitmap mode: BIT checksum algo: NONE checksum size: n/a blocks/checksum: n/a reseed checksum: n/a

@Sebastian-Roth Just tested this out and it works. I just modified the inventory_report.report.php file to match your change. Thanks

For these new hardware you need to use the 5.6.18 kernel found under the kernels update menu in the FOG Configuration or you can upgrade by hand using the kernel link https://fogproject.org/kernels/ I would always use an official kernel instead of any one off link you might find.

@FabianN Just to make sure we are thinking the same, you can not get to the fog iPXE menu at all right? Another remote possibility is that you have standard spanning tree configured on the network port where you are trying to image this computer. For pxe booting FOG you should have enabled one of the fast spanning tree protocols (rstp, mstp, port-fast, etc) . Or some kind of green ethernet setting turned on. If its either of these cases you can test by putting an inexpensive (read cheap, like those home 5 port network switches) network switch between the building switch and pxe booting computer. This will mask the spanning tree issue.

@Sebastian-Roth Thank you very much for your help! After you pointed me to the right file, i found a very easy and good working solution. /var/www/html/fog/lib/fog/fogbase.class.php: Changed line 2305 from: $size = filesize($file); to: $size = exec("stat -c %s ".$file); I found this nice solution over here: stackoverflow Reverted my changes that i showed in the last post, restarted FOGImageReplicator service, and it works perfect! We know that this can’t work for forever, and Updates are also nice and good, so we need to change a few internal things, and also reinstall this Server with x64 Debian. Thanks for your great support. Keep up this very very nice project!

@george1421 Thank you lol, yeah the ips are still the same, we are working through it and will post the resolution.

@george1421 Sim, bem esquisito mas esta funcionando, so registro que nao esta funcionando corretamente neste caso ate troquei para BZImage412.

@rodluz Sorry, somehow I lost track of this topic! Here you go… @jtappen The picture you posted, is this in Hosts -> edit one host’s settings -> Active Directory or in Groups -> edit group settings -> Active Directory? If it’s the host’s settings then we can start digging deeper by looking into the database: shell> mysql -u fogmaster -p Password: ... mysql> use fog; ... mysql> UPDATE hosts SET hostPubKey='', hostSecToken='', hostSecTime='0000-00-00 00:00:00'; ... mysql> quit The password for the fogmaster database user is found in /var/www/html/fog/lib/fog/config.class.php.

@plegrand Testing internet connection is now done mainly with curl.

@alzen Well when you run sysprep it kind of resets the computer back to a neutralized condition. You can preset some values using an unattend.xml file you reference when you run sysprep. If you have ever installed windows directly from the dvd drive you know it asks a bunch of question before windows is setup. The unattend.xml file can be used to answer those questions ahead of time so it skips asking the installer the questions. This asking questions bit is part of OOBE (Out Of Box Experience) that is managed by WINdows SETUP. When you run sysprep it cleans out the system of drivers and settings that are important for that specific model of computer and reset its back to a discover new hardware mode. In my case I have 1 golden image for 15 models of hardware. I use a FOG feature to copy the correct drivers over to the target computer during imaging then when winsetup is running it finds the drivers and adds them to the windows configuration. WinSetup will only run when you reset the computer using sysprep.