@Wayne-Workman DATE() returns the date without the timestamp. So it will be assumed to be 00:00:00 Use just NOW() and drop DATE(), so that it is updated more accurately.

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.

@george1421 While I like the idea of not having to embed the grub.cfg file into the binary - for users’ convenience to be able to edit the file - I would like to have the grub modules within the actual binary (its memdisk). It’s just my guts saying this might be more reliable if modules don’t need to be loaded separately.

@wmw509 Would be interesting to see If it reports a different platform if your pfSense also hands out the UEFI binaries as mentioned by George! There are two more things coming to my mind. First I am wondering if there is some confusion about the wording. Host can mean different things but in the FOG world it’s used for the Client machines that PXE boot for deploymens. So I am wondering if your Ubuntu server system is your FOG server or really one of the PXE booting systems. Second I may ask you to schedule a debug deploy task. Same as If you create a normal task but Just before you click the create button in the FOG web UI there is a checkbox for debug mode. Now PXE boot the machine in question and wait for it to give you a Linux shell. Run the ls -al /sys/firmware/efi command in there and report what it looks like.

@Huecuva that is a good question I don’t think I have a great answer too sadly. There’s probably a way but I haven’t actually found one other than comparing file sizes of the binary. There’s probably metadata in the file somewhere to access the version.

@x23piracy said in First default domain admin login never ends when FOG (1.5.0) joins to domain (FOG Client 0.11.15): Is it possible that this has something to do how the older FOG Client technically joins into domain or what could be the reason here? That’s a really good question. Though I can’t give you a clear answer. There have been changes in how the fog-client attempts to join a domain but all of these code changes were before 0.11.15 was released in February 2018. Usually I tell people to update to the latest version of FOG/fog-client and try again but I suppose this is of not much help here. You might want to study that code on github and try some search engine foo to get an idea if there are other methods to join a domain. Though it would take a lot to convince me to use a different method which has not gone through any testing yet. When i deploy the image without letting FOG join the device to the domain i can logon the default domain administrator without any problem. I suppose this implies manually joining the domain, right?

@Tom-Elliott said in Fog V1.5.9.29 Active Directory Defaults for OU not populating Database: but in the edit the option is selected from the list and that applies it properly. Do you mean when selecting it from the drop down manually or when clicking “Join Domain after deploy” to apply the default values?

@george1421 @Goll420 I have worked on the multicast tasking/finishing code just before the release of FOG 1.5.9 because there were issues when you schedule a test not via the group but by creating a named multicast session. I thought I had this all tested and working correctly but I might be wrong. I will need to get a test setup ready and see if I can replicate the issue as described.

@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.

@Matthieu-Jacquart Thanks for the update. I still can’t make sense of it. Just to make sure I may ask you again - try using non-resizeable image type to see if this spikes the exact same issues. another strange behaviour, this one worked fine 10 minutes and supports few reboot What exactly do you mean by this. Sounds like you tried just rebooting the system several times and that worked fine but at some point it fails, right? Where does gparted and with that ntfsresize (as seen in the picture) come into the game? As far as I see you haven’t told us about manually resizing before.

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