What does it say if you manually try installing with:

sudo apt-get install php7.1

What did it say when you manually ran it?

More often than not, this is presented if you’ve crossed init’s and kernels (32 bit init with 64 bit kernel or vice versa).

That said, based on the “inode referenced” issue this could be caused by a few factors.

1. If you edited the inits and failed to compress correctly.
2. If the init was not fully downloaded.
3. Memory on the device is bad/ going bad.
4. Memory on the server is bad/ going bad.
5. Diskspace is full causing the file to fail to download fully.
6. HDD going bad on the server causing the file to be sent in a corrupted state (at random).

Of course, I’m sure, there’s more potential causes, but start with the basics first.

Seeing as I know, at some point, your disk space has been full, I’d say start there (though this seems unlikely if the panic is always different.)
If this all checks out, try reseating the hosts ram (maybe try known good ram too?).

There’s more to try out first, but please just start here and see what you might find.

@Jo2220 not strange in the least. Db credentials should always be separated from web credentials. Unix login account should be different from db and web credentials. Using the fog GUI login as your db credentials would lead to significant security issues. Imagine. If you will. Fog db, web, and Unix login were all the same.

All an attacker would need is a single pair of information and your server would be compromised.

@David-Osinski That would make me ask, what drivers is fortinet installing? The client, as far as I’m aware, has no reliance on drivers. It does need network access (which is what I suspect fortinet is blocking in some way).

Exceptions/Exemptions should be possible though. I’d start by taking a look at fortinet and what it’s blocking that the client might actually need.

@sudburr what you performed is correct, if you already had a prior config laid out. Sorry I didn’t recognize this sooner but a fix for this has been added to the next working branch.

Essentially the variable was being set properly, but it was being overwritten when the fog settings file was imported.

If you sysprep the images first, the sid would always be generic. Just a thought.

Something seems fishy to me. The error messages you’re seeing should not appear in FOG 1.2.0 (as the init’s didn’t even get those changes until WAY later on in the development versions).

If you are running on 1.2.0, but installed a more recent version what is the new version you actually attempted to install?

http://unix.stackexchange.com/questions/273819/how-do-i-rebuild-create-assemble-an-imsm-raid-0-array-from-disk-images-instead

It appears you might need to specify a chunk size? I don’t know what that chunksize will be, but if you can test the ideas on the above link, and figure out, I can work to add a “chunk” size argument for the raid if all works.

Worked out the issue. It was proxydhcp causing the issue. I cannot tell if the issue was Dnsmasq(router and DHCP server) passing off to dnsmasq (proxy DHCP) and not getting the dns to properly route. However, because dnsmasq is already available on the DHCP server we disabled the proxy DHCP and setup the dnsmasq boot items for efi/legacy on the dd-wrt side. This, as I understand it, change around for supporting efi and legacy was the reason he wanted to use proxydhcp to begin with.

@WourN So I don’t understand why you’re still installing -RC-1?

We’re up to 30.

If you’re running svn up you should be getting the most current.

@WourN The installer should have taken care of it for you (but most people installing fog tend toward fresh which means they’re likely installing CentOS 7). Basically, those commands downloaded and installed the repositories FOG is supposed to be installing for you.

@Wayne-Workman and @afaure :

FOG Configuration Page->FOG Settings->General Settings->FOG_FORMAT_FLAG_IN_GUI

@george1421 Well that was an oversight :(.

Basically, it appears, it’s creating a file based on the image’s name.

@jamcdonald120 I’m assuming your image’s name is actually set to “Raw”?

I’ve found the issue and hopefully it will work as expected.

Please rerun the installer to get the “fixed” inits. Hopefully this will help out (and sorry I missed the raw imaging bug.)

You need to tell the FOG system to build the .mo files.

This is done by setting the installlang=0 to installlang=1 within the /opt/fog/.fogsettings file.

To me this sounds like you have multiple DHCP? I don’t know.

Can you show us a copy of your /etc/dhcp/dhcpd.conf file?

I’ve been working to remove AV scanning from the init’s entirely.

There’s a few reasons for this.

First, if your client machines are infected with a virus, it’s typically best not to trust that anything within that client is safe (data, pics, music, etc…). Essentially, it’s safer to reimage the device than to perform a quarentine scan with any virus software.

Second, it’s very time consuming to try to keep up with clamav within the init’s so the init’s are always in an updated state. Seeing as most people stick to the version running (when on stable release of course) for an extended period of time, the only way to have some semblance of safety is to update the signature files regularly (of which are not persisted in the fog client). This basically means every client has to stop, download the latest signature files, apply them, then run through the scan. Of this and it would probably have been faster to have just reimaged the machine.

Third, keeping the running binaries updated is nearly impossible. It seems once a week or so is a new version of clam which causes the init’s running instance to be “outdated” and throws warnings.

Fourth, most organizations have their own AV software already with in their images. Relying on this I think is a bit overkill and prevents reporting to your own tool systems.

If you really MUST use FOG to do AV, you will need to create the folder:

mkdir /opt/fog/clamav and add the clamav entry to your nfs exports file. Within there you would need to place your signature file(s).

I don’t know how this is “another unable to locate image store”. This is not a common thing people are reporting.

Typically, you will see this if the files that “make up the image” are missing though. As the “store” is no longer available.

https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk#Git

Sanboot, typically, doesn’t work for VM systems. This isn’t something I have direct control over unfortunately.

That said, as @Arsenal101 stated, please try using the Exit or Grub exit types instead.

If the VM is not registered in the fog server, you will need to adjust the “global” setting from:

FOG Configuration Page->iPXE Boot Menu->{Exit to Hard Drive Type,Exit to Hard Drive Type(EFI)}