Topics created by michaeloberg

@Tom-Elliott I think this post helps fix the issues:
https://forums.fogproject.org/post/154920

@sebastian-roth Correct, expect this time I am not importing the DB from my old fog server, new server, new images, new everything. I will open a new topic specific to the HP Probook 430 MAC Address Passthrough issues.

Thanks Sebastian for your help, I appreciate every you do for the FOG Community.

Mike

@george1421 Hello! I fired up a new VM and installed Debian 10.11 (buster). I did a modified installation from the YouTube video you shared, I did partitioning based on this video - https://wiki.fogproject.org/wiki/index.php?title=Debian_8

I installed 1.5.9 and setup the DB and changed the fog default password.

My next question is - can I export my settings off of my old FOG server into the new one? Currently I have both VMs fired up so I can simply toggle between the two IPs in a tabbed browser.

Once I get the new server setup, I am going to change my DHCP and PXE settings on my Windows network to test PXE booting my new computers that use the USB dongle. I am going to be beyond thrilled if this works as I have several hundred of these machines that need imaged.

Thank you so much for your help and look forward to your response!

Gratefully,

Michael

@michaeloberg said in Issues with USB Type C NIC Adaptors:

@kghli @george1421 @Sebastian-Roth

This could be a breakthrough. I just noticed that the system is passing the address through iPXE correctly and that FOG is what is recognizing the USB Type-C dongle’s MAC address - the exact scenario that @kghli is experiencing. I took a screen shot of the issue and here is the iPXE address (which is the correct system address):

3e42e174-18f4-40d4-80a0-22714580ef00-image.png

Then when I boot to FOG (now running Debian 10.11 and FOG 1.5.9, and choose “Client System Information” then choose “Display MAC Address” it show’s the USB Dongle’s MAC:

e70169a5-6a1d-4983-be3c-9d9a7dea4c9e-image.png

Hopefully this is going to help troubleshoot our issues as we have narrowed it down to FOG alone, not the manufacture of the system, the BIOS configuration or the version of FOG.

Thanks in advanced!

Mike

I also recompiled iPXE from (g4bd0) to (g1844a) and verified the date (ls -la /tftpboot/*.efi) was today and it still is not working.

Turns out the DNS server was not ser correctly and the server got it’s IP via DHCP. We got that fixed.

@michaeloberg Interesting workaround you cam up with! Using dnsmasq for legacy BIOS machines (undionly.kpxe) and Windows DHCP for UEFI ones (ipxe.efi). While it seems to work properly I am fairly sure this will be failing one or the other time because both send out PXE boot information and this is known to cause trouble.

As George said, would be good to get the packet dump (pcap) to understand what’s going on. For that you’d disable option 66 & 67 on your Windows DHCP, install tcpdump on your FOG server and capture the packets while PXE booting the legacy BIOS host first and when it waits at the iPXE menu try booting the UEFI machine too and stop the packet dump just after that ran into the error.

@michaeloberg Did you ever solve this?

set the IP adress of the fog serveur
instead of the name “fogserver” at the install of the smartinstaller and enjoy 😄

@Tom-Elliott Thanks again, I am by no means a Linux expert, I wouldn’t even be considered a novice.

Michael

Thanks everyone, I upgraded to the newest version of Fog, and had to do the following and now it works:

Windows 8.0, 8.1, and 10 (and most likely future Windows versions) have a feature called “Fast Startup”. This feature basically sets windows so that a hibernation occurs whenever the system is shutting down. This enables Windows to startup much faster than in past Windows versions. Because this feature is on by default, the windows OS partition has a hibernation file which prevents mounting and imaging via FOG, and also marks the OS partition’s “Dirty Bit” to ON. Even when hibernation and fast startup is disabled, the hibernation file remains and the “Dirty Bit” remains ON and these things causes problems. There are a few ways to fix/get around this.

Way 1 (clean method)
Disable: “Turn on fast startup”, located here: Control Panel (Classic View) -> Power Options -> Choose what the power button does -> Change Settings that are currently unavailable -> “Turn On Fast Startup & Hibernate”

Both of those settings should be turned off for use with FOG. They may be turned on at a later time via GPO or snapins.

Shutdown and then boot the system.

Then run this command from an elevated command prompt to disable hibernation and remove the hibernation file:

powercfg.exe /H off

Now you can shut down and reboot once or twice, and then capture your image via FOG.

@michaeloberg use the Git method here to upgrade: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
No it shouldn’t mess up your current installation. If you want it to break your current setup, just let me know and I will show you how.

This works now. Thanks All.

@michaeloberg I’m guessing it ran out of IP addresses to hand out?

Man thank you so much, we have our students save their files on SD cards and man does that screw with the mounting process for drives in FOG. Never even thought of that and my employee said today what if we take the card out, problem solved.