@daansterckx There are a couple of things you want to check:

When the PC boots up, does it show the correct FOG server IP somewhere on the screen? On the FOG server run the following commands and post output here: ls -al /tftpboot/undionly* ps ax | grep -e xinet -e tftp netstat -antup | grep "LISTEN" | grep "69"

@jochenc98 What device is your dhcp server? Please state the manufacturer and version/model.

@george1421
changed to pm.max_spare_servers = 35
other paramaters had the correct value

The hardware :
PowerEdge R440
Intel® Xeon® Silver 4208 CPU @ 2.10GHz
memory size: 16GiB
network BCM57412 NetXtreme-E 10Gb

Just cross linking github issues here:
https://github.com/FOGProject/fogproject/issues/454
https://github.com/FOGProject/fogproject/issues/453

@lse said in Unable to capture image of w10 vm:

i do not know why it says at the end access is denied.

Not sure either…

Looking at the pictures they both show the very same size. While it’s not impossible I still find it suspicious. Maybe updating iPXE didn’t work as expected. Please run ls -al /tftpboot/ipxe.efi on your FOG server and post output here.

As for the rest, as long as it works in your organization there is no need to change because of what some dude on the internet says. From personal experience continuing to update a single golden image renders the image very messy and a bit bloated over time. But if it works for you, then there is no need to change.

Don’t get me wrong- I know that’s not an optimal way to work long term and we’re working on other solutions. I’m not disagreeing with that, I just don’t think there’s an actual problem with the MFT specifically. I’m not an expert on imaging or NTSF by any means though, so I could be wrong. I’m not trying to be hostile, I just want to understand since the MFT seems well below normal tolerance for Windows.

@sebastian-roth said in fog management console is blank:

You might want to take a look at @Wayne-Workman’s great install stats as well as the latest auto installer tests.

You can add AlmaLinux 8 and RockyLinux 8 to this list as I have tested those manually lately using dev-branch.

Very thanks for your advices.
I will to read Wayne-Workman’s postes and try with AlmaLinux 8 or RockyLinux 8.

Thanks

@george1421 said in Securing FOG Boot Options?:

@jra Now that I’ve had my second cup of coffee this morning I can explain it a bit more.

What the advanced menu and advanced.php does is insert a menu you create when advanced.php is called. You have to hand code the advanced menu and insert the text into a field in FOG Configuration->FOG Settings PXE Advanced Menu field. That field is then inserted after the #ipxe you saw when you called advanced.php directly (like I had you do).

I don’t have the skills to do this, but it would be great if you could construct the advanced menu like you do the standard iPXE menus by just changing the Menu Show with field, to “Show on Advanced menu”. Then you could move standard menu item behind the advanced menu right from the gui. That sounds like a logical feature to have, but right now the FOG Project doesn’t have the developer time to add that feature.

Right right - ok I’m with you. Have the workaround though and for now even the non-splash menu is functional, in the sense that curious students here can’t amuse themselves doing goofy imaging.

I am appreciative of the help so thanks much there. 🙂

I know that this is an old thread but please can a moderator link this to?

https://forums.fogproject.org/topic/12838/change-the-default-images-location

I found the former by Google and this fixed my installation.

Please feel free to delete my comment. I wont be offended!

Thanks.

@fgutvar multicasting is very much dependent on your infrastructure. Multicast packets are normally blocked crossing your vlan routers this is by design. For multicasting across subnets there is typically a multicast router in place. This can be the same or different than your vlan router. The processing of unicast and multicast routing are different. Some standard IP routers have an igmp proxy service that will run. It functions much like a dhcp-relay or dhcp-helper service does, but the igmp proxy listens for multicast traffic and not dhcp traffic.

@george1421 : Thank you very much.

In fact i’m used to regular pxe server and we use fog mostly for the cloning feature for windows Workstations.

To deal with Ubuntu workstations i like to do iso booting + pxe , this way i can mix/test configurations (preseed.cfg) of installation process quickly/easily directly from our gitea.

By the way i use fog as the main pxe server even for servers with debian based installations.

After this part of deployment ansible is the king of the hill to do all basics/complex tasks.

Can i modify the topic’s title with SOLVED ? Can i edit my posts to remove the domain’s informations ?

Regards.

@noobfogger said in Backgroundchange dont work -> black:

can anyone send me an custom background .png that i can test it?

http://boot.ipxe.org/texture.png
https://ipxe.org/_media/logos/ipxe-large.png

Both are used for testing by the iPXE team and should work. Though I have to say I have not tested those myself lately.

In ubuntu server 21.10 i had to change something in ~/fogproject-master/lib/ubuntu/config.sh -> “php-gettext” to “php-php-gettext” -> is maybe that the reason?

No, definitely not.

@psicodelico FOG was not made to support setups with more than s single network interface. While you can manually fiddle with things to make some scenarios work I am not sure this is true in your case. You probably need to explain in more detail what your setup looks like. Especially why your FOG server had 10 interfaces. You seem to want to combine FOG server and router in one system from what we know so far. Not a great thing to do I reckon.

Thank you sir

@Pilar Somehow lost track of this. You still run into this issue?

The output you posted seems file so far. What about exportfs -v (please post output here as well)?

Is 111.111.111.111 your FOG server IP?

Is there a firewall on the FOG server or somewhere along the route between host machine and FOG server?

if I change the path of the image in the node it does NOT create a new exports with the current

I am still not sure I understand what you meant here.

@sebastian-roth Thank you. I have not exchanged .efi for .*pxe, it’s what’s in the configuration by default. I’ve only added the “authoritative;” line and changed the UEFI 64 files to intel.efi instead of ipxe.efi. Also, I’ve also used snponly.efi which returns the same result with intel.efi. I decided to use snponly.efi for the meantime while on testing stage.

@handso said in Dell 5090 MFF restores during the capture process. HELP!:

The Linux Kernel is 5.10.71 Tom Elliott arm64.

I am just wondering about the arm64 part. Probably just what you copy & pasted when grabbing the version but I still want to bring this to attention.

So I did the capture through the debug method. Unfortunately no error message outputted on the screen during the capture. It happens around 8% of disk 3 being cloned. It just exited directly and restarted.

As George already said this is hardly ever the case with FOG. So we don’t have a simple step by step guide to debug this issue yet. There is a slight chance that updating to dev-branch can help because we updated the FOS inits to a newer buildroot version just recently. Though the Linux kernel version has not changed much (5.10.86) and I don’t think that’s gonna make the difference. But it’s still worth a try.

If that doesn’t help I suggest you take a video of the screen while capturing. Make sure you setup the camera/smartphone (on a pile of books for example) to get a steady recording. Some cameras even allow for 60 fpm videos. This way we might have a chance to see even a very brief error message flashing the screen just before it reboots.

@jshaver @george1421 Well done!

As far as the upgrade: although it seemed to finish with an error concerning updating the PHP components, the node showed the latest version in the console. Not sure what’s up with that, but it looks like the upgrade fixed this issue.

You might want to post the error log here so we see what went wrong and if it’s worth investigating. You find the log in /root/fogproject/bin/error_logs/...

@cparsons The short answer is you have 2 dhcp servers on your network and one of them are not handing out dhcp option 66 to the pxe booting computer.

Is your FOG server on the same subnet as your target computer?
What device is your dhcp server? (mfg and model)

@Rayco Thanks for letting us know. Though I guess we have updated this long ago. See this commit from 2018: https://github.com/FOGProject/fogproject/commit/b629d5ef15ae52f680fb5c7b99c53ee1da91aa5a#diff-6c19cefd5d36153992eb2ff3ad4873a91680a65ef783d8aa86751fea6f90ef29 (We have changed the URL to standards-oui.ieee.org despite Tom’s comment in that commit.)

I never had problems with mac list update, but in my last update FOG cannot open http://standards.ieee.org/regauth/oui/oui.txt because isen’t a valid link now.

You seem to be mixing up a few things here. First we need to know which version exactly you use and if you’ve manually modified the code already. The very latest dev-branch code is already using the URL you ask about. And this is the same if you’d use latest alpha from working-1.6 branch.