@mimi1255 If your current issues are not related to the original problem in this thread, please start a new thread - and we will gladly help you there.

@tlehrian It would be really great if you could test this fairly soon so we have a little bit of time in case it needs further work. The earlier we know the better! We can’t guarantee a quick fix some time in January when you really need it.

@Pascal-Gazaille Does this mean all the symptoms of not being able to deploy to the new disks disappeared?? Scratching my head… Will mark this solved for now anyway.

@Uncle-Frank You’re amazing! What you posted is very similar to what I came up with in a thread, but I haven’t gotten around to testing it. If you get dnsmasq to work with co-existence then you’re like… everyone’s hero… for real. Because if we can get a rock-solid dnsmasq config for all types of booting - then for 95% of fog setups out there, we’ve eliminated the need to change DHCP. Fog can then come with dnsmasq setup by default and it JUST WORK without further setup. In my opinion, Linux DHCP is far superior to Windows DHCP… but dnsmasq would be the ultimate solution if we could just get it to work.

The known good systems were extremely slow as well just like the new one using 3.12

Any other scripts I an run or ideas to get some usable info towards troubleshooting?

Well Congratz lol!

@sebastian-roth Hi sorry, I couldn’t answer any sooner. “Nevertheless we ought to try out using the SNP binary (debug enabled - DEBUG=snp:3,nii:3 to start with). So find 01_snp.efi here. Just give it a try and post pictures or video. Make sure when you take those to place the camera or phone on a stack of books in front of the screen so we have a good picture.” Here you go, not much to say from my side but here goes: video Thanks!

Thanks, Wayne!

@Sebastian-Roth Sadly I am out of surface go’s to test at this time. Gotta get the ones we have in production.

@marted Just want to keep this topic up as it might be very helpful for others. Not sure if you have time and access to systems right now though.

@lebrun78 Just be aware there is no way back to the 1.5.x version of FOG if you switched to working-1.6 now other than very messy manual manipulations in the database. We are working towards 1.6 and hope to have most users upgrade at some point. So I am not saying you shouldn’t. Just want to make sure you understand the consequences.

That did work!! Hallelujah! Thanks vinyard and Tom!! I ran the following commands and now its uploading that first image: systemctl status nfs-server systemctl enable nfs-server systemctl start nfs-server Thanks guys, success at last!

@hugothebas This article applies to 1.2.0 and below: https://wiki.fogproject.org/wiki/index.php?title=Advanced_Boot_Menu_Configuration_options

No idea ?

@george1421 A Merry Christmas and a Happy new year to you guys.

@Tune389 said: @ch3i okay thanks for the info. I try now to downgrade my fog version back to 1.2 … That’s not supported nor advised… To “downgrade” requires either restoring a previous snapshot (via a virtual machine) or rebuilding your FOG server from scratch…

Again, anything to report?

Good to know. So it seams to only cause problems with a distinct combination of curl and openssl version(s). Possibly the newer curl version works around an openssl bug or the other way round… :-D

@austinjt01 Ok that is a great starting point. I’ll again refer you to my tutorial: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed Look at the fog.custominstall script. Start with that script and then in this section add your code: echo "Done" debugPause . ${postdownpath}fog.copydrivers # . ${postdownpath}fog.updateunattend umount /ntfs Remove the call to the fog.copydrivers and fog.updateunattended and insert your code. At this point in the code /ntfs has been mounted onto the windows (C: drive) partition, wherever it may be. The script takes into account nvme vs sata as well as partitions being in different order or locations.