Solution was

filename "undionly.kpxe"; next-server 10.33.97.251;

VERSUS

filename undionly.kpxe; next-server 10.33.97.251;

@george1421 After fully patching the workstation it still run compatibility ok. I didn’t try imaging before but I completed imaging the VM after the update and it imaged but threw a strange error:
pc_img_err.png

It almost looks like a core dump but the system kept imaging. I have noticed several times that in the percent complete line it will post a message about balloon request will be partially <something>. And then several seconds later balloon floor reached. On both esxi and now on hyper-v. But I think that is a topic for a different thread and a different time.

Edit: Irrelevant follow up. I noticed that 4.19.48 was listed on the screen shot so I confirmed the version of bzImage and it was indeed 4.19.48. I put back 4.19.64 (which was shipped with fog 1.5.7 and that CPU core dump did not come back on a system reimage. So its possible the older bzImage had issues that were resolved in 4.19.64.

@viggo While you are right that my answer might not be of much help I don’t see why I should put in effort to help you sort this issue on a Linux OS FOG simply doesn’t support anymore.

@rockinhc OK thank you. We’ll just move forward. I’ll update the tutorial for LM 19.2 and we’ll call it all good then. Thank you for confirming.

@Adriano-Rocha said in I have this problem can someone help me?:

put the redimioneaval

I’m sorry I don’t understand that word. So lets try again. When you created the image definition for that 500GB image, did you pick the option for “single disk resizable”? FOG will compress the image onto the fog server even if you selected “single disk non-resizable” to save space on the fog server. We need to understand how the image was captured.

@rockinhc The tutorial has been updated to reflect the currently in use kernel options. Thank you for the feedback.

@dylan123 Reading a bit more about the apparmor stuff I found this: https://stackoverflow.com/a/49583958

I read in another SO thread comment that the apparmor=“DENIED” message probably isn’t the reason that MySQL (or in my case MariaDB) wasn’t starting, as it’s only a warning.

Confirmed by this bug report:

On the affected system, there was no noticeable impact (yet?) other than the denials, so I’d say it’s low impact.

Spinning up a VM with Ubuntu 18.04 I saw that quite true it has those log messages in /var/log/syslog on my VM as well but the DB is running perfectly fine. So just for the records: Those apparmor=“DENIED” message don’t cause an impact on the DB and can be ignored.

Check all the information George and Daniel posted as well as my suggestion on the mysql logs.

Thanks guys! You all have been so helpful. I figured out that you don’t have to select the FOG Boot screen to select the Hard drive boot. It goes right into pxe.

It’s cut our deploy time from an 1 hour and 15 - 30 minutes to like 10 minutes.

If it becomes a further issue I’ll keep the post deploy scripts in mind.

Thanks again!

Found them, yes transferring them worked but also resetting encryption data also worked.

@george1421 I believe at one point it was suggested to use SSH to handle interactions with the server instead of ftp/nfs (one or both, don’t remember)

Though I imagine that’s further down the line.

@Sebastian-Roth This is more by design.

Typically snapins are one time run. If needed to rerun a while later, you can run it individually to the host needed, or you could task the host to run all snapins associated.

Maybe something we can limit in the future, but I guess I need better understanding.

Snapins run in queue.

For example, if a host has 25 Snapins to install, it installs 1, 2, 3, etc… It will not install 25 at once.

Now, based on the information, I believe the question here is about number of machines running snapins at once. Lets say you have 25 Machines to install Snapin 1, you want this to be limited?

Right now the code doesn’t take into consideration the number of snapin tasks as a queued process.

Hopefully this all makes sense.

Thank you,

@Trev-lchs Did you ever solve this? I just stumbled upon this issue report which we got years ago: https://github.com/FOGProject/fog-client/issues/72

@sudburr Ok, I tested and updated my version of the script below (derived from yours).

Again, make sure you have backups of your /images and the certificate files before you run this script!! I won’t be responsible for any trouble caused by this script!

I found and believe I may have fixed the issue. It was actually pretty simple. The error was coming from the unpacking of information.

Hopefully it helps. Just repull the dev-branch and install and all should be back to normal.

@Sebastian-Roth Thank you for finding and fixing the issue.
@Greg-Plamondon Thanks for reporting. This fix is also set for 1.6 now too.

Awesome job everybody!

Thank you,

@masoudmahamid Please run this on the command line and post output here: ls -al /images/dev

@dario-vettore Did you get this solved?

@brakcounty Any news on this?

@andrewhancock91 Are you still keen to discuss this?

@f-an Is this still an issue or did you solve it?