Topics created by Wayne Workman

SVN 3320 Released has this in a real simple form.

This is already up and running. File didn’t work the same on all distros but I found a similar method that appears to work the same.

Good luck!

BTW I’ve found FOG to be quite stable at rolling the kernel (bzImage and its ilk) backwards and forwards.

Now if I could bend Tom’s ear to add a feature to roll iPXE backwards and forwards too. 😉

[QUOTE]This isn’t highly documented as it’s relatively new. In an attempt to allow legacy and new client’s to operate with a single version of FOG, I created a Field for the New Client (FOG_AD_DEFAULT_PASSWORD) and the legacy client (FOG_AD_DEFAULT_PASSWORD_LEGACY).[/QUOTE]

Perfect explanation - I ran into this issue today, wasn’t aware of the new legacy field. All is working fine now.

So, good news on this…

We were eventually able to image the system (probably luck), but we wanted to change something on the image and upload a new one.

So, we made our changes and tried to upload again… it just wouldn’t work. Kept saying failure 0 or something… I think it’s HDD related. We messed with this for quite a bit, and I decided to update FOG because Tom said he changed how hardware was detected in the latest svn.

We’re running r3277 now and it started uploading on the 1st try.

No more need.

I’ve removed the flags that seem to error and even removed the cause of the error in the first place. This should no longer be an issue.

[quote=“Wayne Workman, post: 46660, member: 28155”]Does FOG use FTP to delete images?[/quote]

yes

r3254 fixed it.

Thank you for being awesome, Tom.

r3232 fixed this.

Thank you, Tom.

@george1421 said:

There were a couple references to this “with a partition scheme suitable for EFI”. Which makes me wonder if there has to be something done special with the init fs to make it efi suitable??

Interesting. Haven’t thought about this before. Well we do have FOG (FOS) running on several different UEFI machines. So I am certain that it works with those inits Tom is building. AFAIK there is no partition scheme involved. initrd is just a compressed image file - no MBR, no partitions, no GPT …

The issue is resolved. The above post fixed it.

I doubt that OS update is changing file permissions in /tftpboot or /var/www but hey, you never know… 😄

I can update my script with rsync :

It’s debian based The laptop can only used to deploy (any update “laptop” to “FoG Main Server”) Each site have there own DHCP

I’ll post it here asap.

Regards,
Ch3i.

As this would cause extra load on the system I wonder if it’d be wiser to try and gather bandwidth data from the transfers that occour while uploads and downloads happen anyway…

I’ve been thinking A LOT about the many many problems with all the Vendor Class identifiers that Apple has…

Because PC is so standard (like PXEClient:Arch:00000 and PXEClient:Arch:00007 ), and because Apple are extreme non-conformists,

It makes no sense to try to define a class for each apple device. it’s stupid.

I say - make ipxe.efi the default and then make classes for the various PC PXEClient architectures.

Abandon Macs that are 32 bit. Just don’t worry about them.

[quote=“Jbob, post: 44069, member: 21733”]Bill,
That option is pretty simple to build, but it would be something Tom would build if we add it, as I’m pretty busy with prepping the new client for a public beta.

Wayne, the way FOG handles renaming is that it first unjoins the domain, renames the computer, and then joins. It should prevent the AD issue you describe.[/quote]

Amazing.

FOG is definitely a winner.

Bumping this, just so everyone now knows it’s a source forge project. 🙂

yes merge the information. then do a page insertion on the old page. This way both pages will have updated info

Edit:

See this page for what I mean…[url]http://fogproject.org/wiki/index.php?title=Multicast[/url]

[quote=“Wayne Workman, post: 43555, member: 28155”]I can’t do that, I’d surely loose my job.[/quote]

I face this problem as well, I set up a computer at home for FOG and let it mine away though.