Hey Tom, take your time and get yourself settled!

I am wondering if this is a good point too where we reach out to the community for people to join into the FOG team to help work on the code, fix issues, improve stuff here and there.

@Tom-Elliott, @Developers, @Moderators
I got carried away trying to improve the current iPXE script. Now that I’ve dug into the syntax and found some interesting new stuff I want to see what you guys think about this:

#!ipxe
isset ${net0/mac} && dhcp net0 || goto dhcpnet1
echo Received DHCP answer on interface net0 && goto proxycheck

:dhcpnet1
isset ${net1/mac} && dhcp net1 || goto dhcperror
echo Received DHCP answer on interface net1 && goto proxycheck

:dhcperror
prompt --key s --timeout 10000 DHCP failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

:proxycheck
isset ${proxydhcp/next-server} && isset ${next-server} && echo Duplicate option 66 (next server) from DHCP proxy and DHCP server && echo Using IP sent by DHCP proxy ${proxydhcp/next-server} && prompt --timeout 5000 || goto nextservercheck

:nextservercheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} ||
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

:netboot
chain tftp://${next-server}/default.ipxe ||
prompt --key s --timeout 10000 Chainloading failed, hit 's' for the iPXE shell; reboot in 10 seconds && shell || reboot

Feel free to comment and improve. I’ve tested the script and tried to remember all the issues I came across in the last months but I am sure we’re not there yet.

@TrialAndError said:

Obviously the development of FOG stopped after a long time of hard work.
It would be friendly by the developers to inform the users about that.

I am not sure what exactly you mean. This is an open source project and we have no time schedule for new releases and we don’t have a set list of features to add or bugs to resolve. We simply do what we can and like.

It’s quite bizarre to state that FOG development stopped… totally wrong!

I want to thank Tom again for this! I tried to assist and help but I just don’t know the code (and its history) as much as Tom does. He’s done all the hard work to find and fix this issue. Along the way he also fixed a couple other things as well.

@Tom-Elliott Don’t say sorry. FOG is work in progress and you are pushing things way forward!! :metal:

@Wirefall Great you posted the full kernel messages listing. At first I didn’t notice any issue but looking closer I found the issue:

igb: probe of 0000:01:00.0 failed with error -2

The PCI ID perfectly matches the one you mentioned in your fist post. Didn’t take long to find several reports on this issue that came in just lately:
https://lkml.org/lkml/2016/11/24/172
https://bugzilla.suse.com/show_bug.cgi?id=1009911
https://patchwork.ozlabs.org/patch/700615/

Some say that it might possibly work if you disable PXE boot for this NIC in BIOS. I don’t think this is a great solution as FOG heavily relies on PXE booting the clients. Let’s hope that this will be fixed in the latest kernel fairly soon!

@sudburr Why not re-install the whole system from scratch?

@Developers @Moderators Ok, I just opened a pull request to remove the 7156 binaries. Please all keep that in mind. Might cause some minor confusion in the next weeks. But it’s good to get rid of it.

As you all can see the tests of the most recent iPXE version shows that things are back to normal again. I reported back to Michael Brown on the iPXE devel mailing list. So he’s got that in mind as well.

@Avaryan To me this sounds like a different issue. Would you mind opening a new thread on this and posting more details (FOG version, USB ID of the NIC used as shown with lsusb, …).

I’ll mark this solved/closed now. @Psycholiquid Thanks heaps for the great work on testing all the binaries and such!

@Jean-Jacques-Morda Why do you have more than one DHCP server in your network? And why do they offer different information (next-server/option 66) to the clients. This is not strange but kind of expected and it just does not make any sense to me why you would want to have this.

@Lenain As Quazz said it would be good to know which version of FOG you use. There have been many changes in the code to support this kind of disks in the last months. So if you still use FOG 1.2.0 it won’t work for sure. Best if you run the latest release candidate.

Did you set /dev/nvme0n1 as disk device for that host in the host configuration (web gui)?

Trying to get all the pros and cons of changing the current setup of using fog linux user account as we have it at the moment.

As we answer many questions just because people keep using the account and change the password I wonder what can be done to prevent from that.

@george1421 @Wayne-Workman Just moved your other posts here so we have it together in one place and not fill up the users request on how to fix his issue. Open for discussion. :-)

@hj104 I have just tested on a fresh install and both delayed and cron-style work perfectly fine. My log looks like this:

cron-style / * * * * *

[01-18-20 10:31:05 pm]  * No tasks found!
[01-18-20 10:32:05 pm]  * No tasks found!
[01-18-20 10:33:05 pm]  * No tasks found!
[01-18-20 10:34:05 pm]  * 1 task found.
[01-18-20 10:34:05 pm]  * Task run time: Sat, 18 Jan 2020 22:34:00 +0000
[01-18-20 10:34:05 pm]  * Found a task that should run.
[01-18-20 10:34:05 pm] 		 - Is a host based task.
[01-18-20 10:34:05 pm] 		 - Unicast task found!
[01-18-20 10:34:05 pm] 		 - Host hostname
[01-18-20 10:34:06 pm] 		 - Tasks started for host hostname!
[01-18-20 10:35:05 pm]  * Sending 1 wake on lan request.
[01-18-20 10:35:05 pm]  * 1 total mac attempting to wake up.

delayed task set to 22:37 (10:37 PM):

[01-18-20 10:35:06 pm]  * No tasks found!
[01-18-20 10:36:05 pm]  * Sending 1 wake on lan request.
[01-18-20 10:36:05 pm]  * 1 total mac attempting to wake up.
[01-18-20 10:36:06 pm]  * 1 task found.
[01-18-20 10:36:06 pm]  * Task run time: Sat, 18 Jan 2020 22:37:00 +0000
[01-18-20 10:37:06 pm]  * Sending 1 wake on lan request.
[01-18-20 10:37:06 pm]  * 1 total mac attempting to wake up.
[01-18-20 10:37:06 pm]  * 1 task found.
[01-18-20 10:37:06 pm]  * Task run time: Sat, 18 Jan 2020 22:37:00 +0000
[01-18-20 10:37:06 pm]  * Found a task that should run.
[01-18-20 10:37:06 pm] 		 - Is a host based task.
[01-18-20 10:37:06 pm] 		 - Unicast task found!
[01-18-20 10:37:06 pm] 		 - Host hostname

Note that those times around midnight are definitely incorrect, I was not working on it at that time

While I am not sure this is causing the problem I would definitely try to start looking at this first. You said you have checked timezone in the FOG GUI. Do we talk about TZ INFO in FOG Configuration -> FOG Settings -> General Settings? After changes here you need to restart the scheduler service (systemctl restart FOGScheduler).

The PHP time is correct I think, I tested it by creating a .php file that does “echo date(‘Format String’, time());”

Did you run this on the command line or on the web server? If it was command line that might be different to what you get on the web server because configuration can differ. So please try this code on the FOG web server:

<?php
    $tz = new DateTimeZone('Europe/Berlin'); // use your timezone identifier here!
    $d = new DateTime('now', $tz);
    echo $d->format('m-d-y g:i:s a');
?>

@Matthieu-Jacquart said in Host Screen Resolution:

Now there are just thousands of lines with same output

Really thousands? So it seems like the enumeration loop doesn’t exit properly. Sorry for that. Next try…

EDIT: Give it a try but it’s probably not much better. I need to do more testing on this myself to figure it out. Won’t have enough time right now. Maybe next week.

@Matthieu-Jacquart said in Host Screen Resolution:

Current Resolution: 0 x 0 0hz

This seems to be a bit stange.

Display name: Generic PnP Monitor

As well I am wondering if this really is the correct display on your PC.

So I went ahead and added more code to figure this out. Download new module and try again. Log output will be long, post it here.

@JoshA @Matthieu-Jacquart Ok, looking through the code I think I found an issue and fixed it. Please download the Modules_fix01.dll, stop FOGService on the client, move the new DLL to C:\Program Files (x86)\FOG\Modules.dll (rename the original one before). Now start off the FOGService again and take a look at the log. Post output here.

@nextechinc said in NUC10 NIC Compatibility:

I’ve tried a variety of the most recent kernels to no avail.

Please post a picture of how far you get in the process of booting. Any error message?

@ty900000 said:

A few days ago, the init from Jenkins and using Uncompressed would throw the error when it deployed - the image above about /dev/sda3.

I guess you mean this error:

That would mean the capture did run fine and partclone did not segfault when capturing. Though we probably can’t figure out which version it was you were using back then as too many things were tried in a rush. Nevermind.

I currently am using the init @shruggy suggested yesterday …

@shruggy Would you mind telling us which version of partclone this is?

@ty900000 said in Development FOG not capturing image - PartClone update:

I did test with several of the other compression types. As far as I can figure the Partclone Uncompressed is the only one that throws the above error with the 1 minute time out.

and…

I pulled the latest init just now, too. Using both uncompressed and Zstd
… picture with segmentation fault …

Those two answers don’t add up for me. Can you please do a simple test with the different compressions (none, Gzip, Zstd) and post which error exact you get for each.

@Lala-A-C I’d suggest you download the latest version of rEFInd (0.11.4 as of now), extract the archive and copy the binary refind_x64.efi to your FOG server in directory /var/www/html/fog/service/ipxe/.

Then try booting the client again.

@Matthieu-Jacquart Can you please post the full log here? Is this the same message for DisplayManager all over the log?

@hj104 said in Scheduled Tasks (Delayed / Cron-style) not working, but instant tasks are.:

then sent an instant WOL

Did you send the WOL by itself or just an instant task?