Difference between revisions of "Known FOG Bugs"
m (Changed terminology to use capture instead of upload.) |
|||
| (15 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
=== Description === | === Description === | ||
| − | + | Resize bugs are unrelated to boot-files and kernels. | |
| + | |||
| + | When an image is captured as "resizable", the resync process immediately after resizing does not occur. This means that although partitions were actually resized on the host, the capture used the prior partition data pulled from the drive and not the new information. Resize bugs seem to sneak in from time to time. If you find it in a current FOG Trunk revision, post it to the forum so it can be addressed. | ||
| − | |||
When downloading an image to hosts that have the same size HDD as the source machine, or a larger size HDD as the source machine, imaging completes as normal. | When downloading an image to hosts that have the same size HDD as the source machine, or a larger size HDD as the source machine, imaging completes as normal. | ||
| Line 22: | Line 23: | ||
Some hosts will never get to the partclone process, some hosts do but fail during the imaging process. | Some hosts will never get to the partclone process, some hosts do but fail during the imaging process. | ||
| − | |||
=== Verifying your image is affected === | === Verifying your image is affected === | ||
| Line 28: | Line 28: | ||
Start a download task with debugging. | Start a download task with debugging. | ||
| − | Run this command: | + | Run this command on your host: |
| − | < | + | <pre>fdisk -l</pre> |
Examine the output. | Examine the output. | ||
| − | + | [[File:Re-Size Bug.jpg]] | |
| + | |||
| + | Look closely at the three highlighted areas. The first is the command issued, the second is the size of the installed HDD, the third is the size of the image's partitions. | ||
| + | '''If the partition data is larger than the size of the installed HDD, your image is affected.''' | ||
=== Fixing your image === | === Fixing your image === | ||
| − | To fix the image, first update to FOG | + | To fix the image, first update to FOG r3396 or later, and install an HDD of equal or greater size than the source machine had. |
Deploy your image to this host with the larger HDD. | Deploy your image to this host with the larger HDD. | ||
| Line 50: | Line 53: | ||
Create a new image, be sure to mark it as "resizeable" along with any other necessary settings, and assign this new image to the host using the FOG Web UI. | Create a new image, be sure to mark it as "resizeable" along with any other necessary settings, and assign this new image to the host using the FOG Web UI. | ||
| − | Create a new | + | Create a new capture task, and capture the new image. |
The new image should now be able to deploy to hosts with smaller HDDs than the source machine. | The new image should now be able to deploy to hosts with smaller HDDs than the source machine. | ||
| + | |||
| + | You may now delete the old image. | ||
| + | |||
| + | |||
| + | == dnsmasq ProxyDHCP .0 bug == | ||
| + | |||
| + | |||
| + | === Description === | ||
| + | |||
| + | Last edited: May 24th, 2015 | ||
| + | |||
| + | First and foremost, dnsmasq is not developed by the FOG team. However, dnsmasq is utilized by many FOG users. dnsmasq is developed by [http://www.thekelleys.org.uk/dnsmasq/doc.html thekelleys], and we thank them for their amazing solution, it works very well. | ||
| + | |||
| + | For those that do not have access to their DHCP server, or have a device (such as a home router/switch/dhcp combo device) that doesn't support modification of DHCP settings, or simply don't have any DHCP device on their network, they normally would use dnsmasq for ProxyDHCP. | ||
| + | |||
| + | The dnsmasq .0 bug is quite simply - dnsmasq changes the extension of the bootfile information handed out to .0 | ||
| + | |||
| + | For example, say we must use dnsmasq and want to use undionly.kpxe as our bootfile. | ||
| + | |||
| + | When we configure dnsmasq to hand out the bootfile info: | ||
| + | <pre>undionly.kpxe</pre> | ||
| + | |||
| + | dnsmasq will instead hand out: | ||
| + | <pre>undionly.0</pre> | ||
| + | |||
| + | === Verifying the bug === | ||
| + | |||
| + | Every FOG server using dnsmasq is affected by this bug. | ||
| + | |||
| + | |||
| + | === Working around the bug === | ||
| + | |||
| + | Assuming we will be using undionly.kpxe as our bootfile, there are two possible work arounds. Both are very simple. | ||
| + | |||
| + | Copy needed file to correct name | ||
| + | <pre>cp /tftpboot/undionly.kpxe /tftpboot/undionly.0</pre> | ||
| + | |||
| + | Symbolic link the file to the correct name | ||
| + | <pre>ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0</pre> | ||
| + | |||
| + | === Further Info === | ||
| + | For further information on configuring dnsmasq to use for ProxyDHCP, see this article: [[Using FOG with an unmodifiable DHCP server/ Using FOG with no DHCP server]] | ||
Latest revision as of 04:45, 8 July 2016
For those that make additions to this article, please include relevant Versions/Revisions, dates, and ample details (and hopefully fixes / workarounds).
Please Do-Not post things in here that haven't been discussed in the forums prior, or with a developer.
Contents
The Image Resize Bug
Description
Resize bugs are unrelated to boot-files and kernels.
When an image is captured as "resizable", the resync process immediately after resizing does not occur. This means that although partitions were actually resized on the host, the capture used the prior partition data pulled from the drive and not the new information. Resize bugs seem to sneak in from time to time. If you find it in a current FOG Trunk revision, post it to the forum so it can be addressed.
When downloading an image to hosts that have the same size HDD as the source machine, or a larger size HDD as the source machine, imaging completes as normal.
When downloading an image to hosts that have a smaller size HDD than the source machine, errors are encountered and imaging does not complete.
Some hosts will never get to the partclone process, some hosts do but fail during the imaging process.
Verifying your image is affected
Start a download task with debugging.
Run this command on your host:
fdisk -l
Examine the output.
Look closely at the three highlighted areas. The first is the command issued, the second is the size of the installed HDD, the third is the size of the image's partitions.
If the partition data is larger than the size of the installed HDD, your image is affected.
Fixing your image
To fix the image, first update to FOG r3396 or later, and install an HDD of equal or greater size than the source machine had.
Deploy your image to this host with the larger HDD.
Boot the host and verify all is well.
Shutdown the host.
Create a new image, be sure to mark it as "resizeable" along with any other necessary settings, and assign this new image to the host using the FOG Web UI.
Create a new capture task, and capture the new image.
The new image should now be able to deploy to hosts with smaller HDDs than the source machine.
You may now delete the old image.
dnsmasq ProxyDHCP .0 bug
Description
Last edited: May 24th, 2015
First and foremost, dnsmasq is not developed by the FOG team. However, dnsmasq is utilized by many FOG users. dnsmasq is developed by thekelleys, and we thank them for their amazing solution, it works very well.
For those that do not have access to their DHCP server, or have a device (such as a home router/switch/dhcp combo device) that doesn't support modification of DHCP settings, or simply don't have any DHCP device on their network, they normally would use dnsmasq for ProxyDHCP.
The dnsmasq .0 bug is quite simply - dnsmasq changes the extension of the bootfile information handed out to .0
For example, say we must use dnsmasq and want to use undionly.kpxe as our bootfile.
When we configure dnsmasq to hand out the bootfile info:
undionly.kpxe
dnsmasq will instead hand out:
undionly.0
Verifying the bug
Every FOG server using dnsmasq is affected by this bug.
Working around the bug
Assuming we will be using undionly.kpxe as our bootfile, there are two possible work arounds. Both are very simple.
Copy needed file to correct name
cp /tftpboot/undionly.kpxe /tftpboot/undionly.0
Symbolic link the file to the correct name
ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0
Further Info
For further information on configuring dnsmasq to use for ProxyDHCP, see this article: Using FOG with an unmodifiable DHCP server/ Using FOG with no DHCP server
