@dashwell Well you said you updated from an older version and you think the update is causing this problem. While I still don’t think the update caused this I still was wondering what version you used before.

Back to the problem: The error is pretty clear. The image was taken from a larger size disk. Probably using an older version of FOG which did only shrink but not rearange partitions (to fill the empty gaps). The version you currently use (20220203) is capable of rearanging partitions but you need to re-capture the image with that version to make use of it. So I suggest you grab a machine with a disk large enough, deploy that old image to it. Then create a new image definition within the FOG web UI (to keep the old one as backup), set this new image for the machine you just deployed the old image to, schedule a capture to the fresh image definition and then try to deploy this new image to smaller size drives.

@george1421 said in No Network Interfaces Found: Intel i225-lm Kernel:

you simply need to upgrade your FOS linux kernel to 5.15.x series. You do that from the web ui -> FOG Configuration -> Kernel update

Confirmed this fixed the problem. Solution is to perform the above steps @george1421 wrote.

@Redbob Yeah the wiki is really dated. We really need people from the community help us sort through it and move it all to the new documentation platform: https://docs.fogproject.org/en/latest/

Would you be keen to help us?

@joanmarzo Laptop bios/firmware settings.

@c4c @george1421 I can assure you that there should be nothing special that build.sh is pulling or doing. While we have different branches like master (latest official) and dev-branch (development) in the fogproject repo this is not the case in the fos repo. I always use fos master to build stuff. If I do really fance new things I create short temporary branches but merge those into master again as soon as things are ready to go.

One thing I just noticed in George’s desciption is using make -j4 to build. The official manual states that “Buildroot does not support top-level parallel build” (reference). Though I can’t really think of this causing the problem described.

If you work more on this you should also read this part of the manual: https://buildroot.org/downloads/manual/manual.html#full-rebuild - e.g.:

When a package is removed from the configuration, Buildroot does not do anything special. It does not remove the files installed by this package from the target root filesystem or from the toolchain sysroot. A full rebuild is needed to get rid of this package.

@Daniel-1 You might want to open a new topic and post more details (version of FOG and fog-client used, fog.log) rather than re-opening a ten year old topic.

@koni said in Can't pxe boot UEFI:

But I didn’t find the pxelinux.cfg

That is correct you should not find pxelinux.cfg because that is for the syslinux boot loader not iPXE. To add items to the iPXE menu you do that via the web ui in FOG Configuration -> iPXE Menu, menus. There is no need to hand edit the boot menus.

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

@iamvincepr0 Look to see in the target computer firmware that mac address pass through is enabled. The issue is that ipxe is seeing the built in mac address of the computer, but FOS linux (that does the inventory) is only seeing the mac address of the usb dongle.

Also you will probably want to upgrade your FOS Linux kernel to 5.15.x version (FOG WebUI -> FOG Configuration -> Kernel update This will give you the latest hardware drivers for newly released computer hardware.

@john-l-clark said in Lenovo L13W Yoga not booting to FOG:

Ok I have found with the MAC passthrough in the Bios turned on we are not able to boot to FOG unless we were on the same subnet.

This is interesting. My intuition is telling me it might be an MTU issue. We have seen that with tftp, Where (typically) on the other side of a VPN WAN link the MTU of the data packet is less than the block size of tftp. The block size of 1468 comes to mind for tftp. When the network MTU dips below that level it causes fragmentation of the tftp packet, then the transfer fails.

Using the instructions I provided before for collecting a pcap on the fog server, you are interested in udp port 69. Start the packet capture and then pxe boot the target computer on the remote subnet. See if it attempts to contact the fog server. The tftp query will be 2 times before data is transferred, the first time the client queries the tftp server on the size of the file and the second time it asks for the file. My bet is that it will ask for the file size, but then the file is never sent.

@george1421 said in Error capturing Win 10 image after updating to the latest dev version - Resize Test fails:

Would it just create a larger disk image?

Yes exactly.

If yes then 7 or 8 might be a good start if size is the only penalty.

Ok, will 7 do for now.

@x23piracy Sorry for the long delay! This is a known issue in an older version of FOG and fixed in 1.5.9 and later.

@Mightmar Sorry for the long delay. Have been pretty busy.

I suggest you try to figure out what hash sums should be correct. Grab a copy of the file on the host machine, e.g. C:\Program Files (x86)\FOG\tmp\run_wpkg.bat and calculate the SHA256 hash sum for it. Also check the contents of the file on the host.

@ksrvpvl Hostname is allowed in the latest dev-branch version (1.5.9.140).

@mrp Added to the official FOS inits now. Can’t wait any longer for you to test.

@george1421 Yes i already try this. Works fine but already my problem with Bitlocker.
Actually my problem is our computers are configure to boot on pxe when receive wake on lan.
And Bitlocker ask recovery key if order boot has changed.
But i notice if i reboot “normally” even after that, Bitlocker don’t ask recovery key Bitlocker.
My problem is for our computers “Refind EFI” is the only mode who work with pxe. If i use other option, i have an error like “Chainloading failed”.
This is why i was thinking to have a “reboot” mode, because i don’t find how to make it work the “Exit” mode

@joanmarzo ?? OK but I don’t think the problem is FOG but if you want to reinstall that is your choice. We will be here to help if you need it.

I’ve never run into this specific problem until today. Generally, issues with resizing can be fixed by increasing the CAPTURERESIZEPCT in Fog Settings > General Settings. I agree with what @Quazz said about certain kinds of fragmentations causing issues with the theoretical minimum partition size. I’ve found that the more used (fragmented?) a drive is, the more likely it is to fail during resize. I was able to get past the no space left on device and numerical result out of range errors by increasing the CAPTURERESIZEPCT to 15%.

@george1421 0e6dce0b-716b-4019-86f7-09c37e7b1902-image.png IT’S WORK!!! THANKS A LOT!

The fog kernel version is 5.15.19,

I have created the Linux os image from laptop model hp probook440G8 in the fog server.

while I am trying to deploy the image with the same laptop model, it’s showing me the options as I have shared the previous image.

@TaTa The default NFS in FOG is still version 3 which has no concept of user authentication/authorization. Sure you can try to lock things down a bit by setting access rights on the FOG server filesystem.

But if you want to go beyond that you will need to look into NFSv4 which is not implemented yet: https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3