This seems to indicate to me that something is not installed correctly.
FOG’s Cloud logo is also missing, which is why I’m thinking the website itself is failing due to missing files. The information just seems to not exist. (Maybe permissions I suppose but only if they’re much lower).
Please try rerunning the installer.
Also,
You state you had issues with SELINUX, what’s the output of sestatus?
Did you reboot and verify selinux stopped?
@rbaldwin Mind trying out the working-RC-7 branch?
I’ve created the postinitscripts stuff.
The way it works is VERY similar to postdownload scripts, but runs before anything dealing with taskings is called (within the /bin/fog script).
It’s a “first” attempt so there may be some issues…
The “quick and dirty” documentation:
FOG Will create a folder in the capture folder of the server called postinitscripts. (E.G. typically /images/dev/postinitscripts)
FOG Will create a folder in the capture folder of the server called postinitscripts. (E.G. typically /images/dev/postinitscripts)
This will happen on the installer if the postinitscripts folder does not already exist.
/bin/fog script (last part of S99fog IIRC) the postinitscripts directory will be mounted.When calling scripts I like to lean more to sourcing in the script rather than implicit call (. somescript vs somescript) as it will allow “fallthrough” of variables/functions within your postinit that you could use later on (say postdownloadscripts for example).
The fog.postinit script should really only be used to call other scripts but this is not a requirement. It is, after all, a bash script.
The scripts you want to use for postinit must go in the postinitscripts directory. They will also need to be executable. (Normal script type stuff).
The sourced path is to the mountpoint naturally and stored in the variable $postinitpath.
You can directly get the path you want, but this variable should be used in my opinion.
In the case of download scripts the image mountpoint will always be:
/imagestorelocationonserver->/images.
In the case of upload scripts the image mountpoint will always be:
/imagestorelocation/dev->/images
In download mode, the dev folder would be visible directly. So a path of /images/dev/postinitscripts/somescript would work.
In upload mode, the dev folder would not be visible. So postinitscripts would never be accessible if you left the /dev/ in the path. I’ve added corrective items for this postinit to try to make sure this would not break the variable and skip it.
Hopefully all will be well and I got it right the first go around (highly unlikely but I can be hopeful right?) The init’s have been updated and should support this. I will run a test just to see (though I’m not mounting I should be able validate the system is working.
The older export system (1.2.0 and earlier back to 1.0.0 when it was introduced) didn’t take into account the tables existing. The way this would typically work, though, would be to simply clear out all of the tables in the fog database and apply what was being passed in.
For whatever reason, the exported backup file was not dropping the fog database when the import was being kicked off.
The fix, as we already had the original exported db, was to drop the fog database, recreate it, and let the sql file import the rest back in.
We did this via command line just to ensure all was well.
mysql -u root fog < fogdb.sql
Please uninstall the location plugin, and reinstall it.
Yes you will have to make your associations again, but this is the easiest way I can think of to fix the problem.
See here:https://forums.fogproject.org/topic/9279/problems-creating-deploy-location-plugin/6
For all to see and understand what’s happening.
1.3.0 had some strangeness I was unaware of. This things were:
1.3.1 corrected these issues. Apparently at schema version point 136 and 140 there was an issue in creating the primary fields. These two schema versions handled the creation of imageGroupAssoc and snapinGroupAssoc.
These issues have been corrected for in 1.3.1 (and are of course present in 1.3.2). If you’re running into these issues, please open mysql and run:
ALTER TABLE `fog`.`imageGroupAssoc` ADD COLUMN `igaPrimary` ENUM('0','1') NOT NULL;
ALTER TABLE `fog`.`snapinGroupAssoc` ADD COLUMN `sgaPrimary` ENUM('0','1') NOT NULL;
This would only pose a problem for those that were running on trunk builds that had a schema after these points. If either of them error on the command line (or in phpMyAdmin if that’s what you’re using) please just let me know. If you’re getting the Database ID 236 issue though, I’m pretty sure at the least the alter table of the igaPrimary above will work without any errors.
@george1421 The reason it doesn’t say FTP is because there’s actually multiple actions that happen. If it’s not FTP (which sounds like it isn’t here) then it could be the Disk Space of the FOG Server.
The “Updating Database” is more of a “We have to do a bunch of actions and I wasn’t really thinking about all those actions when the init scripts were created so here’s your all or none type message”.
Seeing as FTP appears to be okay, there could be a permissions issue meaning if you run:
chmod -R 777 /images (Changing /images to your actual nfs image storage location) things should work.
If disk space is the issue, then you’ll likely need to add more space or figure out what is eating it.
The apache error logs issue is a known thing that I cannot really do anything, from the installer side, to fix.
This is due to log rotate changing the permissions on the apache log files every so often (whatever that timeframe/sizeframe maybe). The logrotate daemon is changing the permissions to settings that are unreadable from the GUI. (I think it’s setting the files to 644 when to read the files they should be 655 at a minimum (though 755 is probably a safer bet).)
@abos_systemax Yes, all ipxe files use the same embedded script.
You can see the embedded settings here:
Non-EFI: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript
EFI: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src-efi/ipxescript
Try this please:
wget --no-check-certificate http://mastacontrola.com/fog_1.3.4.tar.gz
tar xzf fog_1.3.4.tar.gz
cd fog_1.3.4/bin
./installfog.sh -y
Also, when installing FOG, we aren’t using a basepath pattern to find files, we use relative paths as basepath patterns would still have a hard time finding the required files.
Running the installer with ./bin/installfog.sh is not viable. You must first: cd bin then ./installfog.sh
@Doppelgrau said in Trouble setting up FOG 1.3.3 (PXE-boot problems and Kernel panic):
And booting vith PXE (no help from USB thumbdrive with gpxe) I see some PXE initializiation, that chainloads iPXE and then it stops. (The IMGP_0164 Screenshot)
Mind reuploading your picture? IT can take a second or two to see the picture, but you should see it show up in the preview window when all done uploading. If you “submit” too fast the picture will not be fully loaded and will not display.
This is sounding more and more like the device is getting information from pxelinux.0. In particular the messages about “Pre-eXecution Boot Environment.”
If I recall properly, this message get’s displayed by the ipxe.krn file which would ONLY happen if pxelinux.0 file is being called (unless somebody else made a change).
Would you mind trying:
mv /tftpboot/pxelinux.0{,_bak}
cp -p /tftpboot/{undionly.kpxe,pxelinux.0}
FOG 1.1.0 did not have the “new” client and these folders did not exist.
Chances are, when you updated, you didn’t update the FOG Client on your host machines. This ultimately means you will not lose control of your hosts.
You might lose the ability to join to the domain, temporarily, as the FOGCrypt password should be set in the now legacy labelled form field. (For both the default global and host ad fields).
Disk space? Permissions? /home/fog actually exists?
I confirmed the issue on updating kernelDevice not returning the value stored to all hosts in the group. This is fixed for the 1.3.4 tree. As for the “adding a host should get the items I set all the time”, both @george1421 and @Wayne-Workman are correct.
The group “feature” is just meant to be a means to update a group of hosts en-mass. While I certainly understand the “confusion” the reason it doesn’t update the hosts in the group automatically is because hosts can belong in multiple groups at the same. This way you could setup a full lab for specified settings in group, and add one of those hosts (or more of course) to another group to apply “specialized” settings.
For example:
You have classroom with 20 computers in it. Each of those computers need say a “room” printer associated to it. One of those computers is the teacher machine and needs a “confidential” printer for reports or whatever. (Let’s say that confidential printer needs to be on all teachers printers.)
Add the full room to one group to apply it’s settings. Apply the one computer to the group to the “confidential” printer group and apply the printer ONLY to that host.
Hopefully that makes sense on the “principle” behind groups.
You can achieve, however, the idea of “persistent groups” with the plugin @Wayne-Workman told you about.
@digi I am so very confused. Without knowing what it is you’re needing, it’s difficult to provide help to you. That said, if you sysprep the system (you don’t need the install media to do this), and capture your image in a sysprepped state, all of your machines will have a unique SID.
@lawrence1997 That’s 100% incorrect.
/tmp/pigz1 is nothing more than a FIFO (File in, File out).
All images, capture and deploy, get sent to this file. It’s nothing more than a memory buffer.
@digi if you don’t have access to windows, you don’t have access to change the sid.
@lawrence1997 I dont’ know what you mean.
FOG captures images to your Storage Location’s dev folder.
In a typical fog server you have a storage location structure similar to:
/images
/images/.mntcheck
/images/postdownloadscripts
/images/dev
/images/dev/.mntcheck
The main storage (mounted read only for clients being deployed to) is /images.
When uploading, a folder is created in /images/dev with the systems mac address in lowercase form without any special characters. So WHILE an image is being captured it would be uploaded into:
/images/dev/<macaddress>.
When the capture is complete, FTP is called and moves the /images/dev/<macaddress> to /images/<imagepathasdefinedingui>.