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

@Sebastian-Roth Thanks…

@lostitguy From what you describe it’s iPXE pulling the wrong MAC address. To get this fixed you’d need to contact those people: https://ipxe.org/contact

The quick workaround you can take is booting this particular machines via USB: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

@danieln said in Cannot delete image off of all nodes. Type 2 FTP Error...:

If I wanted to do this, would I just delete the entire directory? Or would I just delete the d1p1.img file? I feel like the entire directory, right?

Yes, delete the whole directory.

Speaking of, is doing an update just running the following commands?:
cd /fogproject
git checkout dev-branch
git pull
sudo ./installfog.sh

As I said, there is a new official release in the pipeline and you could install that if you feel like it. Instead of dev-branch use master instead in the above command sequence.

Is there anything else to it? Aside from backing up the FOG database?

If you have FOG running in a virtualized environment I would also take a snapshot just to be sure. As always, backing up the DB is advised.

@danieln Great to see you figured this one out yourself. Would have been quite a challenge for us to help find that issue.

@Tom-Elliott said in can’t install sumatrapdf:

@kalafina I suppose this is fixe then?

So Snapinarguments becomes: -all-users -s ?

Yes!