Sort of a side note but advanced task debug download/upload should also now work properly.

@Sebastian-Roth I removed the “revertbcd” script of Tom. Remove old image with file Create image fog-windows7 - 16 default: Windows 7 Single Disk - Resizable Everything- Associate image to client Associate image to client Launch Basic task capture Capture works fine and windows start normally Launc basic task deploy … It works !!!

@K.Hays When booting into FOS this way we only need to ensure that the FOS kernel is updated to support new hardware. So as the developers release new version of the FOS engine all you need to do is download these files and move them to the previously created usb flash drive into the boot folder replacing the existing files. https://fogproject.org/inits/init.xz https://fogproject.org/inits/init_32.xz https://fogproject.org/kernels/bzImage https://fogproject.org/kernels/bzImage32 In regards to the usb network adapters. When you pxe boot uefi devices you MUST use network adapters recommended by the manufacturer to support pxe booting. When you usb boot into FOS you will have better luck with older USB 2.0 network adapters since those are most likely supported by the linux developers.

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)

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

@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

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

Got a response from Chris about this. His tests were fine too and as we don’t seem to have anyone else willing to test I am “closing” this topic as solved now. There has not been a response from the partclone devs either. I just just updated the issue and hope that we get this merged upstream as well.

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!

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

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.

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