@NoIPName you didn’t provide a csv. You took a screenshot of an excel of your csv.

That said I suspect there’s an issue on the line of or immediately following the host you aren’t able to import.

I also seem to be seeing the same host name multiple times in your image so that might explain things as well.

Please provide your actual csv.

@Driver while I’d love to support resizing and working with LVM, we do not currently support it. There’s functions to try but I never got around to incorporating it or getting it tested and functioning. Maybe we could revisit but I can assure you I am completely at a loss on how to do it. That’s not to say it cannot be done, I just focused on all things else besides this and the fog client. All help/any help is appreciated especially if it makes fog that much more robust and usable.

@kotson3 I don’t know what’s wrong and with such little information th eonly thing I see is FOG sees it as connection failed. This leads me to think maybe this is something forced for your environment.

Filezilla works because it can just flip a switch when it fails best I can guess. We aren’t filezilla. If you must “drop it out” then so be it. i don’t know what’s wrong and without really much more information, I don’t know what else to say.

in particular I do keep seeing “Entering Extended Passive Mode” which is very very strange. id on’t know what this means and may be playing a part of this?

FOG FTP can support Passive mode but I don’t believe it’s enabled by default.

@kotson3 I’m seeing connection failed, so I’m unsure what/where the problem is occurring.

@NoIPName You’re still using 1.5.9-RC2.9 (???) and @Nicolas-Bricet You too?

can you upgrade ot a more modern version from the stable branch. Pretty sure this may have already long since been addressed.

@kotson3 But you’re not attempting FTP to 10.234.90.212. you seem to be attempting to FTP (in the cli) to 127.0.0.1 or localhost. From what I can tell, your FTP instance isn’t passing over the 10.234.90.212 point.

@Small0145 The filter is the only way, as of now, to do that.

Mind you, the filter works as a comma seperated list.

So if you know all the MACs you want not to be used, that’s how you can ignore it from even potentially registering.

@Small0145 said in Different computers on the same Pending entry:

0A:00:27

I think there’s FOG Settings -> QUICKREG MAC Filter or something, and you can put the partial mac address which effectively would do as you’re requesting.

@Small0145 I don’t recall all the specifics, but it should only associate to an already existing host IF the host mac in use is also approved for use.

@Small0145 Then the only other way I can think of is the machines all have the same hostname.

Pending mac’s are generally found by matching the mac address (or multiples) that are already accepted to a single host.

The machine you’re showing isn’t giving us the MAC address though, at least as far as I can see.

@davidsontiago Have you tried booting the machine and running checkdisk?

Similarly, you should turn off fast booting by opening command prompt and running powercfg /hibernate off then try to capture the image.

@Small0145 Are you using the same network card to image multiple machines? If you are, I would suggest using the “Not for client” option for that specific mac address.

@kotson3 The password that’s in the .fogsettings file is the same password that should be defined for the username in both the storage node (10.234.90.212 of course) and the FOG Settings -> TFTP user/password.

That should be the username/password pair you used to login to from your filezilla program.

That all said, the message doesn’t really tell us if it’s truly invalid login or that the fog server isn’t allowing access from itself to itself. What’s interesting, though, is that I’m assuming you’ve been able to capture images successfully, but you cannot seem to delete it?

@DBCountMan Private key is built to the client at install time. The Public server ca cert is pulled at install time.

So for this to be a “problem”

The person would have to know the IP to download, as well as when installing the client on a new machine configuring it to send to that same server.

What “problem” does this pose? The newly installed client would either already be registered to the FOG Server OR is a brand new and would be behind a “Pending Host/Pending MAC” on the FOG UI.

What you’re suggesting isn’t difficult or problematic itself, so glad you’re sharing, just trying to understand that issue you’re attempting to solve with this beyond restricting it to whatever ip/subnet is being worked.

@lperoma This sounds odd, but somehow you have sysvinit on debian 12, when most modern systems are now using systemd.

That said you should be able to fix this by:
apt install systemd-sysv
Though I don’t know if that’s all that will be necessary?

Now I would, of course, get a backup of your server before blindly running these things

@fabritrento That’s not how this works. Just saying lol. 6.1.22 works fast for your situation, but that doesn’t mean there’s truly something wrong with the kernel for everybody. So when the next stable release comes out, you should remember to switch back to 6.1.22 and we’ll work to keep trying to update the kernels and hope that you’ll test them to see if it works for your situation so you don’t have to revert it to 6.1.22.

@RocksAndRolls So NFS is mounted on the host and used as the place to put the files into a storage point separate of the deployable image point.

After the capture completes, FTP (to the server from the server) is used to move the captured image to the actual image path.

For example you have an existing image called: Windows 10, with a path of /images/Windows10

You create a new “base” image for this and are in the process of capturing it anew. But at the same time another 2 machines are configured to be deployed in the mean time:

You are capturing the new Windows10 in /images/dev/<mac_of_host_capturing> and the 2 other machines that are trying to be deployed can still run at the same time.

The FTP you see called is to move the /images/dev/<mac_of_host_capturing> to /images/Windows10 once it completes.

@fabritrento FOG Configuration Page -> Kernel Update.

Most likely use the 64 bit kernel and just keep the filename set to bzImage and you should be good

@fabritrento What I’m saying is I don’t think the bandwidth limitaiton stuff is what’s happening in your case. It’s been in there since 1.5.1 I believe, so this isn’t why you’re seeing slow downs on multicast.

This might be because of drivers in the kernel where as you stated you got full speeds with earlier versions of FOG. Try 6.1.22 kernel or something?

@fabritrento I am not aware of any differences in speed changes, though there is bandwidth limiting I capabilities. Pretty sure those capabilities exist in 1.5.10 as well though so the only real “change” I suspect are based on the kernel’s being upgraded and maybe something there changed.