6 Replies Latest reply on Sep 30, 2008 1:51 AM by ahe

    Strange PXE-E53 Error...

    ahe Expert

      Hello,

       

      we've had a problem with our PXE boot. (LD 8.7 SP5)

       

      After switching our network hardware our PXE boot didn't work for newer client hardware. The new hardware (for example Dell OptiPlex 320, 330; Latitude D630/631, E6xxx, with Broadcom UNDI PXE-2.1 v2.1.0) got the message:

      CLIENT MAC ADDR: xx xx xx xx xx xx  GUID: xxxxxxxx xxxx xxxx xxxx xxxxxxxxxxxx

      PXE-E53: No boot filename received

      PXE-M0F: Exiting Broadcom PXE ROM.

       

      All hardware with an other PXE ROM (for example Dell OptiPlex GX520, Latitude D600, Broadcom UNDI PXE-2.1 v8.1.8) can boot... 

       

      We checked all settings on PXE server, but nothing is changed. We checked the eventlog on the PXE and found a issue with the inventory scan.

      So we checked the core... no error scans after network change... mmh that's not possible :-)

       

      So check if the inventory service is running and ... No, the inventory service is stopped (why? We've rebooted the core after network change...)

       

      Restart of the inventory service and now we can boot our newer hardware with PXE too, no error messages. . . (Why?)

       

      I tested it again, stop the service manually and try network boot with two different clients (GX 520, 320). The older one got the PXE menu the newer got the error message.

       

      My questions:

      • Why do we need the inventory service on core be started for some hardware to start PXE boot?
      • Why doesn't it happen for all hardware types?
      • Does the PXE server communicate in a very early phase of PXE boot with the core and why?
      • Why do we haven't this problem with the older DOS based method?

       

      Regards

      Axel

        • 1. Re: Strange PXE-E53 Error...
          phoffmann SupportEmployee

          Pretty straight forward stuff...

           

               

          • Why do we need the inventory service on core be started for some hardware to start PXE boot?

           

          Answer -- because the Core must process the mini-scan from the client, so as to either add the device to the database, or update the network information on an existing record and "be aware" that someone's knocking at the door, so to speak.

           

          Can't schedule something to a device that doesn't exist in the database :).

           

               

          • Why doesn't it happen for all hardware types?

           

          Answer - Well - it'll be a hardware specific problem.

           

          This is usually caused by some weird PXE-code problem on the NIC. If the NIC in question is a LOM (LAN On Motherboard) be aware that BIOS-updates include firmware updates for LOM's. So upgrading the BIOS may have changed the LOM-firmware, and thus "upgraded it to broken".

           

               

          • Does the PXE server communicate in a very early phase of PXE boot with the core and why?

           

          Answer - Yes, it does. This is primarily used for "PXE Pre-targeting", where you essentially schedule an OSD job against a series of devices, let the job fail ('cos the devices aren't on the network), and the devices will then automatically run the OSD job as they connect to PXE.

           

          In essence, the check is "Hey Core - there's this guy (insert MAC-address here) who wants something - did he miss a job?" -- to which a Core responds either with "No - proceed as normal" or with a "Yes - here's the instructions to run..." and in the latter case it'd automatically go into an OSD managed boot.

           

               

          • Why do we haven't this problem with the older DOS based method?

           

          Answer - Shouldn't really make a difference, since the PXE-code grips earlier than that - after that, it's all down to the driver ... so maybe the driver doesn't like something that's been changed on the firmware?

           

          Paul Hoffmann

          LANDesk EMEA Technical Lead

          1 of 1 people found this helpful
          • 2. Re: Strange PXE-E53 Error...
            ahe Expert

            Thanks Paul for the hints,

             

            the PXE boot menu is configured and hosted on the PXE server and in the past without any need for LANDesk core. (In the past we install the original intel PXE MSI and cofigured it manually...    , because some sites do not have a connection to core... ).

             

            If I start "WinPE Menu", "Managed WinPE" or other LANDesk entries, I would understand that we've contact to the core to get the LANDesk Boot Menu, a LANDesk MiniScan, etc. But we've some entries more in our PXE BOOT (BartPE, our PXE LINUX installation, etc.), and every clients tries to connect to the core?

             

            I thought, the mini scan is started after/during Windows PE boot (STARTNET.CMD)...

             

            We've had the problem with absolute new hardware (2 weeks old) with actual BIOS and older hardware with older BIOS! The community is the PXE ROM version...

             

             

            ******************************

            • Why do we haven't this problem with the older DOS based method?

             

            Answer - Shouldn't really make a difference, since the PXE-code grips earlier than that - after that, it's all down to the driver ... so maybe the driver doesn't like something that's been changed on the firmware?

             

            ******************************

            Ok, I meant we haven't this "connect-feature" before migration to the new PXE-Server-WindowsPE-installation-method... , we didn't use the mini scan solution to get the computer name or something else in the past.

             

            We used our own, linux based installation method. It is/was much more faster as DOS, we can use UNC pathes and only one script for all sites (>60) We've one PXE boot entry, hosted by the PXE servers and we didn't need the LANDesk OSD script!. But it was not to easy to implement all features, like the mini scan..., now it's easier with the same performance and much more features...

             

            So I'm sometimes a bit surprised about this "new errors", I didn't thougth about the interaction...   

             

            Best regards

            Axel

            • 3. Re: Strange PXE-E53 Error...
              phoffmann SupportEmployee

              So there's a few factors to this.

               

              The ACTUAL mini-scan is started after you selecting your PE-boot of choice, yes - and the primary purpose of that is to make sure that CUSTJOB will be able to address the correct client. This is also necessary for "when you don't boot PXE" (i.e. via a boot floppy) to make sure that we have the correct network informastion.

               

              The part about the PXE-rep talking to the Core and saying "Hey, I've got this MAC-address - what do you want me to do with it..." doesn't require a scan. That's just the PXE rep "intercepting" the PXE-DHCP requestion and then talking to the Core what to do about it (since the PXE-rep knows the MAC-address in question).

               

              I'm not quite sure what you mean with:

              ""

              The community is the PXE ROM version...

              ""

               

              And yeah - PXE is surprisingly sensitive stuff, unfortunately :). It'll only be as reliable/good as the PXE-code written for it/the firmware, pretty much.

               

              Paul Hoffmann

              LANDesk EMEA Technical Lead

              • 4. Re: Strange PXE-E53 Error...
                ahe Expert

                ""

                The community is the PXE ROM version...

                ""

                 

                I meant, the same PXE boot ROM. All clients with version "Broadcom UNDI PXE-2.1 v2.1.0" failed, all other starts the PXE-Boot-Menu...

                 

                It's curious that the newest clients have the "problems" and the older not...

                 

                Regards

                Axel

                • 5. Re: Strange PXE-E53 Error...
                  phoffmann SupportEmployee

                  Not really strange at all. I learned this lesson quite well while working at Intel.

                   

                  All it takes is a tiny detail - a slightly different revision of the same silicon, heck even potentially a specific fab manufacturing it (i.e. "chips from location A == problem // chips from location B & C == fine").

                   

                  And different models of laptops are guaranteed to use different silicon - the firmware may be the same, but the hardware may be different - and the issue may be in the cooperation between hardware + silicon.

                   

                  It's one of those "wonderful" things that on the one hand keeps us in our jobs, on the other hand tends to pull our hair out...

                   

                  Paul Hoffmann

                  LANDesk EMEA Technical Lead

                  • 6. Re: Strange PXE-E53 Error...
                    ahe Expert

                    Thank you Paul.

                     

                     

                    >It's one of those "wonderful" things that on the one hand keeps us in our jobs, on the other hand tends to pull our hair out..

                     

                    ... but otherwise we will be bored... 

                     

                    Regards

                    Axel