Posts made by Tom Elliott

@elchapulin For that you will need to download the experimental kernsl
FOG Configuration -> Initrd update

Download the latest version and then retry your image. You should be good to go.

@El-Fogito So with that can you reboot the machine (outside of the task) and perform a chkdisk /f on it, then disable the hibernation:
powercfg.exe /h off

Then attempt again? I apologize in advance

@El-Fogito So, can you please manually edit the “failed” image from the /images/dev location and manually move it where it needed to go? (as well adjust the permissions again.

Also, can you please look at your /etc/ssh/sshd_config file and look for the line that has “Subsystem” and “sftp”

I am just guessing, but it likely looks like:
Subsystem sftp /usr/libexec/openssh/sftp-server

If you can change it to:
Subsystem sftp internal-sftp and restart ssh services on the server, this should address the “Unable to start SFTP” error you were seeing.

To restart ssh service you would run:

sudo systemctl restart sshd

We’re getting closer I think, but it’s just a guess at this point. I apologize for it seeming kind of hit and miss, but thus is the approach we must take on forums.

@El-Fogito Interesting that you got the error for php-mysql, though I suppose if it completed the “will try again later” actually worked.

@El-Fogito

You can get fog from github:

git clone https://github.com/fogproject/fogproject.git --branch=working-1.6

Normally you’d be in the users root directory (typically /home/<username> or /root if you’re the root user)

After it’s cloned cd to the newly downloaded fogproject folder:

cd fogproject
git pull
cd bin
sudo ./installfog.sh -y

That should do all the work. If you already have a branch of github fogproject on your machine run:

cd /path/to/fogproject/installer
git pull
git fetch --all
git checkout working-1.6
git pull
cd bin
sudo ./installfog.sh -y

it’s basically the same thing.

as for “Same issue after moving folder” can you describe what you mean? Unless I got a typo of the location for the image path an error may be there, but it should definitely be a different error.

@El-Fogito In the mean time you can manually move the image to the proper spot:

Since I don’t know the mac of the original capture machine you’ll have to get that yourself unfortunately.

From the FOG Server terminal:

sudo mv /images/dev/<macofhostyoucaptured> /images/Nuc7i5BNKSDC-AC001-C000-win11
sudo chown fogproject:root /images/Nuc7i5BNKSDC-AC001-C000-win11
sudo chmod 777 -R  /images/Nuc7i5BNKSDC-AC001-C000-win11

This should get you to a point of being able to deploy the image.

@El-Fogito I suspect the fogproject user that is supposed to be handling the FTP connection which does the FTP move from /images/dev/<macofhostcaptured> -> /images/<nameofimagepathcaptured> is out of sync or simply non-functional.

Can i make a bold request and as you to install the working-1.6 version of FOG?

It shifts the mechanisms of file transfer and moves to SSH instead of relying on FTP. This may have it’s own issues of note but we can work on fixing those. As well, it will help fix the NFS security flaws you seem to have running currently so you will have slightly more security conscious FOG install to boot.

@PierreM59 If the computer cannot operate on HTTPS sites, and is using current software, I don’t know there’s anything we can provide to help you.

“Some work and some don’t” seems contradictory. While sites will use different versions of certificates, the fact that you cannot even reach the site tells me you are behind some kind of “gate access” preventing you from even reaching the “some don’t” category.

If you take that same machine, and run it on a network other than where you are currently, does it have the exact same problems? If it does, then is this “gateway” that’s preventing access likely installed locally on the machine? If it doesn’t have the same problems, then it’s the network from where you’re currently operating.

@rogalskij This is very interesting as initially I thought this was on some code I wrote (not that it still couldn’t be) but appears more like maybe the percent of free disk space has been unset and your drive is literally sitting as full as if at the hotdog championships and Joey Chestnut just won for 75th time in a row.

There’s a field in fog that is supposed to ensure free space left on the disk, but where yours is failing seems to be due to paging space / minimum size.

I might suggest, if you’re up for it again

Chkdisk again a few times,

Also defragment the disk a few times. THis should move your paging file (which cannot be resized around) toward the end of hte disk which shoul’d prevent the no space left on device issue I believe you’re currently seeing.

@rogalskij It should not need inbound at all. I do not know why it’s not working, but maybe you can provide the machines FOG Client log?

That usually sits in C:\Program Files (x86)\FOG Client\fog.log (or relatively close)

@rogalskij So while the images were lost, the issue in this particular case seems more in line with the problem that was originally described (and fixed) with the check disk utilities.

Can you boot into windows and run check disk, scan disk/verify disk on this machine? I presume this is only happening for this particular machine and as such may just be related to it alone.

I know the chkdsk and scan and all that will take some time, but while we do have utilities that can perform these actions somewhat automated, it’s also not the ‘native’ tools and Windows would have a much better system for performing the checks than what our tools will.

@PierreM59
It seems your network isn’t allowing you to access github.com on port 443. Are you behind a proxy server by chance?

@rogalskij The fog client only uses outbound 443/80 TCP to communicate to the fog server. All communications are totally reliant on your fog client installation of course too (for example if you installed with https, it will only use 443. If not it should default to attempting to port 80).

Hopefully that helps?

It’s worth noting the FOG Client is a polling system so it checks in with the fog server every so many seconds/minutes, so if you put a task on the server, it’s not immediately pushed to the system in question.

@elchapulin Have you disabled the powercfg option?

This seems to be the same error for the same reason.

You should be able to do it from Windows, open an admin terminal (command prompt)
and run:
powercfg /h off

Shutdown your machine and try the task again. The only other thing I can think of is your machine needs a chkdsk performed which again is best performed under Windows itself.

@MatMurdock Honestly, I don’t know. I’m just looking at the plugin from the view of 1.6 so that’s the base knowledge I’m aware of. I am not looking through the lens of the dev-branch options, though pretty sure it works rather similarly.

It may work, it may not, but If you’r’e willing to work with me, (“this works, this made things borked worse, this made things worked better” etc I’m willing to listen and try things.)

Probing questions and all that. I want it to work for you (and others) and as expected so please let me know.

@MatMurdock I don’t know that it works exactly as you might expect (magically and all that jazz lol)

I believe it relied on the IP address of the host table which just isn’t used anymore by FOG. While the plugin could still “work” you’d have to, I think, do so by setting the IP of the host and having the valid hostname dns translation, or the IP column of the host is set to the IP (this does not happen automatically of course. - Maybe we could add it back and set it as it boots up and gets IP addresses, but this could change A LOT.)

So from what I can see of the working-1.6 method, it does it at FOG Client Checkin, or when it hits the IPXE menu validly (since the IP of the host could potentially change at any given point.

I cannot say I ever had the change to test this plugin though. Somebody else came up with it, I just wrote the underlying bits and bobs so to speak (after they provided what they could of it) and updated it to function from a UI perspective in working-1.6

Theoretically it should work out the box, but I do not know for sure. Apologies on missing that.

I have improved a big of the cidr checking logic so it will now check for valid IP addresses as well (So no 256.0.0.399/23 potentials lol)

I don’t know if it ever worked as intended or not as not really had too many people using it until you and one person back in 2021 it seemed (and hopefully/likely the person who needed and came up with the concept.)

@MatMurdock Yes those are the correct steps to install it.

My Name, no, and glad I don’t work for them either. Not too soon, but also still broken it seems lol.

@sideone Now that we fixed the 1.5.10.41 issue, would either of you (or both?) be willing to install working-1.6?

It will be a curve change to what you’re used to working with I’m sure, but this really needs more widespread testing. I’m trying to get a youtube person to try to do a one off review of the branch as they have for release proper’s and all, but they haven’t responded yet, and I don’t have expectations for them to do so.

More users testing what should become the new release is always good in my opinion though.

@MatMurdock
Can you do a favor?

Please:

• Make a new testing host for your use case.
  • Make sure it has nothing preset that you want your group to set for you.
• Add the newly created host to one of the groups you’re seeing issues with
• Go through, set your associations and settings as you wanted and hit update/save.
• Go back to the host you created explicitly for testing.

Does that host have the defined settings displaying in 1.5.10.37?

@sideone @MatMurdock

Would mind re-pulling and testing again please?
1.5.10.41