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.

https://news.fogproject.org/fog-1-5-8-officially-released/

https://github.com/FOGProject/fogproject/releases/tag/1.5.8

https://news.fogproject.org/fog-1-5-9-officially-released/

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

https://news.fogproject.org/fog-1-5-9-rc2-available/

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

@brakcounty I still have not found enough time to do a test setup…

Out of curiosity, what NICs do you typically run ipxe on?

The default on Linux virtualbox: Intel PRO/1000 MT Desktop (82540EM)

@george1421 said in using deploy image via pxe with more than two nics:

specifically around this line https://github.com/FOGProject/fos/blob/e3e7e93cc249a92b512862f308481f1ee055740d/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L63 mode needs to be quickimage for “image deploy”

I guess you found a old bug thas has been in the code for a very long time. There really is no script called fog.quickimage in the FOS inits. Should be in /bin/ but there is non. So to me it seems like when the quickimage case is called it’s just ignored and fog.sysinfo is called.

The name was even updated in the schema at some point: https://github.com/FOGProject/fogproject/blob/65fe719e58f89398a1e3f45412d7305993eb282e/packages/web/commons/schema.php#L3315

@JJ-Fullmer said:

I tested this in a VM and recreated the problem. It didn’t matter if 1 or all adapters were connected, if 3+ exist on an unregistered host it behaves as @mosi describes.

What kind of virtualization do you use? I was not able to reproduce this on virtualbox yet. Seems like I am doing something wrong because when I get to an iPXE shell and let ifstat list the network interfaces I only see net0.

EDIT: Ok, got me. When using the default iPXE binary undionly.kkpxe this is not happening because it seems to only detect one network interface. Switching to ipxe.pxe brings up the same issue for me. What I noticed is that when you are asked to enter username and passwort to authenticate before the image deploy you submit with ENTER but get back to the same password dialog again with the information entered already. So hitting ENTER once again finally gets you past the authentication screen?!?!

EDIT2: Same problem when trying to join a multicast session on a VM with three NICs. Two NICs does not cause the trouble for deploy or multicast. Moving this to bug reports.

@Kleber I guess the spacing of the information printed is not working as intended when the status bar is just started. I played with the stuff a bit and came up with an easy solution that would expand the text information to the whole width but restrict the green status bar to the lower part:

Would that be a feasible option? If not then some else with more status bar skill needs to look into this.

@AlexPDX @george1421 @Tom-Elliott Great we got this figured out. Please let us discuss the details on github: https://github.com/FOGProject/fos/issues/72

@AlexPDX said in Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify:

HDIO_GET_IDENTITY failed: Inappropriate ioctl for device

Yes, surely we need to use a different command to get that information, e.g. nvme id-ctrl /dev/nvme0n1 | grep mn or smartctl --info /dev/nvme0n1 | grep Model (https://sleeplessbeastie.eu/2022/03/21/how-to-display-information-about-nvme-storage-device/)

@ricardomartins Does this happen with all your client machines or just particular ones?

What is serving DHCP in your network?

@plegrand Good you are asking. Going forward is always supported. So in your particular case coming from commit ddb9904a7 (version 1.5.9.111) you can safely switch to the master branch and then follow the known update commands:

cd /path/to/fogproject
git checkout master
git pull
# Make sure this succeeds as it can fail when you have made changes to the repo files,
# e.g. compiled ipxe binaries. If this fails, then you can drop all modifications using "git reset --hard HEAD"
cd bin
./installfog.sh

@Tom-Elliott said:

dmidecode (which I believe is what pulls all the inventory data) might just not know how to detect the specific information from that NVME either because the manufacture didn’t fill out the items that dmidecode is looking for, or is using a different language that can’t be utf decoded.

Pretty sure Tom is right here. Just had a quick look at the scripts and turns out we use hdparm (code ref) which might not be able to grab the information from NVMe disks per se.

@george1421 said:

the nbdX devices have me confused.

You are right. I am wondering if we added this kernel feature when updating to a newer LTS line at some point. I don’t think we need it. Though it’s always good to make sure. So here is the github commit that introduced those features years ago when we moved from 4.5.x to kernel 4.7.x: https://github.com/FOGProject/fos/commit/b56b8d9f6356f6e702e6ff580b2c4500f27ac41f#diff-15f9b0e5270fc1caac75f8b936c3df11534ceeb08de376b7a72b38c75ff2ad1aL1122

@Tom-Elliott Do you remember if this was added for a reason? Not saying this is an issue at all. Just wondering if we might think about removing it to further slim down the kernel binaries?

@jmcnamee Please let us know if you need futher help with this.

@Romain-0 Please let us know if you need further help on this topic.

Veuillez nous faire savoir si vous avez besoin d’aide supplémentaire sur ce sujet.