PXE Boot Server without DHCP, for many different computers

Yep. I've managed many a PXE server. I'd recommend NeoPXE. There's tons of documentation on it and it's very powerful. You can do things like create a menu that will chainload to other PXE servers and install targets.

You should also know that a PXE server is simply a DHCP server paired with a TFTP server. To do more advanced things like what I explain below, you'll be setting up a proxy DHCP server.

For example, we have it set up so that when you first PXE boot you have a list of options to go to several different departments' PXE servers or go to Linux, Solaris, or BSD. From there you can go to Stable/Devel then pick your architecture and version. Finally you'd be given an option to do a kickstart/autoyast/jumpstart or an attended install.

The menus can be created programmatically and/or by hand. You edit configuration files then run make. I think this answers 1, 2, and 4. For number 3, if I understand you correctly... you can't simply serve an ISO to a client from a PXE server. For Linux distros, generally, you'll have to pull out the initrd and vmlinuz and then make the rest of the packages accessible via NFS, FTP, HTTP, or smb.

I think this is exactly what you're looking for.

http://download.oracle.com/docs/cd/E19273-01/835-0781/sfx46losig.gisnq.html

Let me know if you want more specific instructions for a given distro or if you need help setting up NeoPXE.

TheUser1024 has the problem right, but I'd suggest a different solution.

Firstly, to confirm, having two DHCP servers on the same Layer 2 segment can be problematic. The easiest way around this, for a SOHO setup, is simply to avoid the situation altogether.

Here's how I'd do it. Much of this just re-caps configuration you've already done, so I'm highlighting the key differences for you in bold.

SuperHub:

• Connect WAN (Internet) port to wherever your Internet is coming from, and configure this interface as appropriate for that connection.
• Set LAN IP to 192.168.0.1/24.
• Configure DHCP to serve addresses from 192.168.0.20-50.
• Leave DNS server configuration alone (since it can't be changed).
• Set SSID to "wifi-super". You should also set up WPA2 security, with a strong passphrase.

WGR:

• Connect WAN (Internet) port to a LAN port on the SuperHub.
• Set WAN (Internet) port IP to 192.168.0.2/24.
• Set LAN IP to 192.168.1.1/24
• Configure DHCP to serve addresses from 192.168.1.100-150.
• Set DNS servers to Google's DNS.
• Set SSID to "wifi-other". You should also set up WPA2 security, with a strong passphrase.

Under the above configuration, here's what will happen when you connect the first device to each Wi-Fi network:

"wifi-super"

• IP: 192.168.0.20
• Subnet Mask: 255.255.255.0
• Default Gateway: 192.168.0.1
• DNS: (Virgin Media DNS)

"wifi-other"

• IP: 192.168.1.100
• Subnet Mask: 255.255.255.0
• Default Gateway: 192.168.1.1
• DNS: (Google DNS)

What's happening in this configuration is that, instead of treating the second router as a switch/AP you're actually using it as a router - the way it was originally designed to be used. Essentially, the part of the network that's behind the WGR is treating the SuperHub as you would a standalone cable modem. This will allow you to easily serve up two separate Wi-Fi networks, on two separate subnets, with the common SOHO networking equipment already on-hand.

The trick to getting the systems behind "wifi-other" to automatically pick up Google's DNS servers for their configuration, is to set the WGR's WAN port to static configuration. Don't let it just grab an IP from the SuperHub, or it will also want to inherit the DNS settings and pass those along to its clients similar to how the SuperHub does.

If it is not critical that you have two separate subnets, you can still serve up two separate Wi-Fi SSIDs (though the clients won't be quite so isolated from one another) on the same subnet (192.158.0.0/24). Simply start with the setup you already have, disable the DHCP server on the WGR, and set its LAN IP in the same range as the SuperHub. That's essentially the setup I have at home (different hardware, of course) and it works just fine - though computers configured for both networks occasionally choose the more distant one.