None of this will work with ondrej.

Ondrej has moved into only supporting ‘LTS’ releases.

You will need to upgrade (or downgrade if you must) to one of the LTS releases.

Current supported PHP versions for Ondrej are:

16.10
16.04
14.04
12.04

1.3.5 RC 6 has been released and should have this ‘uncompressed’ capability coded more properly for it.

@coop90 So the d1.minimum.partitions, and I suppose d1.partitions files both have ‘e’ as the the /dev/sda3?

That would lead me to think that the 3rd partition is REALLY odd.

I think that’s going to give you the best bet btw.

@royg706 Updating any version of svn is not going to put you on the RC’s as requested.

Open terminal and become root.

From there run:

apt-get update
apt-get install git
cd /root
git clone https://github.com/fogproject/fogproject.git
cd fogproject
git checkout dev-branch
git pull
cd bin
./installfog.sh -y

Fixed.

@george1421 https://forums.fogproject.org/topic/9581/kernel-panic-in-centos-7 It’s the same person.

@Wayne-Workman I’m probably going to go with sha512sum to ensure less potential of collision (while md5 shouldn’t have too many).

Multicast, in its very nature, is a “selfish” protocol.

Unicast uses TCP transfers, which means only the requesting systems will even see the data (particularly much faster on switches – which is why they are so much more common now – than on hubs.) So the only data sent is given a direct path to the destination (essentially). In simpler terms, I suppose, TCP traffic doesn’t even start sending data until the “requesting” item makes a request confirming it needs the data. This, essentially, creates a tunnel and the data requested is sent purely to the requestor.

Multicast uses UDP transers. UDP works by just sending data across the network. It doesn’t care who the traffic is for and “spams” (for lack of a better term) the entire network path it can reach. We do have “waiters” for the Multicast system to hold sending data until a single host (or number of hosts) are trying to request the data, but once the data starts sending it’s sending everywhere it can get to.

Typically, this is because the checks are not able to “see” the other node.

This could be many things. Things to check might include, but are not limited to:

1. Firewall. Is the firewall enabling port 80 on the servers? Is there another firewall (physical or software) between the two nodes that might be preventing communications?
2. High use. When replication is happening it uses a lot of resources for many reasons. This can cause a high load on the systems involved as one side is sending and the other is receiving. It takes some processing to read and write all the data, so the systems can become heavily taxed during this process. Also, with 1.3.4 but others may be affected as well, the file checking uses resources as well. (We’re trying to grab a hash of the files to compare.) This will be limited to the system where the file is located, but it does mean the “sender” AND the receiver are hashing the files to communicate. 1.3.5 working branch has taken steps to limit the resource usages and should be much better as far as the hashing IO load is concerned.
3. Can the remote node actually communicate to the main server presenting the GUI? (Similar to the firewall note above, but can entail such things as database connectivity.) If the server is unreachable in mysql or html, there’s nothing the remote server can send as it can’t communicate.

Hopefully these help along the way.

Reading another of your earlier posts, are you doing two full servers and trying to have them read “graphs” from one another?

If this is the case, if the “remote” node is not looking at the “current” node, you will see some strange things.

When the pages go out to request the remote information, they pass along the remote’s identifier. If the other node is also a “local” server, the remote would be looking at it’s own database for this information rather than the “requesting” information.

Here’s why.

Server’s have their own database.

If you have two servers you would have one server with storage node id of 1 and the other server with a storage node id of 1.

When you create a “new” entry on one of the server’s for the remote node, the new ID would be 2.
When fog goes out to reach the remote node, it will be sending the id of 2. If the remote node’s ID is not ID 2 in it’s database, the node doesn’t exist and therefore has nothing to send.

You could “fix” this by simply editing the mysql on the remote node and edit it’s nfsGroupMember ID to match what the “requesting” server is looking for.

@MarkusK Your statement makes 0 sense. Please clarify?

@george1421 isn’t saying that NFS is the issue, he’s saying what manufacturer is the device? Is the NFS Server laid out properly as expected by fog?

The IP for the database isn’t changing one bit.

@sjensen Did it work?

This is likely the fog image replicator and/or fog snapin replicator services.

They check the file’s hash values. This constant read has been addressed for what will be the rc 11.

@Wayne-Workman https://forums.fogproject.org/topic/9636/additional-disk-space-is-not-showing-up-on-fog-server/11#

Just trying to help.

This is a fresh install i’m presuming?

@TTellez it’s not a problem. It’s just trying to create a backup but a fresh install would not have anything to backup.

@TTellez it’s that reason @Jaymes-Driver is suggesting going to RC it appears to be fixed there

@george1421 No, it wasn’t.

To add on, the resizing system in the past was far from a perfect beast. It should be much better now, though RC 11 did have an issue or two as well. (This was because forgetting about 4k drives.)

If the issue is still happening, it would seem, to me, that the partition it’s trying to work with is much smaller than what was expected to be on the main system.

So if the image was captured from a 1tb drive, and trying to be placed on a disk the size of 250GB, you’re greatly cutting down the size, possibly to a point that it cannot resize appropriately.

Disk sizing is based slightly off the originating disk. The way it works, now, is:

Find the originating disk size, figure out the originating partition size, how much of the originating disk did the partition use? Using the new disk, use the same a percentage of disk space available to create the drive.

You might be able to do the tasking using a fixed size partition in place, though i may have to review the code a bit to make sure the “original” size is used as the fixed space, and not the “minimized” size.

What’s the output of ls -lhartR /images?

When you applied the permissions, it appears you’ve set 777 recursively, but did the ownership remain as root:root or fog:root?

From the sounds of things, the problem isn’t at all with “permissions” necessarily, rather it sounds like a problem with NFS services.

Maybe:
systemctl status -l nfsd could shed some light?

Or:
systemctl status -l rpcbind