@maximillian What ISO are we needing?
FOG has an ISO for iPXE already available to it. It’s located under /tftpboot/ipxe.iso and should be plenty enough to boot your old and new systems.
I’ve personally never used the ISO itself, but I do know people have.
Found the issue and it is corrected for in the working branch.
It stemmed from the move to use the api backend. The pending display element was still using the old display methodology.
Hosts require two fields at minimum.
MACAddressListSeparatedWithPipe,Hostname
So the way it might look with a single mac would be:
00:00:01:01:02:02,SomeHostname
With multiple macs it may look like:
00:00:01:01:02:02|00:00:01:01:02:03,SomeHostname
For all other elements it’s based on the fields required to store the item which can be found in the respective class.
In the case of images you would have:
Name, Description, Path, created time, created by, building, size, imageTypeID, imagePartitionTypeID, osID, size, captured date, format, magnet, protected, compress, isEnabled, to replicate, server size,
Required fields are:
Name, Path, imagetypeID, osID
So a valid image csv with only required information would be:
somename,,basepathofimagefile-folder,,,,,1,,5
Of course if you wanted to use it right away you might have:
somename,,basepathofimagefile-folder,,,,,1,,5,,,,,,1,1,,
Feb 05 00:22:40 ianos.my.domain FOGMulticastManager[1669]: PHP Fatal error: Using $this when not in object context in /var/www/html/fog/lib/fog/multicastmanager.class.php on line 9
This is the line that’s causing issues.
First, I’m going to guess, and you can confirm, that you have two instances of FOG currently running. MulticastManager moved to /service/ folder for 1.4.4, so I’m guessing there’s a conflict.
To confirm, please provide output of:
ls -lhat /var/www
AND
ls -lhat /var/www/html
I suspect both “fog” instances will show up as individual folders, rather than one being a link to the other.
To fix quickly:
rm -rf /var/www/fog /var/www/html/fog
Rerun the installer.
@sebastian-roth, @developers, @moderators et al, I’ll go with the simple and true, “I’m back!” And I should be able to help a bit more than I have been able to recently. Not as much as before then but more than in the recent months once I rebuild my dev environment.
@BASURILLABAS2 The init’s are not the proper size.
Please rerun the installer.
I am locking this thread as the information we need to work out should first be done on the backend between the developers and few testers so we know what is feasible and have a more defined control set.
While I understand there may be many people interested in this, we have not done it and don’t want to put systems in a bad state where you can potentially lose your data due to failure to be able to boot to any OS anymore.
We will open a new thread once we have solidified a plan of action and tested feasibility.
@drc0nc I’ve marked this thread as solved as we were able to getting his working again. I had some relatively minor things that needed to be corrected and through teamviewer and a little time I figured out what the problem was. Hopefully this means the systems are bootable but I do know the system was taking the image and we already knew the system was able to upload.
In as simple terms as possible, no. We’ve found that the Goldilocks for compression is probably 5 or 6. This gives a semi balanced data across network and writing data to the hdd. The network throughout should be faster at max compression, but writing to disk takes a bit longer as it needs to decompress. Little/no compression is hell on network, but fast to write to disk as no/minimal decompression must happen.
@anthonyglamis I don’t know what reimaging would do to get active directory working. With that said I really wish you hadn’t have deleted the image. I’ve been working to make the scripts that do the work of imaging quite a lot lately. While some of those changes likely caused the problem you were having, it would have been better to keep the “bad” image and upload a new image. This would’ve at least had you do both things and given a point that i can look at. But that is now gone 
Of course I can still help but it would’ve been nice to fix the original problem you had. Only if you’re having issues with uploading would I say to delete the image, especially if you’re running trunk. I am very frequent on the forums and most often fix issues as they come up here.
This is addressed for 1.6 but was not added for 1.5. A lot of work had to go into 1.6 for the effects to take place. While it’s not too hard to add to the 1.5, I’ve been mainly focused on functionality bugs as those would also likely appear in 1.6. We’ve been working hard to get 1.6 going and just have a little further to go before getting to a testable state.
@anthonyglamis While that is potentially possible, the link must be unc, or prior mounted.
Remember, linux uses / for directory separation, but windows uses \ for directory separation.
Even if the samba share is mounted before it looks, you still need to tell it WHERE to look.
Prior mounting is not a good method though as when the service runs, it’s fully possible the mapping hasn’t been done.
Even with that, if the share is located at /opt/fog/, You would still need to access as:
\\ServerName\opt\fog\printerdriver\restoftheway (of course change the parts to get to the real location.
If the mapping has occurred you would change the value to:
DriveLetter:\opt\fog\printerdriver\restoftheway
Branches in GIT allow developers to separate code into elements while leaving other elements alone.
Typical structure for a repo in GIT will have at least 2 branches.
The first branch is typically master. This is the “top” level branch typically containing the current “stable” software version.
The second branch can be named nearly anything, and essentially would be akin to subversion’s trunk. Some GIT repos model their repos off of this and have a trunk branch. This might be where the next development work is at.
FOG’s structure is:
master The current stable release.
dev-branch the current RC release.
working-1.3.4 the development for the 1.3.4 version (currently.
newIpxeGeneration A branch where I’m refactoring ipxe menu generation.
persistentGroupPlugin A branch where i am (kind of?) working on a new model to the persistent group sql trigger stuff.
In git you clone a repo with a command like:
git clone https://<url>/<repoowner>/<reponame>[.git]
For fog this would be:
git clone https://github.com/fogproject/fogproject.git (The .git part is optional but normal to add as well.)
This will download whatever is the “default” branch to download. In FOG’s perspective, the default is master (now).
You do not need to “clone” the repo every time, it is only needed to initially download the repository information if you have not done so already.
If you’ve already retrieved the repo, you just cd into the base path. More often this might be /root/fogproject.
Once in the base path you can change branches. To get a list of all branches available you would run
git fetch --all
To view available branches run:
git branch The one with the * is the branch you’re currently on.
To switch to one branch or another run:
git checkout <branchname>
So to switch from the master to dev-branch in our scenario you would run:
git checkout dev-branch
Hopefully that helps answer that.
As a word of caution I’d also highly recommend always running git pull when you change in and out of branches. This will pull in any new changes.
I don’t understand.
The snapin system IS one at a time. If your snapins are running in “background” this is a piece of the snapin itself returning an exit code to the client making the client believe it has completed that previous run.
Done as requested. After all, people do like choices.
I’ve implemented the requested feature, but I do NOT know if it will work.
To set the bitrate, it’s a Per Node (master of course) setting.
You can set it how you see fit, appropriate to the way it’s set to the command. meaning you can setup the variable with 1000000, 1000k, or 1M
@Wayne-Workman Customization is the game, and Tom is my name.
Printer copy feature added for both Add and Edit printers. Due to the nature of how these things need to work, creating a printer will not automatically transfer you into the printer you just created, rather it will enable you to create another printer immediately.
Messages from the edit/add will display like normal in the top for a 5 second period, then will fade out into the abyss somewhere in the annals of time.
Try setting shutdown=1 in the FOG_KERNEL_ARGS. This should have the same effect you’re wanting.
I don’t think changing the color should matter at all. If people are clicking the button, I don’t think the reasoning for the clicking is color based or not.
That said, what is the “warning” for? If you’re capturing an image, you’re capturing an image. if you don’t want user’s to accidentally overwrite an image, why not just set the image to “protected” and/or change the files so they’re immutable?