Forgive my being rude here, but why haven’t you thought “There may be a reason it’s recommended to set the permissions to chmod -R 777.”?
I mean really?
I understand the concern, but why not start with what’s recommended first and get it working or figure out where the issue is?
Also, can you give us the EXACT error messages you’re seeing, maybe pictures if possible?
I’ve moved this to bugs as it is clearly such a thing.
I’ve confirmed the issue and have a fix already staged for this. I’m just running through a few tests to try to ensure all is working more or less properly.
I want to add, while the legacy client is still supported, I’m not overly concerned with things that Windows Vista and up don’t work well with even if all legacy items are working properly from the server side. These things I’m not overly concerned with (as they won’t work on Vista and forward) are:
I’ve no printers I can test with currently so this will not be a part of my testing.
Currently tested and back to functional from the legacy client:
I will update this post as more of the tests and/or fixes to make sure they work are completed/verified.
@afuente26 latest version of fog is not very helpful. What is the actual version of fog you’re running? Latest in my eyes is current trunk. I’m going to guess you’re working with 1.2.0. You will find the version in the cloud logo at the top of the GUI.
Please run:
cd fogproject #if you're not in the git folder already.
rm binaries1.3.4.zip
cd bin
./installfog.sh
Forgot to update binaries.zip with the 0.11.9 files sorry about that.
@holzfisch Can you delete the Trusted CA that you have for the FOG Server that’s labeled as:
192.168.1.14CA
Then go to http://192.168.1.14/fog/management/other/ca.cert.der in Chrome or Firefox (as IE will just display the file as if it’s plain text) and install THAT certificate?
This should fix your registry issue. You might have to reset the encryption data for the hosts that were affected as well, but ultimately you should be good to go after that. The CA Name in the Certificate Manager should be: “FOG Server CA”
Middleware is the new name of the CommunicationHandler class. It was renamed because, while it does deal with communication, it’s essentially the Middle man of the Client to Server communications and data operations to move in between the other modules. It IS middleware and was named more appropriately.
@Jbob I believe has a debugger function already created and setup on the forums. I’ll update this post with the link that shows where to download the file and how to use it.
Here is the Link to the forum post:
https://forums.fogproject.org/topic/5074/ad-join-rename-on-client-0-8-1/5
I highly doubt, no offense, you’re running 3557 seeing as we’re only up to 3538 right now. That said, I know what the problem is and will hopefully get a fix out shortly.
1.4.0 RC 5 should address the problem though I will admit it initially removes a level of functionality people have probably become accustomed to.
Of note here, it will now display hostname and user.
The “Username” will remain under the user and the host will remain under the hose.
Clicking the “host” will display all login events for that host.
Clicking on the “username” will only display items for the hostname that was selected.
I will probably add another cell later on that will allow you to select a user for all hosts.
Currently it will be:
[hostname] [username]
Clicking [hostname] will show all user tracking events with this hostname.
Clicking [username] will show all user tracking events specific to this host AND user.
Future functionality (possibly):
[hostname] [username - specific to host] [username - all hosts with this user]
Hopefully this makes sense to everybody.
It will not ask about dates. This same thing will occur for imaging and snapin logs as well. (I do plan to add this back but more in a filter approach than a you must know what you want to look for first approach).
This system is trying to boot via NIC over UEFI/EFI boot. Can you change your bios settings to use “Legacy” or CSM (Compatibility Service Mode)? Rather than PXE Boot IPv4 NIC?
This bug is already addressed in 1.4.0-RC-5 and forward. Please consider updating.
The other bit, is if you can see what the error is (My guess is Console Errors), it should help tremendously in giving a suitable fix.
The math is trying to set the size based on math from the originating disk vs the nee disk size. There will always be some variance. In the past this didn’t seem to be an issue but this was because there were major issues in how the resizing was happening to begin with. By “not seeing this is the past” I presume you mean from fog versions before 1.3.5? I say this because the code was fairly heavily modified to work more properly from 1.3.5-rc-10 with minor adjustments made in 1.4.0-rc-1. for 1.4.0-rc-1 the adjustments were made to ensure a block size of 512 was being used to ensure alignment of sectors. It’s this alignment that I suspect you’re seeing as the “unallocated” space. This is most likely due to you disk being 4k but aligned to the nearest 512 sector. I don’t consider this a problem because trying to get things to expand beyond a certain point should be handled as needed by the admins. 6gb extra space isn’t too hard or too much in the larger scheme. 1tb less 6gb is still 994gb usable space. It also leaves some room for buffer which is not a bad thing I don’t think.
I’m solving this thread.
@jguest found the option to allow the physical systems to boot using undionly.kpxe. He’s using a pair between proxyDHCP so we linked the undionly.kpxe.0 file as necessary.
I still want to figure out snp.efi but at least he is able to go on with fogging.
@sebastian-roth inits are updated on fogproject main. Thank you.
The stopping tells me, nearly 95% sure, that there ARE gpt structures left on the disk.
If you can create the tasking you need as a debug task (Host->Basic Tasks->Advanced Tasks->(Upload/Download) - Debug
It should boot your client machine into a console/tty screen (Command prompt if you must).
When there, type:
fixparts /dev/sda
Confirm the information as you see fit, and write the data. I think it will ask you to confirm (type Y, then you need to write the changes to the disk by typing w, then confirming the changes)
Once back at the command prompt, type the command fog
The system should start uploading its image to the server.
I was able to replicate and produce a fix for this.
The fix is in the git branch working-1.5.1.
Thanks for reporting.
If it’s getting “past the menu too fast” my guess is your system is getting a Console display error. This has been fixed in the Dev (trunk) versions of FOG, but can be relatively easily fixed in 1.2.0. Simply open the /var/www/fog/lib/fog/BootMenu.class.php file and find the lines that contain the phrase console. Comment them out with: //.
Found the problem and have a fix for it. If the maxClients are set to 0, the problem was the node was returning a division by 0 (not allowed in normal math either). This caused the lookup to fail with an error.
I’ve corrected this error in the working branch if you want to install it.
cd /path/to/fogproject/git
git checkout working
git pull
cd bin
./installfog.sh -y
@alli
Yep,
Make sure your network is good to go. In some cases you may also need to power down completely, and “cold” start the system.
First, check the network though. I actually saw this exact issue today. All other systems were perfectly fine, it was just this one system that had the issue. Replaced patch cable and restarted system. Everything succeeded.