@chevengur there is not enough information to help you in that picture. If we could see more of the error message that partclone threw (i.e. just above the top of your picture) we would know what happened. At the point in the script all we know is that partclone wasn’t happy.

@JasonNaughton This is a strange one. The linux kernel just doesn’t just invent mac addresses. It would be interesting to look up the first 6 characters of the mac address to see if you could identify the manufacturer.

So are you saying there are 4 physical nics in this computer. LOM, PCie 1, PCie 2? Does that mac address belong to the LOM?

I can say that we are dealing with 2 kernels here. The iPXE boot loader, and FOS Linux. Its technically possible to get to the fog ipxe menu and then when you start up FOS it doesn’t get an IP address because either the nic order has changed or there is missing firmware that is needed to init certain nics.

@chevengur I can tell you how I would go about figuring this this.

1. Take a computer that represents the finished design of how your disk are laid out.
2. Schedule a deployment to that computer, but before you hit the schedule task button, tick the debug checkbox then schedule the deployment. No worries as long as you pick debug mode since it will never get to the deployment phase.
3. Now pxe boot the target computer, it should boot into the FOS linux console. After a few screens of text you need to clear with the enter key you will be dropped to the FOS linux command prompt.
4. From there issue, the efibootmgr command with no parameters. It should print something similar to below (note this is from my laptop)

thunder@lightning:~$ efibootmgr
BootCurrent: 0005
Timeout: 2 seconds
BootOrder: 0005,0004,0000,0001,0002,0003
Boot0000* UEFI BC511 NVMe SK hynix 256GB SN9BN62231050BJ2H 1	HD(1,GPT,d00df89f-1edb-44f8-b325-245b607b2321,0x800,0x100000)/File(\EFI\Boot\BootX64.efi){auto_created_boot_option}
Boot0001* ONBOARD NIC (IPV4)	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(b44,0)/IPv4(0.0.0.00.0.0.0,0,0){auto_created_boot_option}
Boot0002* ONBOARD NIC (IPV6)	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(b440)/IPv6([::]:<->[::]:,0,0){auto_created_boot_option}
Boot0003* UEFI HTTPs Boot (MAC:B445065BDC4B)	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(b445065bdc4b,0)/IPv4(0.0.0.00.0.0.0,0,0)/Uri(){auto_created_boot_option}
Boot0004* debian	HD(1,GPT,d00df89f-1edb-07b2321,0x800,0x100000)/File(\EFI\debian\shimx64.efi)
Boot0005* Ubuntu	HD(1,GPT,d00df89f-1edb-607b2321,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

You can see from this the default BootOrder is 5, 4, 0, 1, 2, 3 this lists the different boot managers found by the firmware.

So it will boot ubuntu first, then debian, the hard drive, onboard nic v4, onboard nic v6, http boot.

Now lets say I wanted debian to boot first I might issue the command.
efibootmgr -o 4,5, 0,1, 2, 3

Now reboot the computer with the reboot command see if it changes the boot order specific to your options.

After you get this worked out, you will need to clean up this deploy task on your fog server so it doesn’t do this moving forward. But for debugging as long as the fos engine doesn’t complete, every time you reboot the computer will enter the FOS debug console. This helps with debugging and tweaking your post install script.

@chevengur I have not had to do this before, but I can tell you in concept how to go about it.

You will need to create a post install script, that script gets executed just after the image is pushed to the computer and before its rebooted. This script is a bash shell script (remember the FOS engine is linux based).

Since it is linux based you will need to use linux command line tools to reset the boot image. The tool named is efibootmgr. This command is built into FOS linux engine.

So on its simplest form, you will create a FOG post install script and that script will call the efibootmgr to set the boot image. Understand that MS Windows will change this order without notice and at random times during its life.

Its not hard to do, but it will take a little effort on you to work out what is needed.

I can’t give you a step by step on how to do this but I can give you a general direction to look in if you want to go down this path.

@JasonNaughton Looking at the code the error would indicate that the target computer can’t reach the fog server.

https://github.com/FOGProject/fos/blob/8893d32bfb702dcf7b8f5427ccd6748fac15df17/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S40network#L64

What I want you to do is to pxe boot the computer into debug mode. Schedule a deployment to this computer but before you hit the schedule task button tick the debug checkbox. Now pxe boot the target computer, you will still get the errors but you will be dropped to the fos linux command prompt.

run this command ip a s that should show if your network interface has an IP address. If not then issue this command.
/sbin/udhcpc -i enp128s31f6 --now where enp128s31f6 is the name I gleaned from your screen shot that appears to have picked up an IP address. See if it gets an IP address now. See if you can ping the fog server’s IP address.

The ‘checker’ script makes this call to verify your fog server is reachable.
curl -Ikfso /dev/null "${web}"/index.php --connect-timeout 5 replace the entire ${web} with the IP address of your fog server. See if that returns a value.

Finally search the system messages to see if there is something related to firmware.
grep -i -e firm /var/log/syslog I think syslog is the right file, if it returns nothing try /var/log/messages One error could be the network adapter needs a specific firmware for the network adapter to communicate. That firmware may need to be added to the linux kernel.

@AlexisPHC said in Use serial number as hostname in Fog:

did you ever get round to writing a guide for this?

Yes. I think the previous comment to your post referenced the files.

https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg?_=1762381023512

the file fog.customhostname uses a linux command dmidecode to extract the serial number from the smbios. And the rest of the ‘hack’ will pump that name into the full registration files. When I wrote that script I worked for a company that had a composite host name with the site code, a hardware type and then the dell asset tag appended onto the end. That is what this tutorial shows.

Now Tom mentioned that {SYSSERIAL} in the quick registration field works too. I wasn’t aware of that feature, it must be new. I know FOG version 0.30 had that feature but it was removed when FOG 1.x was released. If its back, that’s great!! that makes my script(s) unnecessary.

@AlexisPHC said in Issues with Windows DHCP Server:

because we run them in HA mode

but there doesn’t seem to be another DHCP server present

My interpretation of these two statements sounds in opposition.

If you are running windows server in HA or failover mode, make sure that both dhcp servers have the dhcp boot options configured. If I remember right these settings are not copied over between the dhcp HA nodes. Understand this might have changed with later releases of dhcp server but with 2016 the pxe boot stuff needed to be set on each node individually.

@AlexisPHC If it magically stops working again, then I would check to see if you have two dhcp servers on your network. If it continues to work, then move on to the next issue. But in general I don’t like it when stuff just starts working, because the tides can shift the other direction with out notice too.

@sega said in FOG Multicast on different VLANs:

Is there something that I can look up, to see where the problem is?

Well your router supporting PIM is a good sign. Some routers have a service called igmp proxy or igmp relay, or even igmp snooping (you will find this more on switches, but check). This service typically has a number of interfaces to listen on and then a master interface where your multicast source lives. Its job is to relay the multicast requests to the proper interface.

PIM has two modes sparse and dense, that may be just for switches, I don’t remember. Sparse mode only sends the multicast traffic to the subscriber’s port, where dense just blasts out the muticast to all ports. You want sparse mode if possible, that way only the ports with a multcast receiver will see the traffic and not flood your network.

@Kram-Man This won’t work. When fog captures an image it also creates a metadata file that describes the target hard drive. Also fog when it captures the image it creates partition base image files, not a monolithic file describing all partitions. Could you do this outside of the fog image capture process, probably. FOG uses partclone and zstd to capture and compress the partitions. You would just need to create the metadata data file that represents the target system layout. Its possible to do, but just creating your golden image and then capturing with fog would be just as quick IMO.

@AlexisPHC OK the simple (and not so simple stuff) can be ruled out.

You said pxe booting worked when fog was the dhcp server, but there could be another issue especially if this is a new fog install. Confirm that on the fog server /tftpboot/default.ipxe file is there. I have seen people on a new fog install not get all three parts done correctly, if they missed the last step default.ipxe file would be missing.

The next part is not so easy but can be done. What we will do is install wireshark on a 2nd (witness) computer. Plug this computer into the same subnet as the pxe booting computer. Set the capture filter in wireshark to port 67 or port 68 and then start the packet capture. Now pxe boot the target computer until it fails. If it asks for the IP address of the fog server that has failed.

Now check the captured packets. If you set the proper capture filter you should only see the dhcp / pxe boot packets. What you are looking for is the DORA (Discovery, Offer, Request, Ack/Nack) dhcp process. The target computer will send out a Discover and (one or more dhcp servers) will send out an OFFER packet. This is what you need to investigate. First verify you recognize all dhcp servers that are sending an OFFER packet. Now inspect the OFFER packet, in the header there should be two fields (next-server which should match dhcp option 66) and boot-file (which should match dhcp option 67) then scroll down, you should see the dhcp options expand option 66 and 67 and verify they are set correctly. I’m expecting something to be wrong with one or more OFFER packets, because this is where the pxe booting client is getting unhappy.

@AlexisPHC Ok the pictures tells us a good story. Your dhcp server is working perfectly. Well its not working but its not your dhcp server’s fault at the moment.

from the 10.1.6.x subnet can you ping the FOG server?
Is there some some kind of screening router between your 10.1.6.x network and your 10.1.22.x networks?

On a computer on the 10.1.6.x subnet, take a windows computer, disable the windows firewall. Then install the tftp client on the windows computer. From a command prompt key in tftp get 10.1.22.1 snponly.efi and see if you can pull that tftp image.

10.1.22.1 is suspicious since typically the .1 or .254 is the default router for a subnet. It doesn’t need to be, but typically it is. Is the .1 address correct for the fog server?

I feel this is a routing issue between the two subnets.

@AngryITGuy First let me say I don’t use FOG for image deployment any more since I’ve moved to a different IT group, but if this situation hit my desk I would go through a similar process as below

I have more questions than answers for you. But the good thing here is FOG is imaging these systems and can deploy windows 10 to the hardware without issue. Right away we can rule out fog’s foundational support system being broken because it can deploy win10 and win11 to other hardware and win10 to this stone hardware.

When I debug something new or strange I try to build a truth table in my head of different experiments to see what works and what not works. Something like:

Deploy and boot win10 Dell laptop: Yes
Deploy and boot win11 Dell laptop: Yes
Deploy and boot win10 Stone laptop: Yes
Deploy and boot win11 Stone laptop: No (kind of)

So now to the unknown questions (and I assume these stone laptops are in uefi mode, you mentioned ‘bios’, but your boot loader is ipxe.efi.

On this stone laptops do you have pxe setup as the default boot source or is it the hard drive? This question is to see if the boot is failing if you are booting through ipxe.efi or if the firmware is having a problem finding the boot partition. If you are booting through iPXE see if changing the boot order to the hard drive solves the issue (for this test).

You will need to turn off secure boot for this next step. If you swap the hard drives between the dell and stone computer, does the stone computer boot normally repeated times? Does the dell computer reboot repeated times OK? This check is to see if the problem moves with the hard drive. The question is around if fog combined with the disk controller hardware on the stone doing something to damage the boot sector for win11 when it deploys. The dells works, can you get the stone computers working by deploying to a dell and then transplanting the hard drive to the stone?

If you deploy win10 and then upgrade to win11 on a stone laptop (verify its working 100%) and then capture and deploy to a same make and model computer. Does it boot correctly on the second computer? Can you deploy it to the same computer it was captured from and does it work? This will test if there is something wrong with your win11 image you are trying to deploy to the stone computer.

Lets see how the above goes before we plot the next test.

Just to recap

1. Test booting through iPXE vs firmware booting directly to hard drive
2. Swap the hard drives between the dells and stone computers see if the problem moves
3. Try to capture and deploy using the same hardware. First to like computer if no work, try to deploy to same computer image was captured from.

@sega said in FOG Multicast on different VLANs:

So some people already tried it?

Yes and so have I. You would need some way to dynamically change the network adapter defined in the global FOG settings to change the network adapter. You might also need to change a file called /tftpboot/default.ipxe to point to different interfaces. You might be able to get around this by setting up multiple tftp servers on the fog server, where each tftp server bound to a different interface and had a different home directory, that would be more of a long term change. And then you need to work out a way to update the imaging network interface in the fog settings depending on what interface you wanted to image using. There may be more crafty ways about doing this, but this is just off the top of my head.

@ecoele I can say this option will not probably be added by the developers since its such a niche or one off requirement. But I’m not speaking on behalf of the developers, I’m just stating my opinion. Its up to them to decide if a feature request has merit.

But fog being opensource its free for you to modify to your needs.

What I can tell you that there are several user defined fields you are free to add whatever data you want. On the database side I think the fields are called user1 and user2.

The second part is that FOG’s database runs on mysql (mariadb). This is much like any other sql server. If you have a windows computer and the mysql odbc driver installed you can query the fog database from a reporting writing tool running on windows. From there you can print labels, etc. You could do something as an excel macro to query mysql on the fog server.

Again on the mysql server, you could program something on the fog server in either python or php to extract the data from mysql.

@sega said in FOG Multicast on different VLANs:

I wanted to try to run multicast, but sadly our switches are just Layer 2 switches and they don’t support that on other VLAN (as far as I read, not a big network guy myself).

Layer 2 switches are good enough. Hopefully they are managed switches, that will make them work a bit better. Turn on igmp snooping on the switches. What that will do for you is enable sparse mode (i.e. only ports part of the multicast will transmit multicast data) without it the switch will work in dense mode where multicast traffic will be sent to all ports (impacting the bandwidth of devices not part of the multicast).

Muticasts are typically restricted to the current vlan. Where the magic happens is on your router between the vlans. Your router needs to be configured to forward muticast traffic between the vlans. This is typically done with a igmp helper / proxy / relay service much like dhcp needs a helper service to forward dhcp traffic from remote vlans to the vlan that has the dhcp server. This service running on your router will send the multcast data between the subnets.

So my idea was now: The FOG server is running on a VM, is it possible to give that machine just 4 more virtual network adapter (for each VLAN one) and reconfigure the IP address on the clients to one thats on there VLAN? Somehow I think that would be too easy.

This won’t work because when FOG service was designed it was designed to only support a single imaging network. Your fog server can have 4 network adapters, but only one can be the imaging network adapter. The rest will only work as management interfaces.

Or do I need to have a second FOG Server in that specific VLAN that just using the main FOG storage?

If you have no other option you can use a fog storage server here on the remote vlan. The issue is that only the FOG server supports muticasts. The fog storage nodes only supports unicast imaging.

@phant0mbot said in Dell OptiPlex 3000 Thin Client:

have tried both SAN and GRUB exit options

boot loader == snponly.efi

These are in contradiction with each other. SAN boot and Grub are bios boot methods. snponly.efi is a uefi boot loader. Since you are getting into the fog iPXE menu we can assume the hardware IS uefi based since it is booting snp.efi. Try a uefi exit mode of rEFInd (refind) to see if that will boot from the hard drive. The default value can be set globally in the fog configuration->fog settings page. Don’t force a bios attempted boot from a uefi booted computer, that never works.

@phant0mbot said in Dell OptiPlex 3000 Thin Client:

The Thin Client is able to pxe boot and accepts the image, but then can’t get past booting the final time.

It just attempts to boot from hard drive on the Fogproject Menu and keeps refreshing.

1. Just to be clear here. You CAN get to the FOG iPXE menu?

2. What happens when you pick a FOG iPXE menu. This will cause bzImage and init.xz to the target computer. Does the kernel attempt to boot?

@Jchinn412 The answer is it depends on how you have your disk structure setup

Post the results of these two commands.

lsblk
df -h

It maybe easy or harder (but not impossible) depending on how you have the disk created.

@aurfalien The arch value is not going to be fine grained enough for what you want.

This is a short table of what is available in the arch field.
Arch:00000: This is often associated with the non-UEFI, or legacy BIOS, boot process.
Arch:00007: This value typically indicates a 32-bit UEFI system.
Arch:00009: This value identifies a 64-bit UEFI system

So if you want to send bios or uefi boot loaders this is the method you want to use.

But from your post you want to switch between "undionly.kpxe while others the ipxe.kpxe " This are both bios boot loaders so the arch value == 0 for both hosts.

…However would you know how I can determine the client-arch value for a particular host?

If you know how to use wireshark you can get the answer you seek. Take a witness computer (third computer not part of the pxe booting process) and load wireshark on it (you may need to disable the windows firewall for this) Plug this witness computer into the same subnet as the pxe booting computer. When you startup wireshark set the capture filter to port 67 or port 68 and then select your ethernet adapter that is plugged into the same vlan subnet as the target computer. With the witness computer scanning pxe boot the target computer. Keep the scanner running until the pxe booting computer gets to the fog menu.

Now stop wireshark from scanning. Look at the packets it captured, it should have captured about 4 if you setup the capture filter correctly. If it collected a lot of traffic (like if you forgot to set the capture filter) set the view or display filter of bootp.

So with the 4 packets these should be the DORA packets Discover, Offer, Request, Ack/Nak. What you are interested in is the Discover packet, this is from the target computer saying hello world. Look into this packet. Scroll down the list of values until you see the dhcp options. To see the arch value its in dhcp option 93 or 94, or right in that area. You can use most of these dhcp options to set special filters on the dhcp server and then send different boot files depending on the values. You need to find what is unique between these systems so you can tell the dhcp how to react when it sees that particular value from the client during the discover / offer part of DORA