I’d say that SysPrep is your answer.
I found this in the wiki, which might be helpful: [url]http://www.fogproject.org/wiki/index.php/Create_a_windows_7_image_for_many_different_hardware[/url]
Also, this might be helpful too: [url]http://www.itninja.com/blog/view/creating-a-windows-7-sysprep-image-without-having-to-install-any-drivers-at-post-install-tasks[/url]
[quote=“jamesb, post: 42582, member: 27742”]Before my network guy wants to open up the switches with this setting he wants to try a different mcast address. I’ve tried to get the 239 address to be used but FOG always uses the 236 address. I’ve overwritten in the FOG multicast settings in the web GUI but it’s not showing the change in the log files.[/quote]
SVN 2920 & up supports custom multicast address and port settings, along with a few other settings too I think.
That change was made to get FOG working at my location, and it works fine here. We don’t use the default [U]broadcast address[/U] for our broadcast domains, there’s custom setup intended to somewhat contain any multicast stream to prevent network-slowdown.
I’m not sure how the setup on the router & switches was accomplished here (not my job), I just know that it works.
239 & 236 addresses? I don’t follow.
By default, according to the IP info you gave earlier, the broadcast address for the segment that the FOG server is on should be: 172.28.2.255
Have you gotten multicast to work on the FOG server’s V-lan yet? What are the errors associated with [U]that[/U]?
Tom recently posted that he’s rolled back the SVN to 2996.
[url]http://fogproject.org/forum/threads/latest-development-fog.10556/page-22[/url]
Tom recently posted that he’s rolled back the SVN to 2996.
[url]http://fogproject.org/forum/threads/latest-development-fog.10556/page-22[/url]
[quote=“Tom Elliott, post: 42553, member: 7271”]While I know I was making progress, just too much has been breaking. I’ll be rethinking things down the road, but for right now i have reverted all changes back to 2996. It’s just not worth things not working any more simply for some performance gains. I can think about how to apply these things down the road.[/quote]
Spoken like a true developer.
[quote=“jamesb, post: 42509, member: 27742”]So I’m basically going to need to set up a storage node for each vlan we have in order for multicast to work in all of our buildings?[/quote]
I stand somewhat corrected.
I found this: [url]http://networkengineering.stackexchange.com/questions/10065/how-broadcasting-works-on-different-networks[/url]
Which basically says that limited broadcasts are always dropped, but a router can be configured to allow directed broadcasts by running [B][SIZE=14px][FONT=Droid Sans Mono][COLOR=#222222]ip directed-broadcast[/COLOR][/FONT][/SIZE][/B] (I assume on a Cisco router).
Have you done this, jamesb ?
[quote=“AlvinLorus, post: 42513, member: 28646”]Yeah, DeployStudio is the other option I’m looking into. Certainly looks capable. I would just prefer to use Fog since I’m in a mixed Windows and Mac environment and it’d be simpler to manage images for both in the same system if possible. But it sounds like it’s probably not simple to get Fog to image Macs.[/quote]
I’ve used DeployStudio a lot, back when I was stationed at an exclusively Mac school.
It’s an amazing product, really is, and I’ve seen it work amazing. BUT, in that particular school at that particular time, the network performance wasn’t really acceptable and DeployStudio performed poorly as a result (not it’s fault though).
Also, the storage nodes don’t need to be anything fancy (I’ve said this before?)
An old dual-core with a gigabit interface will get the job done in an acceptable amount of time.
Here, in my environment, FOG is virtualized on one of our servers, and can blast an image out to 1 client in 8 minutes (almost 50GB image, uncompressed). We can image 29 systems with that particular image in 29 minutes using multicast (I blame a bad patch cable somewhere).
[quote=“jamesb, post: 42509, member: 27742”]So I’m basically going to need to set up a storage node for each vlan we have in order for multicast to work in all of our buildings?[/quote]
Yeah, basically.
It might sound scary, but it’s not tough to do, and is documented.
If you have vlans that are assigned the same gateway (the router interface), then you only need one storage node for those Vlans.
Basically, you would need one node in each broadcast domain. That’s if you want it all centralized, with one almighty controlling FOG server for them all.
Before going to that extent though, I’d try getting multicast to work within the broadcast domain that the FOG server is in. You have to do that first to confirm you’re network equipment is configured properly, and that FOG is configured properly.
FOG server has 172.28.2.21/24
Client has 172.52.8.54/24
The problem is that they are within different broadcast domains.
Broadcast traffic does not traverse broadcast domains (routers don’t pass broadcast packets).
The network portion of the FOG server/node’s IP address must match the network portion of the Client’s IP address. So, that particular FOG server can only image clients with an address beginning in 172.28.2
Try it on a client that is within the same broadcast domain.
Later, once you can get that going, you can work towards setting up FOG storage nodes with the Location snapin.
What Linux distro?
What version/revision of FOG?
And, I’m assuming you’re wanting to use ProxyDHCP ?
Can you explain your network environment’s setup?
Switch model?
Where is the router (topographically)?
Are you using Vlans?
What’s the FOG server’s network interface configuration(s)? (include subnet mask, gateway, DNS, IP address)
Where’s the client you’re testing with?
Are you using DHCP?
Can you tell us what IP address the client is getting/assigned?
Just covering the bases at this point.
DeployStudio ?
[url]http://www.deploystudio.com/Home.html[/url]
I don’t think FOG would be able to bind OSX to Open Directory (correct me if I’m wrong), but DeployStudio can.
Have you tried a standard [I][SIZE=12px]dnsmasq.conf [/SIZE][/I]configuration ?
Maybe there is a typo in there? You were saying you customized it to allow use of the older method.
This is what mine looks like:
[CODE]port=0
log-dhcp
tftp-root=/tftpboot
dhcp-boot=undionly.kpxe
dhcp-option=17,/images
dhcp-option=vendor:PXEClient,6,2b
dhcp-no-override
pxe-prompt=“Press F8 for boot menu”, 3
pxe-service=X86PC, “Boot from network” undionly
pxe-service=X86PC, “Boot from local hard disk”, 0
dhcp-range=x.x.x.x,proxy[/CODE]
and that’s actually located here:/etc/dnsmasq.d/ltsp.conf
You said it works in the dnsmasq.conf file though.
[quote=“PaganLinuxGeek, post: 42489, member: 2226”]The machine running FOG has 3 nics and is hosting FOG in the HOST OS it is not in a vm.
I have VirtualBox 4.3 installed and am using it to test fog operation.
Thinking that the issue might actually be with vbox, I connected my pavillion g7 laptop via ethernet and attempted network boot.
The laptop was able to network boot using the older (pxe) method, but encountered the same error as vbox when attempting to boot using the newer (ipxe) method. I am able to do this because my dnsmasq.conf has entries that create a menu with default being ipxe boot (new method) Do you recall what particular bios settings the devel mentioned?[/quote]
Copied this stuff from some IM history.
[FONT=arial][COLOR=#222222]kkpxe is safer for buggy bios’s and should work on all working models too[/COLOR][/FONT]
[FONT=arial][COLOR=#222222]so the dhcp-boot=undionly.kpxe[/COLOR][/FONT]
[FONT=arial][COLOR=#222222]and
pxe-service=X86PC, “Boot form network”, undionly[/COLOR][/FONT]
[FONT=arial][COLOR=#222222] [/COLOR][/FONT]
[FONT=arial][COLOR=#222222]you’ll likely need a copy of whatever file to undionly.0[/COLOR][/FONT]
[FONT=arial][COLOR=#222222]so[/COLOR][/FONT]
[FONT=arial][COLOR=#222222]cp undionly.kkpxe undionly.0
the undionly file comes from /tftpboot[/COLOR][/FONT]
[quote=“PaganLinuxGeek, post: 42484, member: 2226”]I HAVE disabled selinux in /etc/selinux/config no change
all the passwords are the default. I’ve made no changes
Yes, all disabled services are not running, all required services are running.
TO repeat: I CAN retrieve the files using tftp on the commandline so I know tftp is working. I can netboot using the older pxe boot menus so I know that dhcp is configured correctly. This is on my home lan right now until I get the bugs worked out then I will install at work. The vbox machine and my laptop will find the dhcp server and start network boot until it gets to the /default.ixpe… stage then it’s timeout errors.[/quote]
Just trying to cover the simple stuff. I overlook little things sometimes.
You said you were running the v-machine on your laptop using 3 adapters? One is an add-on? an HP Pavilion laptop.
Is the system you’re trying to network boot with virtualized, or is it that HP Pavilion itself? Have you tried disabling the add-on interface?
Have you looked in the CMOS settings for the HP Pavilion (if that’s what you’re attempting to netboot), there are various settings on some systems for how a system attempts to net-boot. In a conversation with Tom (the senior developer), he was talking about how the current revision uses newer methods, so your CMOS settings might work with older iPXE but not the newer PXE methods… just a stab in the dark.
Because you can’t find any errors anywhere and all the services are properly configured, I’m reaching all over the place for ideas.
It’s probably something simple.
[quote=“PaganLinuxGeek, post: 42480, member: 2226”]I’ve read this through already actually, thank you. I would suggest adding this little bit to your howto however.
Make sure you are storing dnsmasq configuration into /etc/dnsmasq.conf and NOT /etc/dnsmasq.d/ltsp.conf location.
In desperation a few days ago I moved /etc/dnsmasq.d/ltsp.conf to /etc/dnsmasq.conf and found some success. Seems that contrary to documenatation it does NOT parse the ltsp.conf file…
for others reading this:
selinux has been set to “permissive” and also tried with “disabled” same results
systemctl disable firewalld.service has been executed
I’ve tried this using the xinetd tftp-server and using dnsmasq’s built in tftpserver
It shouldn’t matter but I DO have 3 nics in this machine (2 built into mobo, and 1 add-on)… all are enabled and functional on same subnet but with using seperate IP’s, none are in bridged mode, or “teaming”.[/quote]
Glad you liked the howto. I am not sure why the /etc/dnsmasq.d/ltsp.conf didn’t work for you, as that’s what I did on my setup. You are using a newer revision than me so, maybe [URL=‘http://fogproject.org/forum/members/tom-elliott.7271/’][SIZE=11px][U][COLOR=#969696]Tom Elliott[/COLOR][/U][/SIZE][/URL] changed something… not sure. If he confirms, I’ll put notes in the How-To for the newer revision’s config on that part.
By reading through your problem, I was thinking it was a simple password issue, perhaps for the TFTP settings. Maybe the storage management password settings.
I’d recommend disabling SELinux - just to eliminate it from the equation - at least till things are working. Reboot after the change for it to take effect.
Did you run all the systemctl status commands to see if they were all ok?
Also, lately, I’ve read a lot of stuff about how people need to set up “Bridged connections” for the OS that hosts the virtualized FOG box.
[quote=“PaganLinuxGeek, post: 42472, member: 2226”]I too am having this issue on fedora 21 system. I can transfer the file via tftp from command line without error. However, when attempting to network boot ipxe as per the new method it reports a /default.ipxe… timeout error. This happen in virtualbox vm (network adapter is set to bridged and intel chipset emulation) and with my HP Pavilion laptop. I can boot the old method (pxe) as per fog 0.32. I’ve edited my /etc/dnsmasq.conf file to provide two network boot options in the boot menu (press f8 for boot menu) with the default being ipxe boot. Since I can netboot using the older method and transfer files via tftp I tend to think the setup for DHCP and tftp is functioning normally.
I’ve checked the messages log file for errors and it’s not reporting any. The httpd access log doesn’t show any requests for the files it’s supposed to transfer via http either. It leads me to believe that it’s not progressing past the tftp transfer stage and into the http transfer stage.[/quote]
I’m using Fedora 21 also. I wrote up some instructions for installing in Hyper-V (might very closely apply to VMware). These apply to revision 2922 and up.
The instructions are here:
At the bottom, you’ll find troubleshooting help (just a starting place, really).
I think you might find it to be a lot of help.