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

Rod Smith rod.smith at canonical.com
Mon Aug 21 19:58:44 UTC 2017


Is there any progress on this? I'm encountering similar problems on at
least two more systems now (moltres and ostwald, which are Quanta S910
X31E and Supermicro SYS-6018R-WTR servers, respectively). I've managed
to find a working firmware setup to get the Quanta booting reliably, but
the Supermicro has eluded me thus far.

The Quanta has just two NICs, both of which are 1 Gbps units. To get it
to boot, I need to tell it to attempt an IPv6 boot before the IPv4 boot.
The IPv6 boot fails, but the system then attempts an IPv4 boot, which
succeeds. If the IPv4 boot is attempted prior to an IPv6 boot, it fails
with a "grub>" prompt; however, if the system is configured to attempt
an IPv6 boot between IPv4 attempts on two NICs, and if the user types
"exit" at the "grub>" prompt, the system will attempt the IPv6 boot,
fail, and then try IPv4 on the second NIC, which succeeds.

I'm attaching a tarball with an excerpt from the MAAS rackd.log file, a
video capture from the machine's remote KVM, and a Wireshark capture
file illustrating this sequence. From this output, it appears as if GRUB
is not requesting its configuration file.

** Attachment added: "MAAS rackd.log excerpt, capture of remote KVM console, and Wireshark packet capture of problem session"
   https://bugs.launchpad.net/maas/+bug/1437024/+attachment/4936565/+files/moltres-boot.tgz

-- 
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



More information about the foundations-bugs mailing list