Posts made by Tom Elliott

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

@fabritrento I’ll be honest, I have no idea what you’re saying is isn’t happening here?

@Quintin-Giesbrecht Would there be a potential of finding out if it’s specific to the ssd by removing it from one of these “slow” lenovos, put the drive in one of your normally fast machines, and try to send the image to it?

if it’s slow in the same way, it’s definitely something scoped to the SSD itself, if it’s fast, it’s likely something specific to these Lenovo Neo 50Q Gen 4 devices.

Just my 2 cents.

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

@Laurent Password legacy is no longer used in 0.13.0 I don’t believe. Please enter your domain password in the non-legacy item. 0.13.0 was NOT ever using the legacy fields. It was because of these versions of the FOG client, that the “legacy” items were even created.

@hummela You may need to uninstall and reinstall the location plugin (maybe having to recreate the locations too unfortunately.)

I’m only guessing, but there are things added to plugins DB stuff but no real way to tell plugins that a schema to its db is needed first.

I suspect it’s likely surrounding the newer “protocol” feature of locations.

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

@dtiganas said in Unable to encrypt drives with bitlocker after deploying image with Fog:

The path specified in the Boot Configuration Data (BCD) for a BitLocker Drive Encryption
integrity-protected application is incorrect

Please try the information here:
https://support.microsoft.com/en-us/topic/error-message-when-you-try-to-run-the-bitlocker-drive-encryption-program-cannot-run-39e3c3f5-4f5f-242c-504a-ee55e5015eee

Maybe here as well:
https://www.mcbsys.com/blog/2019/01/bitlocker-wizard-initialization-has-failed/

FOG isn’t the “reason” this is happening though it, I suspect, is playing a small part.

Ultimately I think it boils down to the bcd thinking this is one drive, but you’ve cloned it so bcd needs a resync to find the actual drive it’s sitting on.

I think BCD is using a unique identifier to find the paths and that unique identifier isn’t that actual information on that newly deployed system. so This article should help fix that, I hope.

@Pingolin I believe you can setup the ip as subnets:

For example:

/images 192.168.0.0/24(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev 192.168.0.0/24(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

Which would only allow 192.168.0 subnet to connect to the nfs share.

@Pingolin Technically, yes, realistically probably not.

The reason we use NFS is due to speed and efficiency.

Is there a particular reason you cannot use NFS? Unless you’re using the FOG Server’s NFS to store other data from your company? FOG Server’s are not intended to be that way. The NFS is the point that allows sharing the images you capture and deploy to the machine’s your capturing/deploying (from/to).

NFS is the most user friendly way of accomplishing this.

Now there are past attempts to use SMB shares (Windows file sharing style) but it requires a lot more effort to stand up and is not necessarily guaranteed to work better and might not meet the requirements your company is wanting.

@fabritrento As you stated it, UAC is preventing access. There is no real way to fix user cleanup that I’m aware of.

We have started working to remove the features that we cannot manage.

                case 'service-autologout':
                    $this->serviceAutologoutPost();
                    break;
                case 'service-displaymanager':
                    $this->serviceDisplaymanagerPost();
                    break;
                case 'service-hostnamechanger':
                    $this->serviceHostnamechangerPost();
                    break;
                case 'service-hostregister':
                    $this->serviceHostregisterPost();
                    break;
                case 'service-powermanagement':
                    $this->servicePowermanagementPost();
                    break;
                case 'service-printermanager':
                    $this->servicePrintermanagerPost();
                    break;
                case 'service-snapinclient':
                    $this->serviceSnapinclientPost();
                    break;
                case 'service-taskreboot':
                    $this->serviceTaskrebootPost();
                    break;
                case 'service-usertracker':
                    $this->serviceUsertrackerPost();

Sorry that it isn’t “pretty” but this is the code moving forward. You can think of anything not on this list, but still accessible in the 1.5.x versions as being deprecated (to non-functionality)

@fabritrento yes, you can interchange them though sometimes (not the case here) the biggest concern is schema updates between different versions.

In this case, dev-branch is the basis of stable, so these should be effectively interchangable.

@fabritrento That appears to be the correct method.

git clone https://github.com/FOGProject/fogproject.git --branch=dev-branch

Would have done the same thing (when you didn’t have the fogproject cloned.

The method you chose is correct though, and moving forward you would simply:

cd fogproject
git checkout dev-branch
git pull

To update to the latest information.

When you want to install stable you would:

cd fogproject
git checkout stable
git pull

Then follow the install instructions as normal.

Thanks!

@fabritrento I understand you have more memory than what would typically be required, but 32 bit only allows up to 4gb of memory (generally) and for some reason, I’m postulating, that because there’s more it’s saying “no, we aren’t putting anything into memory” hence the ran out of memory issue.

That said, if you could test it would be great.

I know you’re in a production environment, but right now (as I see it) your prod environment isn’t working at all. So the “test” is what will be in the next stable release on Nov 15th. If you can test, just to validate you’re able to image again, it would be great.

If you cannot, I understand, just hoping to have more information and provide a solution for you.

Thank you!

@Fog_Newb Please pull the latest and try again?

@fabritrento Please try to update to the latest dev-branch and see if htis works properly

Yes I want the 32 bit stuff to work properly, but since this is likely a 64 bit machine anyway.

I am thinking this is due to the amount of memory on the machine far exceeding the amount of memory the 32 bit binaries can actually even handle. (Just my suspicions)