Posts made by BryceZ

We’re looking into different solutions for managing the codebase and facilitating easier user contributions. But at the moment that’s on hold until 0.33 is released. After talking to the devs about this, the current solution is to either post patches here or use the Sourceforge project patch tracker.

Ah, I overlooked the ntfsresize test portions of the script. Try just replacing “$RUN_CHKDSK” on line 391 with “-n -s 10G”.

Does the fog account have write permissions to that directory?

Are you able to connect via FTP?

Are the fog username and password correct in FOG Settings ([URL=‘https://fog.classroom.ohio-state.edu/management/index.php?node=about&sub=settings’]http://<YOUR FOG SERVER>/management/index.php?node=about&sub=settings[/URL] FOG_TFTP_FTP_USERNAME and FOG_TFTP_FTP_PASSWORD)? This is referring to the user account on the server, not the user account on the FOG web console. This is the account that is used to FTP the files. If the account exists, and the settings are correct, and you’re still having problems with creating tasks, then I’d say check that the FTP service is running:
[CODE]/etc/init.d/vsftpd status[/CODE]

When a task is created in FOG the web server creates a small boot file for the client using the client’s MAC address as the file name. The web server uses FTP to push that file onto the TFTP server so that when the client PXE boots it will look through all the files on the TFTP server and grab the one with it’s MAC address in the name. If no MAC address specific file is on the TFTP server then the client uses the default file. The MAC specific file contains the task information, so if the file isn’t there then the client won’t realize that it has a task.

The short answer is no. FOG does not give you the ability to adjust the resize size. However, if you’re really interested in making this happen, it is technically possible; to do so you would have to [URL=‘http://www.fogproject.org/wiki/index.php/Modifying_the_Init_Image’]modify the FOG boot image[/URL] so that instead of resizing to the full space of the disk it only resizes to 10GB.

You would have to modify /bin/fog on the boot image. Easiest probably to just modify the $RUN_CHKDSK variable (line 42 if you’re using FOG 0.32).
[CODE]RUN_CHKDSK=“-n -s 10G”;[/CODE]

Unfortunately those are two very different image formats, and there are no converters. So you will have to deploy via Ghost and upload via FOG.

That actually looks like an FTP issue to me. The FOG web server FTP’s the MAC specific boot file to the TFTP server when creating a task. If you’ve changed the password or permissions on the TFTP server, or have a firewall blocking FTP, or the FTP service isn’t running, then you won’t be able to add those files.

I think it’s something like:
[CODE]UPDATE fog.images SET imageID=25 WHERE imageID=24;[/CODE]

That is the source file that can be used to build the boot image, but the installer comes with a prebuilt boot image, so modifying the file only helps if you’re going to rebuild the boot image.

Here is the wiki page on modifying the boot image: [url]http://www.fogproject.org/wiki/index.php/Modifying_the_Init_Image[/url]

You might also find this useful: [url]http://fogproject.org/forum/threads/scaling-fog-for-the-enterprise.4189/[/url]

What about trying to install php-gettext manually?

[CODE]sudo apt-get install php-gettext[/CODE]

OK, I just reread through your default file very closely…

Is the line:
kernal chain.c32
Or:
kernel chain.c32

Off the top of my head, it sounds like a bad hard drive; could be either server or host.

Are you pushing these images from the same server? Are they going to the same host? Were there any problems with uploading the Windows 7 image?

The shell scripts actually call the package manager to grab all the packages and then afterward the shell script overwrites the config files with the ones FOG needs.

Setting up FOG on a distro other than RHEL or Ubuntu is going to take some leg work. Even installing on Debian, which Ubuntu is based on, isn’t perfect with the official FOG installer, and it mostly comes down to two things: file paths and package names.

The big problem is mostly just finding out what the packages are named in whichever distro you choose; keeping in mind that two packages in Ubuntu might actually be one package in your distro, or one Ubuntu package might be split between multiple packages on your distro.

Once you have all the package dependencies sorted out, then you need to figure out where they store their files. Example: On Ubuntu the default web directory is /var/www/, but RHEL uses /var/www/html/ (side note: The Ubuntu Apache user is www, while the RHEL Apache user is apache).

The FOG server needs a LAMP stack, a TFTP server, an FTP server, an NFS server, and optionally a DHCP server. Glancing at the install scripts just now I notice that it also wants an SSH server, but I don’t recall what part of FOG uses SSH…

The distro dependent scripts, which list all the packages and file paths, are in <FOG installer directory>/lib/.

The only other way to massively remove hosts is to access the database directly and remove them from there. It’s easy if you want to just remove all of them:
[CODE]TRUNCATE TABLE hosts;[/CODE]
Or if you have some known host value that you can leverage; such as all hosts currently assigned imageID 3:
[CODE]DELETE FROM hosts WHERE hostImage = 3;[/CODE]

If you’re not used to messing around in MySQL then you might want to consider installing phpmyadmin, which will give you a web interface for managing the database.

At this point I’m not sure where the problem is. I have a couple hundred 790’s using the syslinux 4.04 files and the same fog.local option in the default file.

I would suggest backing up your /tftpboot directory and copying the original tftp directory from the installer in its place, and then walking through the steps in the wiki again using syslinux 4.04.

Sometimes the quickest fix is to just go back and do it again.

… And then I just had a thought; check the permissions on those files you replaced. I’m not sure how it would affect the boot process if it tried to call chain.c32 and found it couldn’t because of permissions, but that might be it.

OK, everything looks good there, so let’s check the BIOS.

In the BIOS, under Settings -> General -> Boot Sequence, is the Boot List Option set to Legacy? Also, under Settings -> System Configuration -> SATA Operation, is it set to AHCI? Not sure how those settings might affect chainloading, but they seem like they might play a role.

Another point to consider, these workstations/servers, are they using the onboard ports or are they configured in some sort of RAID?

Ah, sorry, I misunderstood. I thought it was only some of your workstations/servers that were failing to boot properly. Can you post your /tftpboot/pxelinux.cfg/default file? One other thing that comes to mind: what version of syslinux did you use to replace the files with? There were certain versions that had issues with chainloading.