Moderators group

JJ Fullmer

@bond007fink @jayrehme
By “Latest Update” do you mean the December updates for Win 11 or do you mean the latest release version of 25H2 ? I haven’t tested 25H2 yet.

JJ Fullmer

@pbriec Sorry that your post got lost in the shuffle, I saw it pop up with @raul’s response.
I imagine/hope you got past this in the last year but just in case, the fix would most likely be resetting the host encryption from the web ui (removes some token related database entries on the host record) then restarting the fog service on the client.

If that didn’t do the trick, then restarting the fog service along with resetting the hots encryption should fix it.

JJ Fullmer

@CoNickt @avh2025
Not all usb ethernet adapters are created equal. I would usually say to just bite the bullet and get the vendor specific adapter but it looks like you already did that. I have usb and usb-c adapters that work fine but different uefi firmwares behave differently. i.e. Microsoft surface just has to have its surface branded adapter for native boot to work. HP will work sometimes with the dell or lenovo pxe capable usb-c adapters. We also recently got 2 different hp laptop models where one had to use snponly.efi and the other was fine with ipxe.efi. I maintain a table of models and which adapters work with what we have. Lots of things do just work once you have a collection of usb adapters. Unfortunately, it’s an issue of hardware vendors adding proprietary limitations, but luckily between fog and ipxe you can typically get it working pretty smooth.

Generally if you’re able to pxe boot though, it should find the adapter within pxe. It could be a case of it being too “new” an adapter that requires a different driver not in ipxe. In that case though, I would try using snponly.efi as it may have different behavior with less things loaded in the pxe side. It may also be a driver or setting needed in ipxe that could be handled in a custom compile of ipxe, there’s some info on that here https://docs.fogproject.org/en/latest/compile_ipxe_binaries

It’s also possible to use a tool such as rEFInd to get to a uefi cli console. If you load the ipxe.efi and or snponly.efi and then if you can obtain them the efi driver for the adapter you can do a fs0: to enter the usb disk (it may be fs1: or fs2: you gotta ls on each disk to find the right one) then load usb-network-driver.efi then ipxe.efi to ensure the usb network driver is loaded in the efi for that session and then boot direct to the pxe file which will start the fog network boot. It’s a bit of a hassle but it usually works for me when all else fails. I have an old startech usb 2 ethernet adapter I do this with. This has worked universally but it’s not an ideal solution, but can be poc that it can be done on any device.

I hope my rant was helpful.

JJ Fullmer

@bond007fink @jayrehme
I do a monthly update to my image (single disk resizable) with the latest updated added to the iso I use to install. So I’m using the November iso with the December updates embedded for win 11 24H2 x64 and I had no issues with resizing.

So it may be a config issue on your end or it could be a more specific use case due to a windows upstream change.
Can you give a little more information on the hardware you’re capturing from and what your settings are on the image definition in fog?
I can try to recreate to some extent.

george1421

@romprager The simple answer is depends on the iso image and what OS will boot from the ISO image.

I do have several how tos in the forum that shows how to net boot several different installers.

https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

george1421

@lsdo FWIW blanking out information regarding a private network address space isn’t helpful to get a full picture of the situation. If that information is for public ip addresses then you have every right to blank it out, but knowing your fogserver is at 192.168.1.100 is of little use to a hacker and it makes trying to understand what is going on a bit harder.

Based on the error message it appears this is a download (being able to see the results of the type variable would help to know for sure) but it appears that FOS (the OS that captures and deploys images) can’t find a hard drive in the target computer to deploy to. I’ve seen this in Dell computers if the sata adapter is in Raid-On mode, a quick test is to switch it to ahci mode in the uefi firmware to see if it can then locate the hard drive.

If you can’t get it by switching to ahci mode, lets dig a bit deeper into this target computer’s hardware.

george1421

@christop said in Plugin Hooks Not Running at Sub-Site:

lab computers in the desired room and thus used to multicast the room

just a data point here. Only the master fog server “the one with the database” can multicast images. Storage nodes can not (unless something changed in the last few years). Storage nodes are basically NAS devices with a little programming.

Now we used the location plugin to create storage locations. We assigned the storage nodes to a location and then target computers to locations, so as the target computer boots it finds the storage node it should image from. But that won’t help with the multicast part because storage nodes can only unicast images.

george1421

@christop When I was using fog I worked at a company that had many sites. There was a master fog server at HQ and storage nodes at each site. I don’t know what the subnet group plugin is so I can’t give direction there. But for us we had one image for global deployment. Then we used a fog post install script that updated the target computer’s unattend.xml file at imaging time. This allowed us to update the system’s default keyboard, locale, language, and destination OU the system was assigned to. We did not use FOG snapins for deployment but another tool once imaging is done. This other solution was used to deploy applications that could not be baked into the golden image because they had deploy time IDs that we did not want replicated to all deployed systems (like Antivirus system IDs).

If you are interested in this method I do have some tutorials that will give you a head start. But if you are using this subnet group assignments to add the machines to a snapin deployment group then my method will not work well.

george1421

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

george1421

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

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