Known FOG Bugs - Revision history

Wayne-workman.28155: Changed terminology to use capture instead of upload.

2016-07-08T04:45:08Z

Changed terminology to use capture instead of upload.

Wayne-workman.28155: /* Description */ Updated this to better reflect reality.

2015-09-09T01:25:04Z

‎Description: Updated this to better reflect reality.

Wayne-workman.28155: /* Working around the bug */

2015-05-25T03:19:12Z

‎Working around the bug

Wayne-workman.28155: /* dnsmasq ProxyDHCP .0 bug */

2015-05-25T03:17:38Z

‎dnsmasq ProxyDHCP .0 bug

Wayne-workman.28155: /* Description */

2015-05-25T03:16:50Z

‎Description

Wayne-workman.28155: /* dnsmasq ProxyDHCP .0 bug */

2015-05-25T03:12:35Z

‎dnsmasq ProxyDHCP .0 bug

Wayne-workman.28155 at 03:12, 25 May 2015

2015-05-25T03:12:00Z

Wayne-workman.28155: /* Fixing your image */

2015-05-22T19:26:49Z

‎Fixing your image

Wayne-workman.28155: /* Description */

2015-05-22T19:26:35Z

‎Description

Wayne-workman.28155: /* Description */

2015-05-22T19:26:12Z

‎Description

@@ Line 15: / Line 15: @@
 Resize bugs are unrelated to boot-files and kernels.
-When an image is uploaded as "resizable", the resync process immediately after resizing does not occur. This means that although partitions were actually resized on the host, the upload 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 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.
@@ Line 53: / 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 upload task, and upload the new image.
+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.

@@ Line 13: / Line 13: @@
 === Description ===
-This bug became present sometime around the r3200s and was corrected in r3396. It is unrelated to boot-files and kernels.
+Resize bugs are unrelated to boot-files and kernels.
-When an image is uploaded as "resizable", the resync process immediately after resizing does not occur. This means that although partitions were actually resized on the host, the upload used the prior partition data pulled from the drive and not the new information.  Any resizeable images created between r3200 and r3395 could be (and probably are) affected.
+When an image is uploaded as "resizable", the resync process immediately after resizing does not occur. This means that although partitions were actually resized on the host, the upload 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.

@@ Line 91: / Line 91: @@
 Copy needed file to correct name
-<pre>copy example</pre>
+<pre>cp /tftpboot/undionly.kpxe /tftpboot/undionly.0</pre>
 Symbolic link the file to the correct name
-<pre>symlink example</pre>
+<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]]

@@ Line 73: / Line 73: @@
 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
+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:

@@ Line 69: / Line 69: @@
 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), or simply don't have any DHCP device on their network, they normally would use dnsmasq for ProxyDHCP.
+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

← Older revision		Revision as of 03:12, 25 May 2015
Line 97:		Line 97:


		+	=== 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]]		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]]

← Older revision		Revision as of 03:12, 25 May 2015
Line 58:		Line 58:

	You may now delete the old image.		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), 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
		+
		+	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>copy example</pre>
		+
		+	Symbolic link the file to the correct name
		+	<pre>symlink example</pre>
		+
		+
		+	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]]

← Older revision		Revision as of 19:26, 22 May 2015
Line 43:		Line 43:


−	To fix the image, first update to FOG ~~revision 3396~~ or later, and install an HDD of equal or greater size than the source machine had.	+	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.

← Older revision		Revision as of 19:26, 22 May 2015
Line 15:		Line 15:
	This bug became present sometime around the r3200s and was corrected in 3396. It is unrelated to boot-files and kernels.		This bug became present sometime around the r3200s and was corrected in 3396. It is unrelated to boot-files and kernels.

−	When an image is uploaded as "resizable", the resync process immediately after resizing does not occur. This means that although partitions were actually resized on the host, the upload used the prior partition data pulled from the drive and not the new information. Any images created between ~~2920 - 3277~~ could be affected.	+	When an image is uploaded as "resizable", the resync process immediately after resizing does not occur. This means that although partitions were actually resized on the host, the upload used the prior partition data pulled from the drive and not the new information. Any resizeable images created between 3200 and 3395 could be (and probably are) affected.