@CHr57 First off you ought to make sure those machines are able to PXE boot. Check the BIOS/UEFI settings to see if the blades can boot from network (PXE).

DHCP is closely related to PXE booting and so FOG can be setup to host DHCP for you (asked when you run the installer) or you can say no and add DHCP option 66/67 to your existing DHCP server or you can manually setup dnsmasq to do ProxyDHCP if you can’t modify your exiting DHCP server.

The next step I suggest you do is setting up a test FOG server to check if the PXE boot works all the way through. I say this because FOG is relying on iPXE and the Linux kernel to PXE boot machines. Both have their own drivers (which we can also add for you up to a certain point) and there is no general list you can look up your blades to see if they work fine with FOG. In general 90% of hardware does work but there is always a chance of things not working out of the box or not at all.

They all should look the same, except name/IP.

There are three options you have for name changes.

• At the end of a deploy FOS (the FOG Linux OS doing the work) can update the Windows registry to rename the machine. This works for Windows 10/11 but I am not sure this is tested with Windows Server products. FOG web UI -> FOG Settings -> FOG Configuration -> … change hostname early … (from memory)
• Install the fog-client and let it do the renaming.
• The other option is to use WinSetup/OOBE/unattended.xml - not a FOG specific topic but you will find many posts in this forum and the web using this keyword in a search.

The other thing is changing the IP. PXE booting only works when you have a DHCP server and so static IPs is not something FOG needs to take care of usually. Though I guess you could achieve this through WinSetup/OOBE/unattended.xml or fog-client snapins (could break the communication right in the process though).

When we make any changes to the sw setup we would like to reimage all of them and and rejoin them to the AD.

AD join is done using WinSetup/OOBE/unattended.xml or through the fog-client (the same module that does the rename will also do a domain join for you when the settings are enabled).

@dyacishyn For some reason this is Sometimes broken. I shall see if I can fix this. Meanwhile I may ask you to upload the picture to an external picture upload store and post a link here.

@Baden-Skates said in Isolated Fog Server Removing M.2 From UEFI Bios:

… shutdown the device and add it to my production network and try to boot the device.
Once its removed from the server and I restart the device it no longer boots and the M.2 SSD that has the image doesn’t show up in the bios options.

Welcome to the forums!

I am not sure I understand the steps involved when you move a deployed machine to the production network. What do you exactly mean by “removed”? Deleting it from the FOG web UI? I don’t think there is anything wrong in what you do but I tend to try and make sure we unterstand the situation correctly.

My rough guess here is that the machines boot nicely into Windows when booted from network (PXE) because rEFInd is loaded via PXE and that is able to find the installation and boot it up.

You need to know that FOG does not care about or mess with the EFI boot entries so far. Some EFI firmware simply finds an installed Windows and will boot it no problem. But if this is not working out of the box you need to add some postinstall magic script to manipulate the EFI boot entries for you: https://forums.fogproject.org/topic/16703/dual-boot-2-disks-unable-to-boot-grub

@Koffinny Please be more specific on what version of FOG you installed as “the newest” can mean different things.

Did you say yes when the installer asked if you want it to setup DHCP for you. If you said no and already have a DHCP server in your network (the one you bridged to in VMware) you need to configure DHCP option 66/67 to make PXE boot work.

@jmeyer said in Update to last dev (1.6.0-alpha.1182):

Updating Database

Usually that’s the part where you need to open the web browser and let it update the database schema. Did you do that?

Do you run the installer with command line options or just plain?

@brakcounty A 6.1.22 test kernel is available on Github. Be aware those kernels are untested so far. I dod not have the time to even do the simplest bootup test.

@Fog_Newb Here you go: https://github.com/FOGProject/fos/releases/tag/20230331

Be aware those kernels are untested so far. I dod not have the time to even do the simplest bootup test.

FOG 1.5.10 was kind of re-released (technically just re-tagged on Github) just now to patch issues causing trouble when updating from an earlier version with the location plugin enabled.

@george1421 All those binaries are shipped with FOG and installed by default - see the list of ipxe binaries on github.

It’s more or less a question on which binary we make the default when generating the dhcpd.conf - which obviously not everyone is using anyway.

@Sebastian-Roth said in Which pxe file to use:

Should be update the default dhcpd.conf generated by the FOG installer as well?

@george1421 What do you think?

@dimoura At the risk of repeating myself, someone needs to make a commitment to maintain the docker image. This is not going to happen if everyone keeps asking for others to do it.

@jblomquist said in Is there a way to restrict FOG menu access to specific users?:

I’d like to allow a particular user to be able to deploy an image, but not quick delete a host through the PXE menu.

Which version of FOG do you use?

The quick delete option is secured in the iPXE menu in FOG 1.5.10 (github commit).

@AlexPDX said:

i see u did not find the time to fix the M.2 NVMe problem …and the Storage Nodes being Unauthorized

No, we haven’t yet. You are very welcome to get involved and help fix this stuff.

@brakcounty said in Very slow imaging performance on XCP-NG guest vm:

Are you referring to the bzImage kernel version? If so the kernel version I’m on is 5.15.93.

Yes. Just a hint: You can find out the version of kernel binaries by running file /var/www/html/fog/service/ipxe/bzImage* (or using whatever kernel filename you want to know the version).

We are planing to bring out a fresh new 6.1.x kernel for testing in the next week. Keep an eye on https://github.com/FOGProject/fos/releases for it to come out.

No idea if that newer kernel version will solve the described issue but it’s worth a try.

@JJ-Fullmer said in HP EliteBook 840 G9 - Cannot deploy image:

So at different points in the process of pxe boot, it gets a different mac when pass-through is enabled, I’d expect it to always use the passed-through mac.

Unfortunately there is not much we can do about it if we stick to relying on MACs as the (only) source of identifying hosts. This happens because FOG uses different “compontents” for the PXE booting and imaging process. The PXE menu (and first host recognition) happens with iPXE while when registering/imaging the Linux kernel is doing the job. Each using their own drivers and they can behave differernetly (not have to). Especially the USB adaoters and MAC pass-through bring up this as an issue more and more.

Probably someone with more time in the next months needs to dig into this old Github issue and give it a go: https://github.com/FOGProject/fogproject/issues/198

@george1421 said in What do I rename the T2 bzimage file to for reliable mac OS capture and restores?:

FWIW, I read (somewhere) the Mac T2 compatibility was going mainstream in the 6.x series of linux kernels, so this one-off patched version shouldn’t be necessary once we have the linux kernel 6.x version in FOS Linux.

Nice!!! We were going to bring out a first 6.x kernel soon anyway. Will post here when it’s done.

@AlexPDX This should be fixed in 1.5.10.3, so updating to the dev-branch should make this work for you.

cd /path/to/fogproject-repo
git checkout dev-branch
git pull
cd bin
./installfog.sh

Be aware that 1.5.10 is currently the latest master/official release. The mentioned dev-branch is meant as development branch of the code, though pretty stable (as of now - will be different when we get going with 1.6.x again). Just so you get the wording right and know what I mean.

@medchemii said in Capture not the entire disk but more than one partition:

is there a way to capture not the entire disk but more than one partition ?

The short answer is no. But there might be a way to achieve what you want on deploys. Though I have not tested this and I am not exactly sure this works. Figure out the partition number (start counting at 1), go to the image folder on your FOG server (usually /images/.....) and rename the file d1pX.img to .bak or whatever. Then try a deployment.

If this is not working and you are keen you can work on implementing this feature. Let us know and we can give you hints on where to look at.

As a side note:
The image type description in the wiki (I got there from the balloon help: https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Images) points to a non-existing page (404): https://docs.fogproject.org/en/latest/management/image-management.html

Thanks! @JJ-Fullmer would you find the time to fix that quickly?

@Punti I have never seen this error before. Doing a little search engine foo I came across this topic where they talk about an issue in the GnuTLS libraries used by git and that the whole issue was magically fixed (by Github?) in the end: https://discourse.pi-hole.net/t/error-git-remote-https-died-of-signal-4/56558/17

Though on the other hand this is really strange because I did give it a try in my Ubuntu 20.04 test machine and it does not run into the same problem. Maybe this really is a temporary Github problem??

@brakcounty Which version of FOG do you use and even more important, which FOS kernel version is installed?