@Sebastian-Roth thank you for pointing me at the DHCP! I found the problem! All files are fine, but our company DHCP was not! After trying it in a seperated VMware Network it worked like a charm! So all the effort was in vain - i am sorry

We have an old fog running 1.4.4 in our DHCP config for managing the PXE Menu because we are running multiple (i)PXE Services in one subnet. I created a new boot menu item to forward the pxe boot to the new fog server.

like this:

iseq ${net0/mac} a0:36:9f:bd:XX:XX && goto testing || :testing set pxeserver:ipv4 FOG-IP set next-server ${pxeserver} chain tftp://FOG-IP/default.ipxe exit

Got it from here in 2017: https://forums.fogproject.org/topic/9648/add-a-second-pxe-boot-option

Worked fine, until now … And by now, i understand why no certification cmds were availibe because it got stuck in the old fog enviroment. Need sth. to reload the enviroment i think. I will take a look into it to find a way. Maybe i will open a new topic here!

Thank you @Sebastian-Roth for taking the time! Your scrips are fine - it was my fault …

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, let’s call it quits. I just pushed a commit to the fos repo to add this patch to our build of partclone and add the ignore_crc parameter back to the scripts.

Marking as solved.

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.

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.