[quote=“VincentJ, post: 36284, member: 8935”]Are you thinking this could replace multicast? (which has had a ton of problems)
Or possibly become the main method of distributing images?[/quote]
i’m thinking of this being an alternative to multicast, but so far as i know there isn’t any intention to drop multicast support
this method won’t become the “main” method of imaging for a few reasons, one of them being that it isn’t as fast as unicast if you have hardware that can keep up (server, network, and client)

i don’t even know if it’s faster then multicast (since i’ve never gotten multicast to work, or tried very hard to do so)

[quote]Can the clients peer the parts of the image they have already in chunks or does it need the whole image to download to become a peer?[/quote]
as per a normal bittorrent download, the file is split into small “chunks” for transfer, and all clients that have downloaded a chunk can share it with others as soon as they get it
[quote]Is there a configurable time after the image finishes downloading on that machine that the client reboots to allow getting into the new OS, so people could have 5 minutes peering to speed up others and then reboot?[/quote]

a client continues to share the image while the computer is using, it only stops sharing when the computer is done imaging, so all clients should have a reasonable amount of time to finish downloading before clients stop sharing
[quote]Is there a tracker/torrent file that could be added to other torrent clients? easy setup storage node…[/quote]
yes, that is part of the intention. it is compatible with any standard bittorrent client, qbittorrent has been working best for me, for windows

i don’t think anyone has mentioned this so far, so i feel i should: FOG is not designed to be a backup solution. It is a systems deployment/management solution. Generally speaking, images are not expected to contain sensitive data (it’s usually just Operating System, and some programs, tweaked the way you want it).

i believe the problems you’re describing typically get resolved though network device configurations. check the settings on your switches.

@Sebastian-Roth said:

Who added torrent to FOG?

that was me. it worked through any network connection, so it had that as an advantage over multicast (tom even imaged a computer at his house from an image hosted in Kansas) and it didn’t hammer the server as hard as a bunch of unicast, but it never had the speed boost i wanted out of it.

@Joseph-Hales i hope to resurrect the method, but it’s going to be more complicated than the last implementation. i’m up for the challenge, it’s just hard finding the time.

host_namechange_early functions by editing the registry of the computer offline
fog 1.2.0 assumed a specific partition would be used for the operating system and only tried to edit the registry there.
the latest development versions of fog attempt the edit on all ntfs partitions.
upgrading to trunk will almost certainly resolve your problem.

the client reports all available mac addresses when checking for tasks. this means that, typically, the registered mac is sent with the pending tasks check whether it’s the one being used to connect to the network or not.

@Neil-Underwood i host my fog server on a esxi vm and this is the kind of deployment speed i get
https://www.youtube.com/watch?v=gHNPTmlrccM
i can’t imagine it being much faster than that
(SVN 3488)

in the default.ipxe file on your storage node (it is a plain text file) edit the IP to be that of your primary fog server

what kind of “boot settings” are we talking about here?

it can be done, but it would be easier to deploy the image to a computer (real or a VM) and recover the files from there

if you run top, how much of your cpu do these services utilize?

https://forums.fogproject.org/topic/9324/parted-magic-for-uefi-bios-boot?page=1

i’m not sure about btsync, i’ve never used that one.
wget would depend on where you’re pointing it to.
git and SVN are both valid ways to update

Ubuntu 10.04.4s ? any chance you’re willing to set up a new server on a supported operating system? you can migrate your images and database over.

@watson fog version, client version if you’re using it, windows version, image type (resizable, not resizable, etc) ?
btw, my dedicated fog test machine is an Optiplex 3020, i can assure you that there are no issues with this model and fog, so whatever the issue is, we can help you figure it out.

@george1421 said in Separate server for ipxe:

PXE boooting from the storage nodes may only resolve parts of your issue.

or possibly none. i suspect what you’re seeing is a product of a bug in 1.3.4 that has been fixed in later release candidates. before you set out to do anything complicated, try upgrading FOG.

@Almeida said in Multicast doesn't work:

FOG Version: 1.2.0
OS: Ubuntu 10.04

do yourself a big favor and upgrade your server OS and version of FOG. even if that doesn’t make muilticast work for you (it might) it will make your unicast deployments go faster, and make troubleshooting your issue easier for us.

@Gamienator the fog ipxe boot file is compiled to load /tftpboot/default.ipxe as soon as it starts. this is the writable file that we use to give a writable address location for the fog server, so we don’t have to recompile the boot file for every server.

normally, this file just gathers some information and chain loads

 http://<your-fog-server-address>/fog/service/ipxe/boot.php##params

this “file” is a dynamically generated boot file that will change according to scheduled tasks for that host

but, something you can do, and what i do to direct my testing machines to my development fog server and away from the production one, is add a few lines before the chain load like this

iseq ${serial} <your-machine-serial-number> && chain <alternative-boot-file-destination> ||

this reads
iseq (is equal)
${serial} (one of the pieces of info that we have ipxe already gathering and assigning to a variable)
<your-machine-serial-number> (the serial number of the host you want to redirect booting of)
&& (if previous condition tested true, do the next command)
chain (boot the following)
<alternative-boot-file-destination> (can be local to the default.ipxe, or http location, etc)
|| (if previous conditions fail, proceed to the available command instead of throwing an error)

these command descriptions aren’t exact, but effectively what’s happening here. for more info, check out ipxe’s website

@Benjamin_D you have been misinformed. the client can be used to schedule the capture task, but the system needs to reboot to begin pulling the image.
FOG is not typically used to capture systems that have been in use by users, but rather used to deploy a standardized image to systems.