Moderators group

george1421

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

george1421

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

george1421

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

george1421

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

george1421

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

george1421

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

george1421

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

JJ Fullmer

@george1421 said in Broken iPXE boot loader:

@Mightmar I wonder if the devs for iPXE has changed something in the ipxe source code to cause this error message about autoexec.ipxe not found. This should be supplied by the fog project add on files. I’ll take a look at the compiler to see if something has changed. You should not see this error.

Reinstalling 1.5.10 will fix the error of the latest build of iPXE. Also you mentioned about a later version of FOG. Yes you can install that over 1.5.10 without issue. It should also have updated (but not the newest version of iPXE).

This is the first post I found searching autoexec.ipxe so replying here for future searchers.

This was an addition in a recent ipxe version, and is meant to be a way to add ipxe based functionality without needing to recompile ipxe in order to edit an embedded script (https://github.com/ipxe/ipxe/discussions/1237#discussioncomment-9847219), I can’t find the post/doc again but I remember reading in one place that ipxe added it as part of the hopes of getting a signed ipxe shim so users could use the signed shim and then use this script to add what they can’t embed. While technically we can create a blank file in /tftpboot/ i.e. just

#!ipxe

which will remove the error during boot, this can then cause kernel panics when loading into FOS. Why it does this is a bit of a mystery at the moment, maybe it’s adding to or replacing another part of our pxe menu scripts that causes something in loading the kernels to lose access to ramdisk drivers. But adding it can break everything, so for the time being, just ignore the error.

george1421

@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

Test booting through iPXE vs firmware booting directly to hard drive
Swap the hard drives between the dells and stone computers see if the problem moves
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.

george1421

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

S	Sebastian Roth
J	JJ Fullmer
F	fry_p
X	x23piracy
Q	Quazz
F	falko
G	george1421
C	cml
C	ch3i
A	andyroo54
C	chad-bisd
V	VincentJ
N	need2

Moderators

Posts

Member List