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.
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.
@Tutungzone Maybe there is a quick fix for this issue. It’s been some time since we updated the RAMDISK size and I guess this could fix it: Go to the FOG web UI -> FOG Configuration -> FOG Settings -> TFTP Server and set KERNEL RAMDISK SIZE to 275000. Save settings and try booting into a task again.
After a certainly too long period since the last release we finally announce the new FOG 1.5.10:
https://news.fogproject.org/fog-1-5-10-officially-released/
Thank you very much to everyone devoting time to help getting this ready!!!
Find all the details in the new release notes…
This version was re-released (re-tagged) on 31st of March 2023 to patch issues with the location plugin that would cause trouble when updating from an earlier version.
@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.
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:
@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!
@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!
We are working towards a most stable release of the 1.5.x line of FOG and will publish release candidates of FOG 1.5.9 for this over the next weeks. We ask people to participate and help test to get the final release as good as we can.
@alexamore90 Is this a typo with IP, gateway and DNS all set to the same address?
You might want to run systemctl status isc-dhcp-server
(Debian/Ubuntu) or systemctl status dhcpd
(Redhat based distros) and post output here.
@alexamore90 Did the installer finish all the way to the end? When running it there is a point where you need to open the browser and let it populate the database. If you skip this the installer will fail and needs to be run again.
The node offline sounds like the installer didn’t finish properly.
@ksrvpvl As soon as the machine is registered in the FOG web UI a task can be scheduled. This would send WOL packets to wake up the machine and let it PXE boot straight into the scheduled task.
@Tauric From the pictures we see that FOG recognized the filesystem as NTFS and should be able to resize it. It’s still strange the size was larger. Good you got this fixed by reinstalling the master to capture from. No idea what could have been wrong with the other one.
@tomynocker Looks like you used the wrong field. Such an options need to go in Kernel Parameter.
@matthewadams12 It depends on the partitioning and filesystems used. If Ubuntu is installed with LVM it will be captured sector by sector (large). But if you choose plain GPT or MBR partitioning FOG should be able to capture the used space only.
@w2log Does this SuperMicro X12 have more than two NICs onboard? Then it’s probably a bug in FOG fixed in the latest dev-branch version already.
@infotc While a clean migration would surely get you to a nice clean system you can first try to get this fixed manually.
There is some logic in the FOG installer that should take care of the different package names that have changed over the years (php-mysql vs. php-mysqlnd).
Please run the following command to see what PHP packages exactly are installed at the moment:
dpkg -l | grep php
Post the output here.
Edit /opt/fog/.fogsettings
and make sure only php-mysql
(but not php-mysqlnd
) is in the packages line.
As well you might want to manually install the package needed - see if that gives you an error as well:
apt install php-mysql
@lan Which version of FOG do you currently use?
Quite possibly this is fixed in the latest dev-branch version already (fix on github).
@ludlud Do all the machines come back on or just some of them?
Check the log in /var/log/fog/fogscheduler.log
to see if jobs are somehow scheduled - like a plain WOL type job.