• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    Finding messages or log from a failed pxe boot

    Scheduled Pinned Locked Moved
    FOG Problems
    2
    14
    2.8k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      KDM
      last edited by

      Hi all, I’m very new to FOG and PXE. I set up a FOG server (Ubuntu) and I have added the options 66 (ip of the FOG server) and 67 (ipxe.efi) to my Windows DCHP server.

      I’m trying to boot a laptop (HP Elitebook 840) over PXE in order to make an image of it.
      When booting from XPE it says “Start PXE over IP4” but continues to boot to windows after a couple of seconds. If tried messing around with option 67, but no succes so far.

      There are some messages showing between “Start pxe over ip4” and the windows boot animation. The problem is that these messages dissappear so quickly I can’t see what they say"

      Is there way to see these message somewhere (log)?

      Thanks in advance

      george1421G 1 Reply Last reply Reply Quote 0
      • george1421G
        george1421 Moderator @KDM
        last edited by

        @kdm Is the FOG server on the same IP subnet as the pxe booting computer? If yes then we can grab a packet capture of the pxe booting process. If no then we can use wireshark installed on a witness (extra computer) on the same subnet to capture what the target computer is being told.

        Also make sure if you have more than one dhcp server on your network, that both of them are configured for pxe booting.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

        K 2 Replies Last reply Reply Quote 0
        • K
          KDM
          last edited by

          This post is deleted!
          1 Reply Last reply Reply Quote 0
          • K
            KDM @george1421
            last edited by

            @george1421

            Yes, the computer (10.58.1.207) is on the same IP subnet as the fogserver (10.58.5.88)

            I did do a pcap, but I’m a bit puzzled about this message:

            Dynamic Host Configuration Protocol (Request)
                Message type: Boot Request (1)
                Hardware type: Ethernet (0x01)
                Hardware address length: 6
                Hops: 0
                Transaction ID: 0xd37bd5de
                Seconds elapsed: 3
                    [Expert Info (Note/Protocol): Seconds elapsed appears to be encoded as little-endian]
                        [Seconds elapsed appears to be encoded as little-endian]
                        [Severity level: Note]
                        [Group: Protocol]
                Bootp flags: 0x0000 (Unicast)
                    0... .... .... .... = Broadcast flag: Unicast
                    .000 0000 0000 0000 = Reserved flags: 0x0000
                Client IP address: 10.58.1.207
                Your (client) IP address: 0.0.0.0
                Next server IP address: 0.0.0.0
                Relay agent IP address: 0.0.0.0
                Client MAC address: a8:b1:3b:53:28:8e (a8:b1:3b:53:28:8e)
                Client hardware address padding: 00000000000000000000
                **Server host name not given
                Boot file name not given**
            
            

            “Server host name not given” and “Boot file not given”

            They are clearly set on the DCHP server.

            george1421G 1 Reply Last reply Reply Quote 0
            • george1421G
              george1421 Moderator @KDM
              last edited by george1421

              @kdm Yes something looks amiss. I have a bit more detailed instructions on capturing a pcap here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

              If you want to review it, look at the dhcp OFFER packet it needs to have in the ethernet header both the next-server and boot-file set as well as dhcp options 66 and 67. On your dhcp server make sure it sends both bootp and dhcp information.

              If you are unsure what you are looking at post the pcap to a internet file share then either post the link here or IM me the link via FOG chat and I will take a look at the results.

              Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

              1 Reply Last reply Reply Quote 0
              • K
                KDM @george1421
                last edited by KDM

                @george1421
                it looks like my DHCP server does the OFFER with all required parameters:

                2b6d708e-2c47-4093-9530-60b0274be92e-image.png

                george1421G 1 Reply Last reply Reply Quote 0
                • george1421G
                  george1421 Moderator @KDM
                  last edited by george1421

                  @kdm ok two things jump out here.

                  1. PXE booting actually involves 2 protocols bootp (fields in ethernet header [not show in the picture below] and dhcp (dhcp options 66 and 67 [as shown below]). Its up to the pxe booting computer mfg to decide which to look at.

                  2. I see you have a ProxyDHCP request there too. That proxydhcp overrides the settings set by dhcp options 66 and 67. What is device 10.58.1.207 (or 10.58.5.88 I can’t remember which column is the server). That is the device that is responding to the proxy response.

                  It would be much easier to have the pcap file instead of screen shots to narrow in on the issue. But your dhcp process looks normal typical DORA response (discover, offer, request, ack). The proxy response is not normal but is used in certain circumstances. A Windows WDS server may give this type of response. Look at the OFFER packet make sure that dhcp option 60 is not being set for some reason. This says the response is a proxydhcp response.

                  Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                  1 Reply Last reply Reply Quote 0
                  • K
                    KDM
                    last edited by

                    In my search to figure out why my clients are not booting PXE I tried booting a virtual Win10 client.

                    On booting I got the warning “pxe-e55 proxydhcp service did not reply to request on port 4011”

                    970362fa-8cec-4aaa-a536-661d8b102e19-image.png

                    Googling this, everywhere I read the suggestion to remove option 60 on my DHCP server. But option 60 is not set on my one and only DHCP server (Windows Server 2008R2). It’s not in the DHCP scope and not in the Server options.

                    I’m sorry but I don’t feel comfortable uploading the Wireshark captures as for now.

                    george1421G 1 Reply Last reply Reply Quote 0
                    • george1421G
                      george1421 Moderator @KDM
                      last edited by george1421

                      @kdm said in Finding messages or log from a failed pxe boot:

                      I’m sorry but I don’t feel comfortable uploading the Wireshark captures as for now.

                      Uploading would be the quickest way to an answer but I think we have enough info to point you in the right direction. Actually you provided what is needed. Look at your posted picture of the pcap, for the OFFER packet.

                      Look in the details section. Do you see option 60 being set? That is the problem. Its coming from dhcp server 10.58.0.4. That option being set specifically with “PXEClient” value tells the client to reach out to the server on port 4011 (proxydhcp) to find out where to boot from. DHCP options 66 and 67 will be ignored by the target computer.

                      If your dhcp server is not configured to do that, then I was ask is a wds service installed on this dhcp server? Something is putting that value in the response packet.

                      FWIW This is not a fog issue, but network infrastructure.

                      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                      K 2 Replies Last reply Reply Quote 0
                      • K
                        KDM @george1421
                        last edited by KDM

                        @george1421

                        Thanks again, I did do a PCAP and I’m getting Option (60) Vendor class identier

                        7b12078c-4288-4596-b49b-7f6f06bf7389-image.png

                        This is not set by our DHCP, but we had WDS running in the past. The service is disabled, but I guess it is still answering…

                        To clearify: WDS was NOT installed on the DHCP server, but a separate server. That server is still running, but WDS is disabled.

                        1 Reply Last reply Reply Quote 0
                        • K
                          KDM @george1421
                          last edited by

                          @george1421

                          I have uninstalled the WDS service from the other server, double and triple checked and rebooted the DHCP server.

                          And option 60 is still being offered…

                          I’m lost…

                          george1421G 1 Reply Last reply Reply Quote 0
                          • george1421G
                            george1421 Moderator @KDM
                            last edited by

                            @kdm Well I don’t have a good answer for you. The short answer is that option needs to go to be able to pxe boot.

                            Maybe you can reverse engineer these instructions that shows how to add it" https://www.azure365pro.com/add-option-60-in-dhcp-server-for-sccm/

                            I little bit harder answer is to upgrade that windows 2008 server to something that is currently supported by Microsoft leaving this bad setting behind.

                            Thinking out of the box installing dnsmasq configured as proxy dhcp server could fool the client into pxe booting too. Not ideal in the least but something that might work if all other things fail.

                            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                            K 2 Replies Last reply Reply Quote 0
                            • K
                              KDM @george1421
                              last edited by

                              @george1421 said in Finding messages or log from a failed pxe boot:

                              I little bit harder answer is to upgrade that windows 2008 server to something that is currently supported by Microsoft leaving this bad setting behind.

                              Yes, an upgrade of this DHCP server has been on the planning for a very long time but has always been delayed for al kinds of reasons. “it works and we have other priorities”

                              @george1421 said in Finding messages or log from a failed pxe boot:

                              Thinking out of the box installing dnsmasq configured as proxy dhcp server could fool the client into pxe booting too. Not ideal in the least but something that might work if all other things fail.

                              Yes I have been thinking about this, but that’s a serious hassle and will probably cause more issues than it solves…

                              I’ll leave it for now, upgrade the DHCP first and get back in touch if needed

                              1 Reply Last reply Reply Quote 0
                              • K
                                KDM @george1421
                                last edited by

                                @george1421
                                Well I’ll be damned

                                35f04c28-e6a6-4fff-80c2-fb2738c82298-image.png

                                1 Reply Last reply Reply Quote 0
                                • 1 / 1
                                • First post
                                  Last post

                                165

                                Online

                                12.0k

                                Users

                                17.3k

                                Topics

                                155.2k

                                Posts
                                Copyright © 2012-2024 FOG Project