Best posts made by Tom Elliott

@JackYwn Please try this:

curl -kOL https://github.com/FOGProject/fos/releases/latest/download/bzImage
curl -kOL https://github.com/FOGProject/fos/releases/latest/download/bzImage32
curl -kOL https://github.com/FOGProject/fos/releases/latest/download/init.xz
curl -kOL https://github.com/FOGProject/fos/releases/latest/download/init_32.xz
curl -kOL https://github.com/FOGProject/fog-client/releases/download/0.13.0/FOGService.msi
curl -kOL https://github.com/FOGProject/fog-client/releases/download/0.13.0/SmartInstaller.exe

@george1421 This link might help:
https://forums.fogproject.org/topic/10160/virtualbox-pxe-boot-no-configuration-methods-succeeded

it’s the use of EFI booting a PXE booting system:

It’s been a long long time, but VirtualBox back then didn’t have EFI Network booting capability, and I suspect this still may be the case.

May need to adjust the boot options to use boot classes to provide ipxe.pxe for this virtual box host. I don’t recall how to do this right now.

@Chris-Whiteley This is a table of FOG from the older “virus scan” capabilities. It was a storage point for if and what it found on machines it had scanned.

@tiefel From what I can tell you hit enter on the part it asked you to go to the browser and actually submit the database insert/update process.

It literally needs the database to run.

So you can do this automatedly doing:
./installfog.sh -y Which will set all the default options and just make your involvment less involved. Of course if you’re not wanting to be that involved, please follow the on screen prompts as they occur.

Mind you if you go through the point of the install and while ti’s installing packages, the enter’s you press will translate as proper inputs later when you may not have intended them to occur, please take care and use patience.

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

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

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

@Fog_Newb That’s an interesting fdrive you got there

Not sure how that would work but to your actual question:

Please try:

touch /images/.mntcheck

As that error is indicating that the /images mount (for deploy points) is missing that file.

@Fog_Newb there is a new sed statement that is trying to set the port for mountd to 20048, but seems it may be setting all ports after mountd to 20048. We are aware but trying to figure out why and how to fix.

@AUTH-IT-Center Should be addressed in the latest.

@george1421 we added a little security bit now too as getting the hostinfo gave us the host sensitive information (ad user , domain , password, etccc.)

https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L9

This is the main difference.

We now need to get a token, and pass that token back to the hostinfo (it’s one time and locks upon initial request.)

Edit: Apologies on not posting the direct example, this was written while from my phone, not at a computer so copy paste wasn’t really “suitable”.

@kalmarteve What do you mean you don’t have permission?

YOu can read the log:

sudo tail -1000 /var/log/php-fpm/www-error.log

When prompted enter your sudo password.

@rogalskij I’m unable to replicate the problem:

I’m assuming this is what you mean?

@rogalskij so it seems your “ipaddress” is defined as your fqdn either on the IP address for the storage node directly.

I don’t know what your storage node settings look like but should be looked at likely from:

Storage Node-> DefaultMember

HOpefully that will help.

Normally if you can dereference the DNS name all would be fine so I’m just not sure where to help out.

But at least you know what is happening now?

Thank you for letting us know.

@Baessens Unforutnately the EFI stub: Measured initrd data into PCR 9 seems to be hitting us a lot lately and I don’t know why or what’s causing it.

I have heard mixed results of using older kernels, and sometimes newer ones fix it for the person. Not really sure what will be the right case here.

From FOG UI you can downgrade the init based kernel by FOG Configuration -> Kernel Update.

Please try some of them and let us know, if any, which works for you.

6.1.89 was one (20240430_1) was one that seemed to work for somebody. Maybe there?

The configs don’t change much between newer version, but we were seeing similar errors using the 6.1.22 version. This leads me to believe something was added to the kernel code, potentially removed, then re-added to it later. Just a suspicion I have.

@Quintin-Giesbrecht basically I think this is something in the kernel, but what it is we don’t have enough information yet. It’s possible a newer kernel might help.

Then again it could be something like:
https://forums.fogproject.org/topic/13620/very-slow-cloning-speed-on-specific-model/105?_=1729271500055

@Bhav We don’t have any information.

What I’m seeing, however, is that the machine you’re attempting to load is using UEFI booting, but you’re presenting MBR/Legacy PXE systems.

@Laurent The information is stored encrypted in the db + the transfer of information is encrypted between the client and the machine.

The only time the password is clear to any user is when you initially enter it in the field.

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