Posts made by abulhol

@Sebastian-Roth Unfortunately, secure erase will most often be blocked by the BIOS (frozen state). See more details here: https://github.com/FOGProject/fos/issues/40

@Sebastian-Roth PR done: https://github.com/FOGProject/fos/pull/41

I am not an expert on SSDs, but I haven’t used any so far that did not support secure erase.
But we could also add a check if it is supported as described e.g. here:
https://www.thomas-krenn.com/en/wiki/Perform_a_SSD_Secure_Erase
and run shred when in doubt.

The FOG OS has nice options to securely wipe disks, but it is not efficient for SSDs.
SSDs can be wiped with a few commands within seconds, while a shred for a 500 GB HDD takes about 1.5h.
I have opened a Github issue for this:
https://github.com/FOGProject/fos/issues/40
Is anybody interested in adding this? Otherwise I will have a go at it.

Final update:
Replacing the hardware solved the issue.
So it was either a hardware defect, or a bug in the firmware.

@JJ-Fullmer Just a short update on this issue: The NUC’s BIOS was outdated, and updating it failed for unknown reasons. We now replaced the NUC with a brand new one and hope to see the issue gone.

I currently have a single server running FOG.
If I capture a new image, will the FOG client (the one loaded via PXE) check the free disk space on the FOG server before starting the upload?
Or will it try to upload data until the disk runs out of space?

I am asking because I want to implement a safeguard against running out of disk space unexpectedly.

@JJ-Fullmer and @george1421 thank you so much for the immediate responses. I will follow your advice and see if I can fix it.
Regarding the use case, this is for doing malware analysis on bare metal machines (resetting the machine after each analysis).

We have an Intel NUC that runs Windows 10x64 version 1809.
We use FOG version 1.5.8 to manage it.
We use UEFI boot.
The machine is restored several times per day.
Occasionally, booting the machine fails. We have investigated this issue and found out the following:

1. The deploy job finishes normally, the machine then reboots
2. The FOG boot screen shows up
3. Afterwards, the “Intel NUC” screen appear, i.e. a black screen with “Intel NUC” in white letters. Normally, the Windows 10 “spinning wheel” is displayed below the text, and after a few seconds, the Windows login screen appears. However, in the cases of failure, nothing happens, and the Intel NUC screen stays there indefinitely.
   (I cannot upload the screenshots I have because of a bug in the Forum page)

We are wondering whether there is some hardware defect, because we have no clue why this is happening.
Has anybody seen this issue before?

@Sebastian-Roth it only happens with FOGMulticastManager, and we see it in regular intervals of ~11 days as described.
Thanks for investigating!

We actually don’t run any multicast tasks at all.
The error happens in seemingly regular intervals on every instance of FOG, about every 11 days.
It also happens on an installation of FOG 1.5.5.
We actually do start and stop Apache, DHCP and other services related to FOG from time to time, but the server (Ubuntu 18.04.4 LTS) itself is running continuously.

We are running FOG 1.5.7 on several machines.

Recently, we received an identical error on all instances at the same time:

Rule: 31420 (level 5) -> 'PHP Fatal error.'
Feb 28 14:38:53 myinstance FOGMulticastManager[1108]: PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 134217736 bytes) in /var/www/fog/lib/fog/hookmanager.class.php on line 54

which refers to this line:

public function processEvent($event, $arguments = array())
{
    $this->events[] = $event;

We haven’t seen this error in relation with hookmanager before, and I have found nothing on it here in the forum.

I have checked source code and opened a Github issue:
https://github.com/FOGProject/fos/issues/38

@sudburr In my FOG installation (1.5.5), the value for DATABASE_PASSWORD in config.class.php is in single quotes, so the sed statement for needs to be:

sed -i.bak 's|DATABASE_PASSWORD', '<oldpassword>'|DATABASE_PASSWORD', '<newpassword>')|g' /var/www/html/fog/lib/fog/config.class.php

I would also like to note that the values in .fogsettings are only initial values for during installation. So it does not matter if you patch the password there really (not 100% sure though).

@Sebastian-Roth That sounds like a plan. I cannot tell whether it will hurt older Ubuntu versions, but I suppose not.

@Sebastian-Roth At least after I had purged the package, it was not listed by apt-cache pkgnames anymore. But I am continuing testing upgrades and will check if apt clean helps.
Keep up the good work!

@Wayne-Workman I see that there can be issues due to missing package sources, but the sysv-rc-conf simply does not exist anymore for Ubuntu 18.04.
I hope that my post explains this well and helps other people who run into the same issue.

@Boyan-Biandov yes, but I prefer to use the working branch because it uses Ubuntu’s PHP7.2, which makes it more compatible with other software.

Hi there,
Here is some information for anybody upgrading their installation to Ubuntu 18.04 and getting stuck because of the sysv-rc-conf package which does not exist on Ubuntu 18.

The thing is that if you do a fresh install of Ubuntu 18 and then install Fog, you don’t face this issue.

But if you are coming e.g. from Ubuntu 14, you get stuck and as a solution are told to remove the package from config.sh, see: https://forums.fogproject.org/topic/9998/upgrade-ubuntu-16-10-to-17-04-sysv-rc-conf-fail

This “riddle” has been asked but not answered here: https://github.com/FOGProject/fogproject/issues/258 before.

I noticed when comparing the two that for the install that gets stuck, the output is:

Installing package: sysv-rc-conf..............................Failed! (Will try later)

while for the fresh install that works it is:

Skipping package: sysv-rc-conf..............................(Does not exist)

I wondered what that meant and had a look at /lib/common/functions.sh

What happens here is that the installer calls:

eval $packagelist "$x"

which in this case is:

apt-cache pkgnames | grep sysv-rc-conf

Now on a fresh Ubuntu 18, this will give you no output and return code 1, while on an upgraded Ubuntu, it is

sysvr-rc-conf

and the return code is 0, because the package has been removed, but is still listed by dpkg and marked as “rc”.

To cut a long story short, before you install Fog, completely purge sysvr-rc-conf, and you will be fine:

sudo apt purge sysv-rc-conf

Have fun!

We have the continued problem that on Ubuntu 18, PHP7.2 is default, but Fog installs PHP7.1 packages from another PPA, obviously only because of tests that still use PHP mcrypt.
Could you please change this? It is really cumbersome to tell people to update the fog installer manually to be able to install it.
See also:
https://github.com/FOGProject/fogproject/issues/264
Re: Installation - Centos 7 & PHP 7?