Posts made by BryceZ

The TTL is 32. It’s set in /opt/fog/service/common/lib/MulticastTask.Class.php.

The image definition is what you actually create with the FOG interface. Basically follow all the steps for creating an image with FOG, just don’t actually create an upload task, and then copy the image files created with PING to the directory specified for the image file.

Technically… maybe? FOG and PING both use Partimage to create and restore images, so it is possible that you’ll be able to take your PING created images and shove them into FOG manually (create the image definitions and copy the image files into the /images/<image name>/ directory), but I am unaware of anyone attempting this.

Did you add/replace the files listed in the [URL=‘http://www.fogproject.org/wiki/index.php?title=FIX:_Chainloading_alternate_SYSLINUX_to_force_boot_from_first_hard_drive’]chainloading[/URL] article on the wiki?

With Single Partition type images FOG does rewrite the MBR. With The Multiple Partition types FOG just clones the MBR.

Partclone is in FOG’s new boot image, however the scripts that are triggered for imaging still call Partimage. At this point the option to switch the “imaging engine” has not been fleshed out in the UI, so if you would like to test Partclone you would need to do it manually.

If there was a password before then it would be listed in /var/www/fog/commons/config.php as MYSQL_PASSWORD. If there is no password listed there then I would guess that during the upgrade process you were prompted to provide a new password for mysql.

Try pulling up a terminal and running…
[CODE]service mysql status[/CODE]
To make sure the mysql server is actually on.

If it spits back “mysql stop/waiting” then it’s currently off, so run…
[CODE]sudo service mysql start[/CODE]

Chainloading is a workaround for a bug most often seen with Dell BIOS, and does add additional levels of complexity that do not need to exist for everyone. So the developers are hesitant to build chainloading in. And as long as it’s simple to implement after the fact they’d prefer to keep it that way.

I would hazard a guess that you’re sites are far enough away from the TFTP server that they’re timing out. I’m not sure where the documentation exists at this point, as it was just a user modification that did this and not something official, but you can set up remote TFTP servers (generally just add the TFTP service to a remote FOG node) and then use NFS to share the /tftpboot/pxelinux.cfg/ directory from the main site’s TFTP server to the node sites’ TFTP servers. If your issue is TFTP timeouts then that would take care of it.

Have you added the wireless MAC addresses as additional MAC’s on the host’s page? I could be wrong, but I was under the impression that the additional MAC feature was built to address this issue.

Off the top of my head I’d suggest editing /etc/init.d/S99fog and adding a conditional statement like
[CODE]if [ “$mode” != “inventory” ]; then
sh /bin/fog.inventory;[/CODE]
before the rest of the $mode checks.

So…
[CODE]afterActionTerm=“reboot -f”;
if [ “$shutdown” = “on” ]
then
afterActionTerm=“poweroff”;
fi

if [ “$mode” == “debug” ]; then
[/CODE]

becomes…

[CODE]afterActionTerm=“reboot -f”;
if [ “$shutdown” = “on” ]
then
afterActionTerm=“poweroff”;
fi

if [ “$mode” != “inventory” ]; then
sh /bin/fog.inventory;

if [ “$mode” == “debug” ]; then
[/CODE]

Warning: That was off the top of my head and has not been tested.

As far as I am aware, 0.33 is NOT backward compatible at this point. Some database tables have been modified, in ways that don’t align with 0.32, which can cause plenty of errors. I would recommend simply performing a clean installation of 0.33 and then importing your hosts using the host CSV upload method (not sure if this functionality has been tested recently so it might not function correctly, but it is the quickest method I am aware of).

if you boot a host into debug mode you can run the command
[CODE]uname -a[/CODE]
which will spit back the kernel version along with other info.

If you have a Windows machine on the network, pull up an explorer window and go to \<ip address of FOG server>\images.
If you have a Linux machine on the network, pull up a terminal and type…
[CODE]sudo mkdir /mnt/images/
sudo mount -o nolock <ip address of FOG server>:/images /mnt/images[/CODE]
Then just browse to an image file and try to copy it locally.

What about pulling down one of your images over NFS “normally”? As in mounting the server drive and grabbing a copy of the image from a desktop. How fast does that transfer?

I’m just trying to narrow this down to specific conditions that could cause this type of issue. If you’re able to upload the image at a more reasonable rate then it’s not all NFS transfers, and if you’re able to grab the image over NFS from something other than the FOG boot image then it’s not the FOG server, which means it’s something to do with the boot image.

How fast does the upload transfer?

Out of curiosity, what happens when you upload a new image?

The swap partition is just used for paging in to and out of RAM, there is no need to upload the partition itself so FOG skips it. The MBR has the swap partition geometry, so there will be a new swap partition on the system you deploy the image to.

For those of you experiencing menu looping, please post your /tftpboot/pxelinux.cfg/default file, and perhaps the steps you took in setting up the chainloading. Anything that helps us pin down what’s causing this issue is important.

One thing to consider: the chainloading will return you to the menu if the device you’re booting to does not have a boot partition (though it usually displays an error message for a few seconds before reloading the menu). I’m not sure how it would handle being pointed at a hardware address that does not exist; it is possible that your systems are setup in such a way that your drive is listed as hd1 instead of hd0, which [I]might [/I]be contributing to your problem.

I don’t know why there would be an issue between 32bit and 64bit, though I won’t go so far as to say it’s impossible. I’ve been chainloading from both 32bit and 64bit to both 32bit and 64 bit, and I’ve never encountered an issue.