@flat4vw I found my answer got it updated.

@george1421 @Sebastian-Roth
hi guys,
the compression rate in the image caused the error
capturing and deploying works…
Thx 4 the support
thread closed … finally 😉

@juelson The output of the commands I asked you to run look normal except the directory listing of /images. There is a missing hidden file that FOG uses to know its connected to the correct image store.

There should be a file called .mntcheck in both /images and /images/dev This file is created by the fog installer so it should be there unless someone adjusted the contents of the /images directory.

So we can fix it with the following command. We will fix /images/dev so uploads work correctly while we are at it.

Key in these commands at the FOG Server’s linux console. You may need to use sudo if you are using a debian variant or do this as the root user.

touch /images/.mntcheck touch /images/dev/.mntcheck

This is a non destructive command so its OK to run them even if the file exists. Once the .mntcheck file is created you download should work better.

@juelson I’m not exactly sure what you are saying here, so let me reword what I think I understand your issue is using my words.

I’ve pxe booted and selected full registration to register my computer with FOG. Registration works just find but when I go to deploy an image and create the deploy task, when I pxe boot into the fog the iPXE menu it shows the computer is not registered with FOG. I know it completed registration OK because I can see it in the web ui.

I know I used more words than you did, but I applied what I think I understood with your issue to ones I’ve seen before. Did I explain the situation you see now?

@mgoh You could probably update the size with a sql command if you wanted. Not really a need to do it though.

@londonfog Not sure but I don’t think there are API calls for the iPXE menu stuff. I suggest you look into using a SQL query/insert or you might be able to code your own plugin to get what you want.

@jmccannon The current version of FOG only has admins and that is it. There is an admin plugin module, but I have never personally used it. I do agree that FOG needs to have and admin user and a capture/deploy/imaging user class.

@george1421 You were right, it was a problem with DHCP, our System team solved it by comparing it with another site, I don’t know the details, but it’s working now, Thank you for your help!

the below entry, opening max connections for sql - was indeed a fix.
default is 151, and i now have been a solid 200 connections for a week with no issues.

in debian 11, i did the following :

sudo su -
mysql -D fog
SET GLOBAL max_connections = 512;

To make this a permanent solution, refer to the link in the previous post.

@george1421 I made update of IPXE to the latest version and then I tried ipxe.efi and sucess! Thank you!

Eu havia procurado antes mas não tinha achado solução no fórum para esse problema. Procurando mais, encontrei solução conforme esse post: Storage group activity - 1 active

@rogerbrowntdl yes a smaller mother image would be best. 1.5.9 can grow the golden image to the size of the disk but not shrink it. Or just removed the recovery partition from the golden image. If you have an imaging solution in place is the recovery partition even useful?

I started with fog the shrink option really worked so I would create my golden image on a 70 or 80GB hard drive then expand it post deployment in windows. I also developed our golden images on a VM because I could snapshot the vm before critical steps. That kept me from having to rebuild the entire image again if I botched something. Stuff happens you know.

@lenain said in AD password issue:

'

Is the “&#039:”. giving a problem? MYSQL is typing it that way as a HTML code. I have no coding knowledge nor do I know MYSQL very well but this may be of some use:
Source:
https://stackoverflow.com/questions/9596652/how-to-escape-apostrophe-in-mysql
Quote:
Possibly off-topic, but maybe you came here looking for a way to sanitise text input from an HTML form, so that when a user inputs the apostrophe character, it doesn’t throw an error when you try to write the text to an SQL-based table in a DB. There are a couple of ways to do this, and you might want to read about SQL injection too. Here’s an example of using prepared statements and bound parameters in PHP:

$input_str = “Here’s a string with some apostrophes (')”;
// sanitise it before writing to the DB (assumes PDO)
$sql = “INSERT INTO table (note) VALUES (:note)”;
try {
$stmt = $dbh->prepare($sql);
$stmt->bindParam(‘:note’, $input_str, PDO::PARAM_STR);
$stmt->execute();
} catch (PDOException $e) {
return $dbh->errorInfo();
}
return “success”;
In the special case where you may want to store your apostrophes using their HTML entity references, PHP has the htmlspecialchars() function which will convert them to “&#039 ;”. As the comments indicate, this should not be used as a substitute for proper sanitisation, as per the example given.

@george1421 Thank you very much. I will try to run the multicast deploy