That did the trick. But this still means the FOG installer itself is forcing the incorrect version yes?

Build 6347, no change.

And before you ask, the firewall is inactive (dead).

Apache2 is working. I can reach the default page.

In behind the installer? This is what FOG is installing, not me.

* Installing package: httpd...................................OK
 * Installing package: php.....................................OK

Dumping:

yum -y --enablerepo=remi-php5-56 update

… behind the installer through a second session I get:

Error getting repository data for remi-php5-56, repository not found

It’s set for Linux, Single disk - resizable.

The only thing of consequence I could find in /opt/trunkgit/fogproject/bin/error_logs/fog_error_6339.log regarding anything php up to the website view request is:

WARNING : PHP 5.4 have reached its "End of Life".
Even, if this package includes some security fix, backported from 5.5,
The upgrade to a maintained version is very strongly recommended.

WARNING : These php-* RPMs are not official Fedora / Red Hat build and
overrides the official ones. Don't file bugs on Fedora Project nor Red Hat.

I created a CentOS7.1 VM and uploaded it 2015/10/01 . At that time, the EXT4 partitions were successfully resized & captured by FOG, set as Linux, Single disk - resizable.

As of today with build 6339, capturing it simply says:

Shrinking Partitions on disk
Not shrinking (/dev/sda1) fixed size
Not shrinking (/dev/sda2) fixed size
Not shrinking (/dev/sda3) fixed size

The file systems for sda1 and sda2 are both EXT4.

The result in 2015/10/01 was an “Image Size on Client” of 2.5 GiB .
The result today capturing the very same VM is an “Image Size on Client” of 115 GiB.

Of course, attempting to deploy this new image to a HDD of lesser size results in the Part Clone error “Target partition is smaller than source …”

I’m rolling back through kernels to try and find when it broke; nearly the entire list of kernels in FOG are dated December 20th, 2015, so I can’t tell which kernel it might have been that was in use at the time (2015/10/01).ymd

@Sebastian-Roth said:

To me this sounds like you have an older version of PHP installed. Maybe something went wrong in the installer when external repos were added. Check to see which version of php is installed rpm -qa | grep php

PhP was installed by the FOG installer. Six times now I’ve tried, in progressively cleaner environments until now I’m basically installing FOG immediately after installing CentOS without any updates. Same result every time.

With Build 6339,

HTTP Error 500

extract from /var/log/httpd/error_log (centos)

PHP Fatal error:  Cannot create references to elements of a temporary array expression in /var/www/html/fog/lib/fog/fogbase.class.php on line 193

Looking it over again now that I’ve slept on it.

From one fire to the next.

When it comes time during the installation to visit the fog/management web page, a fat ol’ HTTP 500 error comes up.

From /var/log/httpd/error_log (CentOS)

PHP Fatal error:  Cannot create references to elements of a temporary array expression in /var/www/html/fog/lib/fog/fogbase.class.php on line 134

AH01276: Cannot serve directory /var/www/html/: No matching DirectoryIndex (index.html,index.php) found, and server-generated directory index forbidden by Options directive

The turkey was a turkey. I couldn’t recreate it with build 6333, so I’m moving on.

I agree. A kernel panic was the last thing I expected from CentOS.

Welp, it’s really quite simple.

I think I elicited a kernel panic entirely because I ctrl-c the process after it had sat there for 20 minutes without moving.

The rest of it is as it says; install CentOS, install fog… hang. I’ll try and dig up log files.

The installer does not hang when upgrading to 6321, only on a fresh install.

I’ll throw another turkey at it later and see what happens with 6323.

Build 6323 fixes it thank you! … except, links for both x86 and x86_64 both want to replace bzImage32 by default.

FOG_TFTP_PXE_KERNEL = bzImage
FOG_TFTP_PXE_KERNEL_32 = bzImage32

Manually changing bzImage32 to bzImage at the download prompt works at least.

CentOS 7.1 Minimal Server built and updated today (2016/02/18).
Installing build 6321.

The installation hangs at “Setting up and starting MySQL”.

Huh… actually locked the system up into a kernel panic.

Attempting to re-install over this failure, now fails gracefully at the same line.

I pulled version 4.1.4 of bzImage and bzImage32 from another server.

Without replacing the init’s, “Resizing Filesystem” now completes in about a minute.

I’ve noticed this problem with Hyper-V VMs on physical discs as well. Though much, much worse at 45 -60 minutes stuck on Resizing Filesystem. These are brand new VMs built from scratch. The last command I use next to shutdown is:

defrag c: /x /h /u /v

I have an added problem in that I can’t download other kernels (in another thread) so I have been unable to test with older kernels other than 4.4.1 .

First discovered upon upgrading to build 6303 then build 6315, when attemping to “Update Kernel” from within Fog Configuration.

Inserting the missing “/” to FOG_TFTP_PXE_KERNEL_DIR results in this error:

FOGFTP: Failed to rename file. Remote Path: //var/www/html/fog/service/ipxe/bzImage32/backup/bzImage32_20160218_132122, Local Path: /var/www/html/fog/service/ipxe/bzImage32, Error: ftp_rename(): Rename failed.

Attempting to update kernel produces this error.

FOGFTP: Failed to put file. Remote Path: /var/www/html/fogservice/ipxe/bzImage32, Local Path: /tmp/bzImage32, Error: ftp_put(): Could not create file.

The path /var/www/html/fogservice/ipxe/ does not exist.

Should it not be /var/www/html/fog/service/ipxe/ ?