Find the answer to your Linux question:
Results 1 to 6 of 6
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Network Boot (PXE) w/ Home Router


    So here's a situation that I'm hoping to work around.

    GOAL:
    * I would like to allow a PC(s) in my network to boot via PXE off my server.
    * This should not impede the existing DHCP configuration of my home router because if the server is away (i.e. at a LAN party), the rest of the network should continue to function.

    NETWORK CONFIG:
    * 1x D-Link Gamer Router DGL-4300 <-- a nice router
    * 1x server
    * 1x multimedia PC
    * 5x desktop PCs
    * 2x notebooks

    All of my media files reside on the server (file server), so there is no need for the media PC to have a hard drive (currently booting off USB key). I would like to have the media center boot via PXE to an installation hosted by the server.

    From everything I've read so far about PXE and network booting, one of the key steps is to DISABLE the router's DHCP. This is not desired, because as I mentioned in my "goal", I do not want the entire network to rely on the server for DHCP for two reasons:
    1. The server is not always in the network and can be on occasion away at a LAN
    2. The router is a good quality router, and I would prefer to keep DHCP/gateway/etc. on the same device.

    Is it possible to boot via PXE without disabling my router's DHCP server?

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,666
    Only if your router
    a) has a dhcp server with PXE extension
    b) offers a freely configurable dhcp server (ie: "filename" and "next-server" are needed in the dhcpd conf for PXE). This might not be possible via the router's webinterface and change via commandline possibly conflicts with the webinterface.
    c) also has a TFTP server. This is used to host the bootimages for the clients.

    I would be surprised if this router meets all these criteria, so in your case, you will proably need a second server.
    Do you have an old pentium 3 lying around?

    Or perhaps its easier to do the PXE on your server
    and simply turn your router's dhcp off and on every time you go to a LAN party.
    Last edited by Irithori; 11-28-2009 at 12:36 PM.

  3. #3

    Thumbs down

    Thanks for the reply. It's too bad, because I'm certain the router doesn't meet all 3 criteria.

    It's silly for me to have ANOTHER computer running just to be a DHCP / PXE boot server. (waste of energy).

    Well, I guess I'm sticking to good old fashioned hard drives then.

  4. $spacer_open
    $spacer_close
  5. #4
    Quote Originally Posted by Fermulator View Post
    Well, I guess I'm sticking to good old fashioned hard drives then.
    There is a way to PXE boot without a local configurable DHCP server but you need a bit of technical know-how and you still have to boot off a CD. The CD will (or should be, anyway) be generic enough to use with any PC/workstation/server. The CD image is small though - like 5MB - and boots very quickly.

    Here are the instructions I wrote up for someone else to do this:

    gPXE build process:

    1. Download gPXE source files (I can't post URLs but it's not hard to find).
    2. Untar gpxe source; e.g., tar xzf gpxe-0.9.7.tar.gz
    3. Go to gpxe source folder; cd gpxe/src
    4. Create a boot script for the gPXE kernel to use when booting off ISO; this is the key piece that tells the gPXE kernel where to find its initial boot file – which can be any text/PHP/web-generated file accessible either locally or via a URL - and precludes the need for a local “next server” (TFTP boot server) specification in a configurable DHCP server. In the source example attached this script file is called boot.script.

    --- boot.script contents –
    #!gpxe
    dhcp net0
    set 210:string (imagine a URL to a boot folder here)
    kernel (imagine a URL to a PHP file here)
    boot
    --- boot.script contents –

    The "kernel" line in this example points to a web hosted-PHP file that simply regurgitates some text that gPXE's scripting language understands. The kernel line could point to a remotely accessible (http, tftp, ftp etc) kernel and you could potentially add an "initrd" option to remotely load an initrd filesystem. The gPXE boot script reference is on the gPXE wiki (sorry can't post any URLs).

    5. Make the gPXE ISO kernel image:

    make bin/gpxe.iso bin/gpxe.lkrn EMBEDDED_IMAGE=boot.script

    Then you just burn the gpxe.iso file to CD and boot off of it.

    Short of this you should look at getting a wireless router that can support custom firmware (e.g., Linksys WRT54G). DD-WRT, Tomato, etc. can support customizable/configurable DHCP options for PXE booting. For $50 or less (look on Craigslist) you can get this custom firmware capability.

  6. #5

    Smile One (or maybe two) more options

    Quote Originally Posted by serverminds View Post
    There is a way to PXE boot without a local configurable DHCP server but you need a bit of technical know-how and you still have to boot off a CD. The CD will (or should be, anyway) be generic enough to use with any PC/workstation/server. The CD image is small though - like 5MB - and boots very quickly.

    Here are the instructions I wrote up for someone else to do this:

    gPXE build process:

    1. Download gPXE source files (I can't post URLs but it's not hard to find).
    2. Untar gpxe source; e.g., tar xzf gpxe-0.9.7.tar.gz
    3. Go to gpxe source folder; cd gpxe/src
    4. Create a boot script for the gPXE kernel to use when booting off ISO; this is the key piece that tells the gPXE kernel where to find its initial boot file – which can be any text/PHP/web-generated file accessible either locally or via a URL - and precludes the need for a local “next server” (TFTP boot server) specification in a configurable DHCP server. In the source example attached this script file is called boot.script.

    --- boot.script contents –
    #!gpxe
    dhcp net0
    set 210:string (imagine a URL to a boot folder here)
    kernel (imagine a URL to a PHP file here)
    boot
    --- boot.script contents –

    The "kernel" line in this example points to a web hosted-PHP file that simply regurgitates some text that gPXE's scripting language understands. The kernel line could point to a remotely accessible (http, tftp, ftp etc) kernel and you could potentially add an "initrd" option to remotely load an initrd filesystem. The gPXE boot script reference is on the gPXE wiki (sorry can't post any URLs).

    5. Make the gPXE ISO kernel image:

    make bin/gpxe.iso bin/gpxe.lkrn EMBEDDED_IMAGE=boot.script

    Then you just burn the gpxe.iso file to CD and boot off of it.

    Short of this you should look at getting a wireless router that can support custom firmware (e.g., Linksys WRT54G). DD-WRT, Tomato, etc. can support customizable/configurable DHCP options for PXE booting. For $50 or less (look on Craigslist) you can get this custom firmware capability.
    I realize this is an older thread, but since it's a high hit on google I thought I would paste my 2 cents here.

    There is a way to remove the CD requirement from this earlier response, in some situations. If you check the iPXE documentation, there are some select network cards that can subsiqnetly have such a custom boot image burned onto the nic's flash.

    This still leaves you with needing some server somewhere that will contain your bootable image. If you already have some other server on your network somewhere, it should be able to pride this image by either adding tftp or reviewing the iPXE documentation and using a different protocol (it can boot from regular ftp, http, even network file systems, so chaces are you can put your image somewhere iPXE can find it.

    There are also public bootable images you can load. While this decreases customizability and includes other obvious risks, it is a quick option that I've used in some niche cases. check out netboot.me for some options.

    also, one other less usable option (and one i'm looking into again now), is handing out unsupported dhcp options from a 2nd source. While I don't have the links on hand, I did read about it a while back. There were two methods IIRC, one was a simple custom daemon that would see DHCP handouts and try to inject additional options, since it is time and client compatibility limited, it's not the best idea but sounded feasable.

    The second one involved mangling network traffic to append options. This would involve either a dedicated computer/device between your router and lan, or somthing with ipchains/iptables that can interrupt/insert/interfeir with your existing network.

    That's my 2 cents. The earlier response with burning the flash are the best/simplst. The others really are only for people that want to test out concepts and don't just need it to work, it's likely to not-work, break, and other random insabilities.

    Cheers!
    D0c

  7. #6
    Given how old the thread is some of my advice has changed - some of it considerably - since then.
    Quote Originally Posted by caldwelljt View Post
    There is a way to remove the CD requirement from this earlier response, in some situations. If you check the iPXE documentation, there are some select network cards that can subsiqnetly have such a custom boot image burned onto the nic's flash.
    True but at scale this is very challenging. Imagine re-flashing potentially hundreds of NIC cards at great risk to the boot ROM and generally supportability of the card. In KVM and VMware ESXi it is much easier to do with the embedded virtualized NICs (e1000, realtek, vmxnet3, etc.). In those scenarios you can replace the .rom files straight across from compiled versions in iPXE (gPXE is long gone, now, as you know).

    This still leaves you with needing some server somewhere that will contain your bootable image. If you already have some other server on your network somewhere, it should be able to pride this image by either adding tftp or reviewing the iPXE documentation and using a different protocol (it can boot from regular ftp, http, even network file systems, so chaces are you can put your image somewhere iPXE can find it.
    Whether you host it yourself or boot something off the 'net (like netboot.me) http is vastly superior to tftp booting. Use http if you can.
    also, one other less usable option (and one i'm looking into again now), is handing out unsupported dhcp options from a 2nd source. While I don't have the links on hand, I did read about it a while back. There were two methods IIRC, one was a simple custom daemon that would see DHCP handouts and try to inject additional options, since it is time and client compatibility limited, it's not the best idea but sounded feasable.
    You're (more than likely) referring to Proxy DHCP and it's 100% feasible, supported, and PXE specification compliant.

    After years of seeing mysterious and vague references to proxyDHCP and "PXE servers" and likewise declaring it not feasible, I decided to really dig in to find out what it was all about. In that process I found dnsmasq, which works brilliantly as a proxyDHCP server.

    The great thing about proxyDHCP is it co-exists alongside any existing DHCP infrastructure. It does not have to replace or supplant that infrastructure and in fact is completely transparent to said infrastructure - i.e., DHCP clients that don't need proxy DHCP simply won't use it and proxy DHCP won't respond to them.

    In large networks you can use the proxyDHCP (dnsmasq) server as a DHCP relay in addition to your existing DHCP server and PXE clients will automagically pick up that server when attempting to PXE boot. It's pretty trick.

    If you're a Windows shop, WDS is analogous to proxyDHCP and the WDS transport server acts in effectively the same manner. Main difference is WDS only supports TFTP and also of course is geared to only support netbooting Windows.
    The second one involved mangling network traffic to append options. This would involve either a dedicated computer/device between your router and lan, or somthing with ipchains/iptables that can interrupt/insert/interfeir with your existing network.
    I have no idea what you're talking about here. Certainly this has nothing to do with proxyDHCP which does not "mangle" network traffic. It is designed merely to respond to PXE boot requests, which are part and parcel to the PXE specification.
    That's my 2 cents. The earlier response with burning the flash are the best/simplst.

    The others really are only for people that want to test out concepts and don't just need it to work, it's likely to not-work, break, and other random insabilities.
    (Bill Lumbergh voice) I'm going to have to, uhhh, kind of disagree with you here.

    Flashing boot ROMs does not scale - EXCEPT in KVM environments where it's dead simple to replace the virtual NIC boot ROMs - and probably invalidates your hardware warranty. A handful of boxes that are you own to play with - sure go ahead it's a great idea - but beyond that forget about mass flashing boot ROMs. It's fairly risky and unreliable. Maybe Google and Facebook do it on custom BIOSes (and I'd wager they have a completely custom network bootstrap anyway) but the average IT shop, even one with very sophisticated SAs, won't be doing this.

    I'll sort of agree with you on the stability thing because PXE has always been something of a hit-or-miss proposition in general. The specification is quite old now and has not been updated in at least 10 years but hardware vendors quietly plod along and support it. Early on (late '90s, early 2Ks) the proposition of using PXE was VERY hit or miss but nearly all vendors have a lot of understanding and maturity now when developing PXE support in their ROMs (RealTek, Marvell, Intel, Broadcom, etc. etc.) with Intel, as always, certainly being the best.

    That said, you can make DHCP+proxyDHCP+iPXE work quite stably. iPXE is simply an awesome piece of work, an elegant network boot Swiss Army Knife that we've only begun to exploit. I'd STRONGLY recommend it for a production implementation and time investment. Nearly everyone out there that wants netboot support built into their products are using iPXE. VMware is hanging on with gPXE but I suspect it won't be long before they finally dump it and go with iPXE for AutoDeploy. I've even seen a vendor switch-up WDS for iPXE because it's so, so much faster than TFTP, which is the only protocol WDS supports natively.

    This is a very old thread - my handle is from a business that I started but is no longer around - and my thinking has evolved considerably on this subject. I've written my own netboot tools around iPXE and it's superior to anything out there. I have some depth here so if anyone wants any advice I'm happy to offer it up.
    Last edited by serverminds; 03-18-2015 at 12:13 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •