[Bug 1437024] Re: Failure to PXE-boot from secondary NIC

[Rod Smith]

Another update on this:

I updated jolteon (the Lenovo x3550 M5 that was the original source of
this bug report) with the latest firmware I could find (v.2.21, build
TBE126Q, dated 2016-11-18) and reproduced the original bug. It appears
to be unchanged, with one twist: At one point, the system was booting
normally, so long as MAAS configured the system to use DHCP for ALL its
Ethernet ports. After some changes to the system settings, though, it
stopped working again even with those settings. I suspect that the PXE
and MAAS DHCP-provided IP addresses synced up briefly, but then went out
of sync again.

Also, the boot sequence on a failure looks something like this (taken
from jolteon, the Lenovo x3550):

>>Start PXE over IPv4.
  Station IP address is 10.1.10.128

  Server IP address is 10.1.10.2
  NBP filename is bootx64.efi
  NBP filesize is 1169992 Bytes
 Downloading NBP file...

  Succeed to download NBP file.

 Downloading NBP file...

  Succeed to download NBP file.
Fetching Netboot Image
error: couldn't send network packet.

                             GNU GRUB  version 2.02~beta2-36ubuntu3.12

   Minimal BASH-like line editing is supported. For the first word, TAB lists possible        
   command completions. Anywhere else TAB lists possible device or file completions.          


grub> 

Note the "couldn't send network packet" message. This message isn't
always visible (perhaps it flashes by too quickly to notice?). This is
consistent with the Wireshark output, which shows no packets received by
the MAAS server.

I've managed to get the Supermicro server to boot reliably. The trick
for it is to configure it to PXE-boot from one of its 10 Gbps NICs
rather than from its 1 Gbps NIC. The procedure for configuring the
Lenovo to boot reliably is documented at
https://wiki.canonical.com/CDO/HardwareCertification/LenovoxM5. This is
tedious because of the Lenovo's complex firmware setup utility with many
interacting settings.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1437024

Title:
  Failure to PXE-boot from secondary NIC

Status in MAAS:
  Invalid
Status in grub2 package in Ubuntu:
  New

Bug description:
  On a Lenovo x3550 M5 with the standard 4-port 1Gbps NICs and a
  secondary (plug-in) 2-port 10Gbps NIC, an attempt to PXE-boot from the
  secondary NIC in UEFI mode causes a boot failure with a "grub>" prompt
  on the display.

  This server arrived for certification with both NICs enabled. I
  suspect, but am not positive, that which NIC is chosen for booting is
  semi-random, although it favors the secondary NIC. The system PXE-
  boots fine from the built-in ports (generally the first one, eth0),
  and when booting from eth0 is forced via the UEFI boot menu,
  enlistment, commissioning, deployment, and post-deployment booting all
  work fine.

  When the system PXE-boots from the secondary NIC, though, the normal
  UEFI PXE-boot messages appear on the screen, followed by the
  aforementioned "grub>" prompt. This obviously prevents normal
  operation of the server with MAAS. It appears from the logs (attached)
  that when using the failed NIC, the MAAS server doesn't receive
  follow-on requests from GRUB.

  As a workaround, the secondary NICs can be configured to not support
  PXE-booting in the firmware setup utility; this enables normal
  deployment via MAAS.

  MAAS version information:

  $ dpkg -l '*maas*'|cat
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name                                                  Version                                             Architecture Description
  +++-=====================================================-===================================================-============-===============================================================================
  ii  maas                                                  1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS server all-in-one metapackage
  ii  maas-cli                                              1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS command line API tool
  ii  maas-cluster-controller                               1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS server cluster controller
  ii  maas-common                                           1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS server common files
  ii  maas-dhcp                                             1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS DHCP server
  ii  maas-dns                                              1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS DNS server
  ii  maas-proxy                                            1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS Caching Proxy
  ii  maas-region-controller                                1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS server complete region controller
  ii  maas-region-controller-min                            1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS Server minimum region controller
  ii  python-django-maas                                    1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS server Django web framework
  ii  python-maas-client                                    1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS python API client
  ii  python-maas-provisioningserver                        1.7.2+bzr3355-0ubuntu1~trusty1                      all          MAAS server provisioning libraries

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1437024/+subscriptions