Did you sysprep the image before capture? How did you build your reference image? Did you build it on the same model computer, capture and then deploy to a different computer of the same model, or did you create a generic reference image on a VM and then deployed it to the target hardware. For uefi computers, if the boot device has a fat32 partition with the boot file in the proper location the uefi firmware will let you set it as a bootable device. If the boot file isn’t found that drive won’t be selectable to boot. So this tells me that refind can find the proper uefi boot loader, but the firmware can’t?? Does the lenovo have something similar to the Dell F12 boot manager? If so can you select the m.2 drive from that menu and have it boot?

This is a work around, for a long term solution …ummm we must to think if this solution is for 1.5.X versions or get a final solution for 1.6.X and how can we do it XD Maybe the solution is create on fly the CSV file to export and import the data (I am thinking loud)

@Demache What’s the difference between 1st/2nd storage node and the 3rd one? I suppose the WAN tunnel between head quarter and 3rd location doesn’t allow the communication needed to query the information from the 3rd storage node. For both size and hash the replication service first uses HTTP or HTTPS (depending on how you installed) and if it doesn’t receive a proper answer it also tries to retrieve the size and hash (only for files smaller than 10 MB) information via FTP. So if all those protocols are blocked the replication cannot work. Now as I re-think what I wrote this doesn’t make sense because you said that it does replicate the files (using FTP!) properly. So we probably need to take a closer look. As I said, it checks size first which seems to fail in most cases considering the log you posted. BUT there is one file where it seems to be ok with size and then goes ahead to match the checksums and fails on that. Seems to be a bit random. Well, using the information given you might try to see if the WAN tunnel might oppose some restrictions that might cause this. As well you want to check apache access and error log on the 3rd storage node to see if those requests actually ever read that node.

@lkisser From what I understand this has nothing to do with the image you use on the machine but with the machine model (Dell Precision 3620 in this case) itself. Have you tried different exit types? (setting in FOG web UI -> hosts’ settings or global setting)

@stu Once you get the system registered, I’d like you to do something for us. Schedule a capture/deploy it doesn’t matter, but before you hit the schedule task button tick the debug checkbox. Then schedule the task. PXE boot the target computer. Plug a traditional keyboard in for this test. After several screens of text on the target computer that you need to clear by pressing the enter key, you will be dropped to the FOS Linux command prompt in debug mode. At the command prompt key in lspci and take a clear picture of the numbers it prints. Plug in the KVM switch (but leave the traditional keyboard connected). Confirm that the KVM is selected towards the target computer. Run the same lspci command again. Hopefully you have 1 or more new PCI devices listed. Take a picture of the new output (you can probably get both outputs in one screen shot as long as I can read the numbers we will be good. The difference between the two commands will be the hardware IDs of the kvm switch. We can then take those IDs and confirm that the linux kernel supports the KVM.

Oh yes, that is most likely what it is. It is when you click the wrench at the top right in the web interface. FOG Version Information 404 Not Found

I have 15 identical systems. All have the same size 120GB SSD drives and only one partition. All have the same W10 build. I have imaged roughly half of them, and the size of the image is always under 20GB. One of the systems is imaging at 119GB. I am doing the same steps each time. Don’t know what’s wrong with this one station! I have tried to upload a picture and I get “sharp” errors.

@Sebastian-Roth said in Development FOG not capturing image - PartClone update: @shruggy Would you mind telling us which version of partclone this is? It’s the latest git shapshot: https://github.com/Thomas-Tsai/partclone/tree/58d138da6e0f473acd80a7c9b8544d104377d50f with the fix you suggested: $ cd git/fos/Buildroot/package/partclone $ ls Config.in partclone-0.3.12.patch partclone.imager.patch partclone.mk $ cat partclone.imager.patch diff --git a/src/ddclone.c b/src/ddclone.c index 04f8775..cab5386 100644 --- a/src/ddclone.c +++ b/src/ddclone.c @@ -30,7 +30,9 @@ void read_super_blocks(char* device, file_system_info* fs_info) } strncpy(fs_info->fs, raw_MAGIC, FS_MAGIC_SIZE); fs_info->block_size = PART_SECTOR_SIZE; - //fs_info->device_size = get_partition_size(&src); +#ifdef IMG + fs_info->device_size = get_partition_size(&src); +#endif fs_info->totalblock = fs_info->device_size / PART_SECTOR_SIZE; fs_info->usedblocks = fs_info->device_size / PART_SECTOR_SIZE; close(src); I haven’t yet pulled the latest FOS, however. So it doesn’t contain the changes to func.sh by @Tom-Elliott i.e. no special case for partclone.imager. On the other note, when using unpatched Partclone 0.3.12 I also sometimes got segmentation fault, but didn’t report it. The case when Partclone finished successfully, but actually didn’t capture the partition was the more common outcome. I’d say, somewhere in the relation of 4 (empty) successes to 1 segfault, IIRC. And I didn’t notice any pattern to segfaults then (e.g. it could happen with or without compression).

@Malte-Will bump

There are a few things I would look at here. pxelinux.0 is not used for FOG for almost 8 years. pxelinux.0 is typically a boot loader for syslinux and not iPXE (what fog uses). The default bios ipxe boot loader is undionly.kpxe, for uefi its ipxe.efi. FOG is not your dhcp server and that is OK. It does appear that you are using isc dhcp server. If you were to pick FOG as your dhcp server it also would use iscp dhcp. An example configuration file for isc-dhcp is here: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Example_1 Another option is to not have your dhcp server issue boot file names, but install and configure dnsmasq onto your FOG server. Let your main dhcp server issue the ip and network configurations, and let dnsmasq supply only the pxe boot information. There is a tutorial here on how to set it up: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server So to your problem. Did you pick register the host when you first went to the iPXE FOG menu? That will create a host management page. You will next need to create an image definition page to describe the image you want to capture. Then go back to the host definition page and link the image to the host. Once you save the setting then from the host definition page you can pick capture image. On the next pxe boot FOS Linux (the engine that runs on the target computer that captures and deploys images) and your target computer’s hard drive should be uploaded to the FOG server. If the task can not be activated on the fog server, is there an error message displayed when you schedule the task?

@nonamejason How did you change it? Probably a config file, post that config file here. Or if it was through the GUI, post a picture of that.

@Dv27842 said in ERROR: Not able to find a network interface that is up on your system: I was able to get ufw enabled Actually you want the firewall disabled. OK so lets back up a bit (mainly since I’ve been bouncing around different threads). Can you ping 8.8.8.8 ? Can you ping www.google.com ? If you can ping by ip address and not by name then something is messed up with the dns entries. Understand if we are stuck here this is a linux issue and not anything (yet) to do with FOG. For linux there is a file in /etc called resolv.conf. That holds the name(s) of the dns servers for your network. The network configurator should populate this file. If its effectively blank you can add a line like nameserver 192.168.1.1 where 192.168.1.1 is the IP address for your dns server for your network. That DNS server needs to be able to resolve internet addresses like www.google.com. If you put the proper nameserver entry in that file you should be then able to ping by host name.

I believe you have to modify the client OS to support being booted over iSCSI, though I have limited experience with it. I could be wrong, but I think by default iSCSI isn’t included in the initramfs of Ubuntu. Perhaps this https://apfelboymchen.net/gnu/notes/booting ubuntu iscsi.html could be helpful. (at least the client info) All that said, NFS boot is likely to be a lot more straightforward to implement and I use that method quite often.

@UWPVIOLATOR If you can’t get the application to behave with respect to the restarts, you could always create a snapin pack bundling the executable with a script. In the script, you could check to see if the application was already installed and of the correct version, then if it wasn’t perform the install. if you wanted to kick off the application and then do something like loop while the executable was running, you might want to play with the start command, something like start "" installer.exe -args. https://ss64.com/nt/start.html @george1421 the /k flag runs the specified command then leaves the command window open. https://ss64.com/nt/cmd.html

I will go through the information you sent, but I cannot take photo of the screen. Thanks.

@Greg-Plamondon Ok, fog-client log looks fine. What about the other things I mentioned?

@Penguinsec said in Fog Client Not Communicating with Server: This time client logs are showing no errors, but the host is not showing up in the server. What do you mean by this??

I tested and uploaded another version: this time it’s the latest Partclone with the fix suggested by @Sebastian-Roth, i.e. diff --git a/src/ddclone.c b/src/ddclone.c index 04f8775..cab5386 100644 --- a/src/ddclone.c +++ b/src/ddclone.c @@ -30,7 +30,9 @@ void read_super_blocks(char* device, file_system_info* fs_info) } strncpy(fs_info->fs, raw_MAGIC, FS_MAGIC_SIZE); fs_info->block_size = PART_SECTOR_SIZE; - //fs_info->device_size = get_partition_size(&src); +#ifdef IMG + fs_info->device_size = get_partition_size(&src); +#endif fs_info->totalblock = fs_info->device_size / PART_SECTOR_SIZE; fs_info->usedblocks = fs_info->device_size / PART_SECTOR_SIZE; close(src); The symbol IMG is defined in Makefile when building partclone.imager and prevents this change from being built into partclone.dd. For now, I’ve successfully captured a disk from one machine and restored it to another one. After the coming Microsoft Patch Day (probably over the next weekend) I am planning to capture another disk image with this and deploy it to my pool in multi-cast mode. This time, I also built the 64-bit kernel 4.19.94 and used it together with this image. It’s here.

@JonesDK Sorry for the delay. You can try it out now (as described below).

@Greg-Plamondon Is this still an issue or did you find what was causing this?