@hector-santiago Just be aware the FOG web UI default user is named fog and has nothing to do with the Linux service account fogproject. The later should not be messed with - therefore the message you see when you try to login to the server console using that account.

By the way, which version of FOG do you use?

@george1421 Thanks for responding. I’ll go ahead and create a new thread. Thank you!

@dyacishyn Too bad. Hope you have a recent backup of the database and the images.

Marking as solved as we know what was causing the described issue.

@Sebastian-Roth sorry i meant to click this one as the solution but now i cant figure out how to change it

@TheBuff said in PXE Boot help - Noob:

Might i also ask if their is currently any known solution to have fog work while secure boot is enabled?

The only way is to create your own certificates, update the target computer’s supported certificates and then sign both ipxe.efi and bzImage with the certificates. So the short answer is yes there is a way. Is it more effort than its worth, that decision is up to you.

I do have a tutorial on how to reconfigure your environment so you can secure boot using fog if you want to go in that direction. There are a number of steps but the difficulty level is not hard.

@LynnBerry On the first error.

Either:

let sysprep power off the computer when its done doing its thing. shutdown the computer with the command shutdown -s -t 0 disable fast boot

This will solve the disk not being closed properly.

In regards to the second error. On the fog server’s linux console key in sudo df -h and post the output here

@Hope1983

22bc75f6-4c63-4066-91a4-ea303c76385b-image.png

And for manual mount command used was :

mount ip_of_the_qnap:/Directory_of_the_qnap /fog_directory/

ex :

mount 192.168.0.2:/Images /images2/

@george1421 It looks like it finally managed to update the database and proceed to the final moment of the capture. I did what you suggested and changed the FTP Path and I can’t believe it worked. bbe46e8b-69c1-47c8-8353-5d323f802234-image.png
As you can see, my Image is there !
eee79cf2-cf90-480b-91a2-bfb027cbb839-image.png

Many Thanks for the help, I was this close of giving up for another solution, I was stuck for so long !

@ikt_le Hi, not sure what system you are using for DHCP but if it is windows please have a look at the guide below
https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence follow this, but please add the fog server IP to option 66. Also if you have subnets you need to complete this on each subnet scope on the dhcp server. Also if you have 2 DHCP servers you must do it on each one and on each subnet (unless is copies over properly between the servers, mine didn’t last time i set it up)

@Scootframer Maybe the server’s disk is failing? Have you checked the disk’s SMART bearings yet?

@Sebastian-Roth Thanks a lot for helping me and good to know that it will work on the newest version of fog project

@Sebastian-Roth said in Persistent Groups Not Working - FOG 1.5.9.235:

Could you please do me a favor and update your Ubuntu 20.04.1 - FOG 1.5.9 - MySQL 10.3.34 setup to the latest dev-branch (which does not have the fix included yet)?

Haha, that would not have triggered the issue because updating from 1.5.9 to dev-branch will not switch your DB table from MyISAM to InnoDB! Only new dev-branch installs are on InnoDB.

I did some extensive testing and it’s definitely the table engine InnoDB causing the initially reported problem. So it’s definitely good we got that fixed and from my tests there does not seem to be an issue with the new code, even on MyISAM tables. So I think we are good to go with this.

@Sebastian-Roth

removing php-common partially fixed the issue i moved the installer to the /opt directory reran ./foginstall.sh and was able to access the site.

Hi Sebastian,

thank you.

You are right it might be a Mac-Problem. After resetting the Parameter RAM ist works like before.
Many thanks
Mathew

@phonebread Just pushed a fix to dev-branch. Please update.

@abulhol said in Does FOG check free disk space before starting capture?:

That’s nice - but as far as I understand, it still doesn’t protect against the new image needing 10GB, but there are only 9GB left.
Right?

Yes, right, it doesn’t protect from that. We discussed different “solutions” and thought we should better keep it simple. If you are keen you can still jump in and add a more thorough check - estimating how much size the new image will need. While it is possible to do it’s not that easy because images are being compressed and other variables can vary as well.

@nkduy1508 You can either use Greasemonkey or other plugins to hide the IDs.

Or you can manually edit the PHP code (/var/www/fog/lib/pages/imagemanagementpage.class.php on your local filesystem) to remove the ID. Though the later will be gone when you update your FOG install.

@mikmatcr If this only ever happens on multicast deploys we should start looking at those logs I reckon. Please upload all the log files you find in /var/log/fog/ that have multicast in their filename.

Though I am not much optimistic we’ll find the issue in multicasting. I say this because in the pictures we see errors at various points in the deployment process. That points to hardware issues on those machines I would guess. Maybe dying hard drives or memory or whatever.

@Jordane said in ERROR: Could not get security token:

Indeed, in the local security strategy of our clients, the FIPS encryption is activated.
But also the option, Configure the types of encryption allowed for Kerberos “AES256 and future”.
These are the options that would block me?

Probably yes. And I really do understand your organization is forcing FIPS compliance.

AES is not compatible with FOG services?

Well, AES is actually a subset of the Rijndael implementation used in the fog-client. So it’s pretty close. I guess we can switch to using AES as I said before but not in a quick move! Needs code changes and testing.

I was going to open an issue report on github to keep track of this but turns out this has been around since a long time already as well as another forum topic (sounds like the fix isn’t that easy…)

Is it possible to disable encryption from fog and the TOKEN function?

No, not right now. One of my future plans was to remove the self made encryption from the fog-client/forproject code but switch to using HTTPS (enforced). This way we’d rely on state of the art crypto done by webservers and system crypto libraries. But that is even further away than switching to AES.

Ideally, it should communicate with clients without encryption.

I don’t get this. Why would you enforce FIPS compliance but then let the communication go unencrypted?!?!? Just doesn’t make sense to me.