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

    040ee119 error on boot

    Scheduled Pinned Locked Moved Solved
    Bug Reports
    26
    101
    83.5k
    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.
    • JunkhackerJ
      Junkhacker Developer
      last edited by

      what bios version to the Dell Optiplex 990’s have?

      signature:
      Junkhacker
      We are here to help you. If you are unresponsive to our questions, don't expect us to be responsive to yours.

      1 Reply Last reply Reply Quote 0
      • T
        Tribble
        last edited by

        [quote=“Tom Elliott, post: 29104, member: 7271”]In reference to the “twirling” you’re experiencing, do your switches have STP enabled on them? Do you have an option for portfast on these switches?

        Being connected to the 10/100 doesn’t really mean anything, it simply means it can receive the dhcp request from ipxe. If you take out all managed switches and connect directly to the FOG server, does all work as expected at 1gb?

        This will let you know if it’s a 10/100->1000 problem. I run gig switches on all my tests, and don’t experience the boot loop issue. (BTW for all, the boot loop is intentional kind of).

        Doing this won’t necessarily be easy, but I suppose, if you could for DHCP, connect your FOG Server, Client test system, and DHCP server to the same switch. Start off easy and use a “dummy” switch preferably rated for 1GB.

        This will, again, determine if it’s truly the undionly OR if something’s on your network not sending the DHCP back in time.[/quote]

        Hey Tom, I’ll see what i can do about running them all through a single unmanaged gigabit, but i doubt i’ll be able to do that without significant network disruption. Nearly everything runs through those 2 Dell powerconnects.

        What i can do at the moment, is try an un-managed gigabit capable switch in place of the 10/100 C-net.
        I’ll also have the Network admin check the managed switches for STP and portfast.

        Keep in mind however this issue never came up while using .32.33 to image well over 100 pc’s this spring for our Win-7 roll out. We’ve had no changes to our network infrastructure since then. Those 100+ PC’s were loading through with no issues up until i updated FOG to 1.0.1 .

        Appx 25 of the machines mentioned are in this office, i have not verified that all of the PC’s in this office are effected. I have not updated the DHCP PXE image name at our other 14 branch offices as of yet as that’s just way too many “OMG my computer won’t boot” phone calls every morning lol. Each office has it’s own subnet (10.X.0.x) and Local DHCP server.

        All in all, i’ve imaged and installed 80 DC7900’s, and 80+ DC5750’s since january using fog .32 before the update with no issues like i’m describing here. A PXE\STP issue would have reared it’s ugly head already.

        I’m certainly not complaining, Fog has already saved me hundreds of hours of work, lol, I just want to give you as much info as i can since i’ll be pretty busy today with DR testing.

        1 Reply Last reply Reply Quote 0
        • W
          Wolfbane8653 Developer
          last edited by

          Tribble check out this: [url]http://fogproject.org/forum/threads/nothing-is-working.10598/page-2#post-28305[/url]

          I’m sure that the Dell Powerconnects have Spanning Tree Protocol (STP) enabled by default. Please confirm that these have be disabled.

          Also there seems to be a portfast function as well. With portfast being disabled it would interfere with iPXE and not PXE

          1 Reply Last reply Reply Quote 0
          • Tom ElliottT
            Tom Elliott
            last edited by

            [quote=“Tribble, post: 29149, member: 17221”]Keep in mind however this issue never came up while using .32.33 to image well over 100 pc’s this spring for our Win-7 roll out. We’ve had no changes to our network infrastructure since then. Those 100+ PC’s were loading through with no issues up until i updated FOG to 1.0.1 .[/quote]

            The reason there is a difference is ipxe has to establish it’s own dhcp connection. The timing is less than that for regular PXE. Your systems are “getting” to the undionly.kpxe which means the PXE side of the house is working properly. To enable the new “protocol” usages, ipxe has to re-establish the link to the switches which was what was first causing the 040ee119 error. It happened because of a timing problem and CPU usage issue in the ipxe source which has since been fixed. Now if you see this error, it’s most likely a network relatable issue such as the STP or not having PortFast in the case of cisco switches.

            I hope this makes sense.

            [quote=“Tribble, post: 29149, member: 17221”]All in all, i’ve imaged and installed 80 DC7900’s, and 80+ DC5750’s since january using fog .32 before the update with no issues like i’m describing here. A PXE\STP issue would have reared it’s ugly head already.[/quote]

            The pxe/stp issue wouldn’t have reared it’s head because Old PXE didn’t care about that, and even still isn’t, which is WHY you’re able to see undionly.kpxe, but after that point is the failure. Just wanted to give clarification.

            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! Get in contact with me (chat bubble in the top right corner) if you want to join in.

            Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

            Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

            1 Reply Last reply Reply Quote 0
            • F
              fractal13 Developer
              last edited by

              [quote=“Buddy, post: 29092, member: 225”]Tom,

              I got rid of the “Operation not Supported” message on a Dell 390 today by using the “e0478-DEFAULT-TEST” ipxe.pxe . Though that version did not work on the Dell 990’s. I went through all of the most current files you have posted and here is what I have found.

              e0478-DEFAULT-TEST

              undionly.kkpxe - - reboot loop on dell 990 operation not supported
              ipxe.pxe - - - - operation not supported then freezes
              undionly.kpxe - - - operation not supported then freezes
              undionly.pxe - - - - assumming it errors but goes way to fast to read error then reboots
              ipxe.kpxe - - - operation not supported then freezes
              ipxe.kkpxe - - - operation not supported then freezes

              d6300-DEFAULT-GOOD

              ipxe.pxe - - - operation not supported then freezes
              undionly.kpxe - – operation not supported then freezes
              undionly.pxe - - - - assumming it errors but goes way to fast to read error then reboots
              ipxe.kpxe - - - operation not supported then freezes
              ipxe.kkpxe - - - operation not supported then freezes
              undionly.kkpxe - - - - operation not supported then reboots[/quote]

              For what it’s worth, our Dell 990s work on the out of the box PXE configuration.

              1 Reply Last reply Reply Quote 0
              • B
                Buddy
                last edited by

                Thanks fractal that is good info to know. So it is definatley something unique with my setup.

                I am running A18 on the bios and I will run through boot again and post that in a sec. No wireless or other nics in any of the machines.

                1 Reply Last reply Reply Quote 0
                • T
                  Tribble
                  last edited by

                  So, you’re saying that the issue would only appear when a PXE booting device using Undionly.kpxe is directly attached to a managed switch with STP enabled. And that adding an unmanaged, Non-STP switch as an intermediary between the PC and the managed switch can prevent the problem because iPXE communicates directly with the switch for DHCP? Therefore since the PC is not “directly” communicating with a switch that has STP enabled, there is less delay establishing a connection with the DHCP server.

                  Now, I will admit that i do notice a shorter time to pick up DHCP when i have the intermediary switch in place, but i never realized that switches had anything to do with DHCP packets and requests other than routing them to the correct ports.

                  I won’t be able to get on those switches until possibly friday due to our DR testing schedule, but i’ll be sure to let you know what happens. I know we haven’t done much if any customizing to those managed switches from their default state, so STP being enabled is certainly possible.

                  1 Reply Last reply Reply Quote 0
                  • Tom ElliottT
                    Tom Elliott
                    last edited by

                    [quote=“Tribble, post: 29175, member: 17221”]So, you’re saying that the issue would only appear when a PXE booting device using Undionly.kpxe is directly attached to a managed switch with STP enabled. And that adding an unmanaged, Non-STP switch as an intermediary between the PC and the managed switch can prevent the problem because iPXE communicates directly with the switch for DHCP? Therefore since the PC is not “directly” communicating with a switch that has STP enabled, there is less delay establishing a connection with the DHCP server.[/quote]

                    The intermediary switch just makes the connection between your DHCP server and the FOG Server so things can still boot.

                    iPXE does not communicate directly with the switch for DHCP. PXE boot’s, get’s DHCP and then loads the undionly.kpxe file. After this point, to use the “new” protocols within iPXE, ipxe requests it’s own dhcp information. The timeout between PXE and iPXE is vastly skewed. iPXE must wait for proxyDHCP address, then if those “timeout” it requests regular DHCP. Mind you these are in the milisecond to second intervals of “waiting”. The STP “blocks” the DHCP address during this time, unintentionally.

                    STP works like this:
                    Establish that there is a link on the port. Clear the port, enable forwarding to the port, PXE doesn’t mind all of this and will ‘wait’ for a much longer time to get DHCP. This isn’t all bad, BUT, when iPXE is re-requesting dhcp, STP ‘blocks’ the connection by, disabling and resetting the port, re-open the port, re-forward the port. Sometimes, this action causes a longer delay than what iPXE is expecting so iPXE DHCP requests ‘timeout’.

                    [quote=“Tribble, post: 29175, member: 17221”]Now, I will admit that i do notice a shorter time to pick up DHCP when i have the intermediary switch in place, but i never realized that switches had anything to do with DHCP packets and requests other than routing them to the correct ports.

                    I won’t be able to get on those switches until possibly friday due to our DR testing schedule, but i’ll be sure to let you know what happens. I know we haven’t done much if any customizing to those managed switches from their default state, so STP being enabled is certainly possible.[/quote]

                    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! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                    Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                    Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                    1 Reply Last reply Reply Quote 0
                    • B
                      bveiga
                      last edited by

                      hi i´m getting the error “could not start: download operation not supported” but this only happens in one domain, in the others we have the same server with no problems,the switches are equals on both domains(cisco), can anybody help me please?
                      best regards

                      Bruno

                      [url=“/_imported_xf_attachments/0/905_fog.png?:”]fog.png[/url]

                      1 Reply Last reply Reply Quote 0
                      • W
                        Wolfbane8653 Developer
                        last edited by

                        [quote=“bveiga, post: 29369, member: 24091”]hi i´m getting the error “could not start: download operation not supported” but this only happens in one domain, in the others we have the same server with no problems,the switches are equals on both domains(cisco), can anybody help me please?
                        best regards

                        Bruno[/quote]

                        This is not the iPXE “0x040ee119 error” please make a new thread.

                        1 Reply Last reply Reply Quote 0
                        • R
                          RipAU
                          last edited by

                          Hi,

                          Not sure if this helps at all, but I am finding even when building from the master iPXE source with the iPXE script that I am getting the same error, but when I forgot to add the option for CONSOLE_VESAFB into the build, all of a sudden I could boot my ipxe.kkpxe file in my DNSMasq server. As soon as I built it back in the error returned

                          The resulting menu is ugly but it does boot.
                          Not sure if this helps or not?

                          Cheers,

                          1 Reply Last reply Reply Quote 0
                          • B
                            Buddy
                            last edited by

                            Ripau which error?

                            1 Reply Last reply Reply Quote 0
                            • R
                              RipAU
                              last edited by

                              Sorry I jumped ahead of myself.
                              I was getting the error 0x040ee119 error when using the iPXE files from Toms website. ([url]https://mastacontrola.com/ipxe/[/url])

                              But what I did notice was that if I leave the CONSOLE_VESAFB out of the build and write my own iPXE script into the embedded ipxe.kkpxe file it seems to boot with my laptops. (Dell E5410)

                              [CODE]#!ipxe
                              ifopen net0
                              dhcp
                              cpuid --ext 29 && set arch x86_64 || set arch i386
                              params
                              param mac ${net0/mac}
                              param arch ${arch}
                              chain http://10.0.0.253/fog/service/ipxe/boot.php##params
                              [/CODE]

                              if I use the following fog iPXE script it seems to fail with that error.

                              [CODE]#!ipxe
                              sync --timeout 500
                              dhcp || reboot
                              chain default.ipxe || exit[/CODE]

                              I don’t mean to derail this thread if I’m not posting into the right place.

                              :edit:

                              I was using my own server as well as [url]https://rom-o-matic.eu/[/url] to make the files with the embedded script options.

                              1 Reply Last reply Reply Quote 0
                              • Tom ElliottT
                                Tom Elliott
                                last edited by

                                [quote=“RipAU, post: 29482, member: 24459”]Sorry I jumped ahead of myself.
                                I was getting the error 0x040ee119 error when using the iPXE files from Toms website. ([url]https://mastacontrola.com/ipxe/[/url])

                                But what I did notice was that if I leave the CONSOLE_VESAFB out of the build and write my own iPXE script into the embedded ipxe.kkpxe file it seems to boot with my laptops. (Dell E5410)

                                [CODE]#!ipxe
                                ifopen net0
                                dhcp
                                cpuid --ext 29 && set arch x86_64 || set arch i386
                                params
                                param mac ${net0/mac}
                                param arch ${arch}
                                chain http://10.0.0.253/fog/service/ipxe/boot.php##params
                                [/CODE]

                                if I use the following fog iPXE script it seems to fail with that error.

                                [CODE]#!ipxe
                                sync --timeout 500
                                dhcp || reboot
                                chain default.ipxe || exit[/CODE]

                                I don’t mean to derail this thread if I’m not posting into the right place.

                                :edit:

                                I was using my own server as well as [url]https://rom-o-matic.eu/[/url] to make the files with the embedded script options.[/quote]

                                Interesting,

                                Basically your compiled script is what the default.ipxe script does.

                                I’ll make a modification to the ipxescript and put those undionly.kpxe.

                                Can somebody test and see if it helps?

                                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! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                                Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                                Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                                1 Reply Last reply Reply Quote 0
                                • Tom ElliottT
                                  Tom Elliott
                                  last edited by

                                  Rebuilt, only change based on suspicion of the issue would be removing the sync --timeout command from the default.ipxe.

                                  link to try:
                                  [url]http://mastacontrola.com/ipxe/latest[/url]

                                  My suspicion is it’s not a CONSOLE_VESAFB problem, but that your CPU’s don’t like the sync command. We don’t really need it anymore, it was when we KNEW it was a timing issue and an attempt to delay that timing. Hopefully my theory’s correct and will work now.

                                  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! Get in contact with me (chat bubble in the top right corner) if you want to join in.

                                  Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)

                                  Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG

                                  1 Reply Last reply Reply Quote 0
                                  • B
                                    Buddy
                                    last edited by

                                    Will check it against my environment to see if it helps me. Will post back tonight.

                                    1 Reply Last reply Reply Quote 0
                                    • R
                                      RipAU
                                      last edited by

                                      Ok just tested with each file in --> [url]http://mastacontrola.com/ipxe/latest/[/url]

                                      I’m finding the ipxe.kkpxe still has error 040ee119 but the undionly.kkpxe had an error with default.ipxe error 3d126001 (Dell OptiPlex 755 and Dell Latitude E5410)
                                      I didn’t get the error code for the rest of the files but I can re-test and write them down if needed.

                                      1 Reply Last reply Reply Quote 0
                                      • B
                                        Buddy
                                        last edited by

                                        Just tested them all as well. undionly.pxe throws it in a boot loop (but still gets error (op not sup)- flashes really fast). ipxe.pxe does something new (see image below). The rest just did the operation not supported. The ipxe.pxe error doesn’t make a lot of sense though as seen in second pic the path is correct.

                                        [url=“/_imported_xf_attachments/0/913_ScreenShot535.png?:”]ScreenShot535.png[/url][url=“/_imported_xf_attachments/0/914_ScreenShot536.png?:”]ScreenShot536.png[/url]

                                        1 Reply Last reply Reply Quote 0
                                        • B
                                          Buddy
                                          last edited by

                                          The above was off a dell 390. Just tested them all on hp 8300 elite:

                                          unidonly.pxe - - puts it into a boot loop

                                          All others = operation not supported.

                                          1 Reply Last reply Reply Quote 0
                                          • R
                                            RipAU
                                            last edited by

                                            Hi guys, as a quick workaround till the iPXE issues are working I posted this in another post.
                                            Might help a few people?

                                            [url]http://fogproject.org/forum/threads/ipxe-issues-work-around.10727/[/url]

                                            Cheers,

                                            1 Reply Last reply Reply Quote 0
                                            • 1
                                            • 2
                                            • 3
                                            • 4
                                            • 5
                                            • 6
                                            • 4 / 6
                                            • First post
                                              Last post

                                            227

                                            Online

                                            12.0k

                                            Users

                                            17.3k

                                            Topics

                                            155.2k

                                            Posts
                                            Copyright © 2012-2024 FOG Project