2 Replies Latest reply on Jan 13, 2015 1:39 AM by Apachez

    DE3815TYKHE [BIOS 0041]:  iSCSI boot:  dead-end "MAC Selection" screen

    RobroyGregg

      Fellow NUC Fans,

       

      I have a DE3815TYKHE with BIOS revision 0041.

       

      I'm trying to configure it to boot from an iSCSI LU.  I see in the BIOS release notes that "Add iSCSI feature" appeared in revision 0032.

       

      In Advanced -> Devices and Peripherals -> Add-In Config -> iSCSI Configuration, I see these options:

       

      iSCSI Initiator Name

       

      Add an Attempt

      Delete Attempts

      Change Attempt Order

       

      I'm able to configure an iSCSI initiator IQN with no problems.

       

      When I choose "Add an Attempt," I see screen entitled, "MAC Selection," yet the screen appears to be a dead-end; my only option's to back out by hitting <Esc>.

       

      Here's a screenshot:  http://www.robroygregg.com/misc/2015Jan11_AtomNUC_iSCSI_0.JPG

       

      Has anybody successfully booted a DE3815TYKHE from iSCSI?

       

      Thanks so very much,

      Robroy

        • 1. Re: DE3815TYKHE [BIOS 0041]:  iSCSI boot:  dead-end "MAC Selection" screen
          RobroyGregg

          Fellow NUC Fans,

           

          I've found a workaround.

           

          While enduring this symptom, my NUC's clock was set about eight hours in the future (fast).  I thought that was irrelevant.

           

          Yet after adjusting the clock to my local time (US/Pacific) and re-entering Visual BIOS, the NIC came online, and the iSCSI configuration screens became functional.

           

          I believe this is a firmware bug; it seems like the NIC should come online while entering Visual BIOS regardless of the clock's setting.  Would y'all agree?

           

          Thanks so very much,

          Robroy

          • 2. Re: DE3815TYKHE [BIOS 0041]:  iSCSI boot:  dead-end "MAC Selection" screen
            Apachez

            Sounds like an odd and funny bug...

             

            What if you manually set the clock +8 hours into the future and reboot?

             

            Can you spot at which difference the NIC stops working, will +4 hours work but not +5?

             

            Only thing I can come up with that is time dependent is if some kind of ssl certificate (or similar for encryption) is being used for your iscsi initialisation. In those cases mismatching clock can make the ssl (or such) handshake to fail. Timestamps might also be used in IP-packets but that would a really odd bug if that would be related to the issues you are seeing.