Posts made by BryceZ

Darren, FOG does not currently support Mac imaging. [url]http://fogproject.org/forum/threads/mac-feature.3727/#post-9042[/url]

OSX uses HFS+ which is not supported by Partimage, the application that does the actual imaging, so it’s not an option at this point. However, there has been some consideration of adding Partclone to FOG, which does support HFS+, but we’re not there yet.

As far as I’m aware, you can currently use Linux images on a Mac (at least I can’t think of a reason why that wouldn’t work), except for the tiny problem of Mac’s not supporting PXE, so they have no built in method of “booting into FOG”. You [I]can[/I] use pxelinux or ipxe on a bootable disk to get the Mac’s to PXE boot, but then you’ve got to carry around a bootable disk.

Unfortunately there is no scripted way to merge FOG into your environment. If you’re not comfortable with ripping apart open source software like this, knowing that you’ll have a harder time when it comes to troubleshooting, then I’d say you need to rethink your approach to FOG. A standalone FOG server is definitely the easiest to setup.

If you really [I]really REALLY [/I]want to merge FOG into your already existing infrastructure then I’d suggest installing FOG on a separate machine and pulling the pieces into your setup one at a time (unless you really like hacking away at installation scripts).

The testing thread is [url]http://fogproject.org/forum/threads/bugs-in-fog-0-33.631[/url]. Feel free to jump in and give a hand, just make sure you’re not cluttering up the thread with useless questions (search before you ask).

As for a release date… when it’s ready. I know that’s not the answer most people are looking for, but it’s the truth. There are three FOG developers, each with real jobs that keep them busy. If more people help with testing then the devs can spend less of their own time tracking down bugs and more time fixing them.

Last time I spoke with the devs it seems we’re still having an issue with non-sysprep images that are resizeable. If people are interested in providing more testing and feedback, here is a list of scenarios to test (taken from Blackout’s todo list):

[LIST]
[]Windows XP - NTFS, Multi
[]Windows 7 x86 - One & Two partition layout - with & without sysprep - NTFS & Multi types
[]Windows 7 x64 - One & Two partition layout - with & without sysprep - NTFS & Multi types
[]Windows 8 x86 - One & Two partition layout - with & without sysprep - NTFS & Multi types
[]Windows 8 x64 - One & Two partition layout - with & without sysprep - NTFS & Multi types
[]Windows Vista x86 - One & Two partition layout - with & without sysprep - NTFS & Multi types (not critical)
[]Windows Vista x64 - One & Two partition layout - with & without sysprep - NTFS & Multi types (not critical)
[]Multicast
[/LIST]

Take a backup of your database first
[CODE]mysqldump -u root -p[root_password] [database_name] > dumpfilename.sql[/CODE]
Then log in to mysql and run the repair
[CODE]mysql -u root -p[root_password] [database_name]
REPAIR TABLE tbl_name;[/CODE]

0.33 is a major rewrite of the underlying code structure (new classes, new objects, etc.), so it is possible that your patch will no longer function. You can test it by pulling down the latest development copy of 0.33, which is mostly completed. I’d highly suggest doing this on a test server or VM.

[CODE]svn co https://freeghost.svn.sourceforge.net/svnroot/freeghost freeghost[/CODE]

Matt, generally when the upload fails partway through it’s because of a hardware issue with the client. Have you tried running chkdsk?

Try…
[CODE]sudo chown -R fog.fog /images[/CODE]

Thanks SomeOne! I’ll give this a try once things settle down here at work.

The port range could probably be scaled back, but I never got around to narrowing each range. From what I’ve come to understand (keep in mind that I’m not a network admin) most protocols have designated ports for establishing connections and then use random ports from the higher port range (generally 1024+) for the actual transfer. Some applications, such as UDPCast, allow you to specify the transfer port range, but that’s not always the case. So you probably don’t need the whole range but you’ll need some of it.

If I recall correctly, that message occurs directly after the image has uploaded when FOG is trying to remove the client file /tftpboot/pxelinux.cfg/<MAC-Address>. At this point you have a successful image uploaded, but rebooting the client will start the task again because the task file still exists. The one time fix is to just browse on the server to /tftpboot/pxelinux.cfg/ and delete the file named 01-<MAC address>, that will end the task.

Ah, sorry, I forgot you mentioned that you had renamed the image… hmmm… I’ve encountered this message before, but it’s been a while…

And you are able to unicast this image just fine?

Have you tried the steps in [url]http://fogproject.org/wiki/index.php/Troubleshooting_a_multicast[/url]?

hmmm… can you copy and paste the following command into the server and then post the output?
[CODE]ls -lsah /images/Image-20120911/[/CODE]

Does this image have a name with spaces or other non-alphanumeric characters?

Just a guess, but it looks like you have bad sectors on the hard drive. You can try running a few drive diagnostic tests to see if you can track it down and repair it, but you might just need to get a new drive.

Unfortunately I’m not very familiar with the source code for the client, but there is the Additional MAC Address field on the host edit page. Adding the wireless NIC MAC address might take care of this, but again I’m not 100% sure without seeing what the client code is doing. Worth a shot though.

This requires the disk geometry to be identical on all machines you’re deploying to…

Collect a multiple partition image, go into /images/<image name>/, delete the d: partition (d1p2 for XP, d1p3 for Vista/7).

When you go to deploy the image it might complain that it can’t find the last partition, but I’m pretty sure it’ll complete the task just fine.

Pigz is multithreaded gzip. The three potential issues that come to mind are:
[LIST=1]
[]The server you’re uploading to is out of space
[]The host you’re uploading from has a bad sector or some other hard drive issue
[*]Networking issue that prevented pigz from writing out to the server
[/LIST]
Have you tried to upload more than once? Does it happen at the same point every time?

Robin is correct, you would need to manually edit the database to reuse old image ID’s. I seem to recall there being some talk of possibly changing this functionality in the future, but for the time being you’re stuck with manually changing them.