Guys, during the struggle to reproduce the issue somehow i found something strange. Let me describe it. Starting point: host has a valid mac, up to date. i want to change mac. It can cause 2 different output, and i think it can cause the result somehow (i will do more tests to see if it really happens, but the difference made me curious). mac update method1: host primary mac field is the only field, no additional field. i select the full field, then overwrite mac. result is a new mac on primary and an additional mac field appears with the previous mac address (which is wrong, as it has no another, but a new mac actually) mac update method2: same starting point, but i only use mouse click to the end of the field, without selection of any char i use backspace, for like 1 char, and type another char instead of the deleted one. here NO additional mac field comes to existence. why? if i change the mac any method i want to change it, not add a new one (i will make test with it, maybe this way it will disappear somehow) EDIT: sorry, somehow i did not notice what you wrote before me.

Yes, there’s a syntactically incorrect sql stament. The statement should be: [code]delete from tasks where taskTypeID=‘8’;[/code]

@Wayne-Workman That’s odd. I know that I had to create a different profile for LTSB but it certainly worked in LTSB. The profile I made in Win 10 Enterprise CB won’t work in LTSB and vice versa. Gotta create a new one. It’s lame I know. My login times are much longer than 4 seconds though. But I have a lot of customziations. Little common fixes and startup scripts and backgrounds and stuff, so my first login for any user is like 2 or 3 minutes, but only a few seconds after that first time.

@sjensen i tried sudo at the start of the string. I am getting could not open lock file /var/lib/dpkg/lock - open (13: permission denied)

@AsGF2MX said: I actually didn’t have to use the has usb nic parameter for any unit. I used the USB-0301 as mentioned earlier and it didn’t complain on any of the units I had imaged with FOG. Wow… who would have thought? Wonder why it worked? I’ll be adding your isc-dhcp configuration to our WiKi sometime today, to the BIOS & UEFI coexistence article here: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

@dholtz-docbox On Dells, they can be in UEFI mode, but if legacy option ROMs is enabled, that UEFI system will boot from something like undionly.kpxe. But when this happens, it will never properly exit to a GPT disk. I’ve seen this before at work. Most likely, the answer here is to configure DHCP to hand out only ipxe.efi.

@Sebastian-Roth Yeah I was thinking the same thing. So now that tablet is booting reliably every time. I’ve moved to another one and it’s getting the errors again. This is totally a tablet-related issue and not a Fog related one.

@Sebastian-Roth I don’t have deep understanding of FOG internal works, but I can say that when option 67 was set to prelinux.0 the kernel panicked.

@Tom-Elliott Yes, I just did. I marked it as unsolved when it broke again.

Ok, marked as solved for now. People who want to keep following, see here (mind this is about PXE booting a Surface 4 now).

Either portfast/RSTP or you can try using iPXE with native driver support. On your DHCP server change bootfile option from undionly.kpxe to ipxe.pxe and see if it makes any difference.

I know this is an old topic but as a friend of mine asked me about HTTPS in FOG recently I felt that I could update this thread again. If you run the installer with --force-https you need to run another script afterwards to build the iPXE binaries and include your SSL certificates. cd /path/to/fogproject_gitrepo/bin ./installfog.sh --force-https ... cd ../utils/FOGiPXE ./buildipxe.sh ...

Glad to see this is fixed. I helped to the extent of my abilities via forum chat but I came to a dead end basically. And Tom’s post explains why. Good to see a solution is found.

Wanted to post another update. Updated to 6893 this morning. Removed my sleep and service stop commands from rc.local and rebooted. CPU seems to be in check again. Thanks for all your hard work!

If a user is logged on to a client machine the only way I can schedule a FOG upload is to send a shutdown/restart command to the client machine via the Linux scheduler.

@Wayne-Workman I believe that would be a right thing to do.

@bmaster001 said: So you guys have plenty of time to think about this weird piece of hardware, and I’ll get back to this thread when we have more devices to play with! I don’t think we are able to push this anywhere without having the hardware around or someone like you who are willing to test things out.

@Tom-Elliott I believe everything else is working fine for now.

I have the same issue on the Realtek 8168. But this is all under hyper-v. On my old pc, with intel NIC, everything worked fine, but now on my new PC with the Realtek 8168 I am running FOG as a virtual machine and a PXE client on. All on hyper-v. It looks like hyper-v inherits the properties of the host system, even with private networks. When using EFI it all works, just not on a legacy NIC.