** Changed in: maas
Milestone: next => None
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit
SFI/SFP+
To manage noti
My organization has been struggling with this issue for ~6 months, and
the fix Christian describes in comment #44 resolved this problem for us.
I used the bionic-updates instead of xenial-updates, and enterprise
wide, the grub rescue console does NOT display anymore when loading the
PXE menu. Mond
+1 with i350 NICs (many of them so this is consistently reproducible).
We worked it around as follows (on the MAAS server):
cd /tmp
wget
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/uefi/grub2-amd64/2.02~beta2-36ubuntu3.18/grubnetx64.efi.signed
cp -p grubnetx64.efi.signed
/var/lib
Hi,
I was also affected by this issue - to PXE boot at UEFI for add-on adapter i350
1Gb interface. Upgrading the MAAS server version to 18.04 bionic release did
not solve the symptom. But I was able to find a workaround by booting first the
IPv6 before IPv4 - the same workaround mentioned by Rod
** Changed in: maas-images
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit
SFI/SF
So this also affects Bionic... will this fix land in 18.04.1 (or sooner
via SRU?)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2 (Ubuntu Trusty)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2-signed (Ubuntu Trusty)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2-signed (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
I consider this as tested as well. It's less of a problem when the fix
simply does not work for some, as in the worst case we can just re-open
the bug (or get another one filled) if not all use-cases are handled. As
long as the fix works for certain users and does not introduce
regressions, for hig
This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu3.18
---
grub2 (2.02~beta2-36ubuntu3.18) xenial; urgency=medium
* debian/patches/efinet_check_imm_completion.patch: check for immediate
completion when sending data to the net device buffer. This is a required
comm
This bug was fixed in the package grub2-signed - 1.66.18
---
grub2-signed (1.66.18) xenial; urgency=medium
* Rebuild against grub2 2.02~beta2-36ubuntu3.18. (LP: #1437353)
-- Mathieu Trudel-Lapierre Tue, 20 Mar 2018
10:27:27 -0400
** Changed in: grub2-signed (Ubuntu Xenial)
I have positively verified that an affected system (which has a 82599ES
10-Gigabit SFI/SFP+) exhibits the ARP storm behavior when booting with
MAAS using the grubnetx64.efi binary in xenial(-updates), leading to
stopping in the grub prompt; and with the grubnetx64.efi binary in
xenial-proposed no A
I've been doing more testing on this, after finding a system with a
10GE NIC that seems affected. With 2.02~beta2-36ubuntu3.17 it's
unhappy, but with 2.02~beta2-36ubuntu3.18 it looks like things are
working just fine.
For now, I'm putting this back to verification-needed until I can
finish the tes
Well, the CI part confirms that there is no regression, but there is as
yet no indication that the issue is fixed aside from the cases where
firmware was updated (but then, it's not the SRU).
There's still a need to verify the fix positively on affected hardware.
Now, KingJ's comment says that te
>From the SRU team's perspective, seeing the comments here, it's really
hard to see if the fix has been verified or not. The verification
comment #27 does not make it clear if the test was performed on affected
hardware or not. Was it? If yes, please clarify. Also, the test case in
the description
Field High SLA now requires that a estimated date for a fix is listed in
the comments. Please provide this estimate for the open tasks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
U
@kj-kingj
I applied the patch myself
$ cd /home/$USER/software
$ mkdir grub2 && cd grub2
$ apt-get source grub-efi-amd64
(add patch to grub2-2.02~beta2/debian/patches)
# apt-get install dh-autoreconf help2man gcc-4.7-multilib xfonts-unifont
libusb-dev libdevmapper-dev libsdl1.2-dev xorriso qemu-
I'm seeing this with a HP NC523SFP 10G NIC and MASS 2.4.0~beta2 on
Ubuntu 18.04. If I UEFI boot from the NIC, it eventually brings up a
grub shell. Taking a packet capture confirmed the same ARM storm
behaviour when attempting to boot - thousands of packets from the server
that is being commissione
The MAAS CI has built new images using -proposed, which includes the
bootloaders (and hence, grub from -proposed):
{
"content_id": "com.ubuntu.maas:daily:1:bootloader-download",
"datatype": "image-downloads",
"format": "products:1.0",
"products": {
"com.ubuntu.maas.daily:1:grub-efi-signed:u
Anybody able to help verifying this?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit
SFI/SFP+
To manage notifications a
The bug identified was not a regression from the SRU. We still need
testing on this stable update.
** Tags removed: verification-failed-xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Ti
I have already flashed all of my Intel Nics with the latest firmware. I
am unable to verify this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for ad
@Matt,
@Russell,
Is the package is xenial-proposed something you could help verifying? I
do not have access to hardware that would exhibit this issue; it would
help greatly in providing the fix to have someone with this hardware
follow the steps in
https://wiki.ubuntu.com/QATeam/PerformingSRUVerif
** Tags added: id-5ab2aac1fcfcb094be6eb2e1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit
SFI/SFP+
To manage notificat
Hello Matt, or anyone else affected,
Accepted grub2-signed into xenial-proposed. The package will build now
and be available at
https://launchpad.net/ubuntu/+source/grub2-signed/1.66.18 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://
Hello Matt, or anyone else affected,
Accepted grub2 into xenial-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/grub2/2.02~beta2-36ubuntu3.18 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https:
** Description changed:
[Impact]
MAAS commissioning may fail when deploying Xenial images or using grubx64.efi
from Xenial due to hardware particularities of some Intel 82599-based network
cards. Other network manufacturers may be affected as well. The main failure
mode appears to be an inf
** Changed in: grub2 (Ubuntu Yakkety)
Status: New => Won't Fix
** Changed in: grub2-signed (Ubuntu Yakkety)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
** Description changed:
[Impact]
MAAS commissioning may fail when deploying Xenial images or using grubx64.efi
from Xenial due to hardware particularities of some Intel 82599-based network
cards. Other network manufacturers may be affected as well. The main failure
mode appears to be an inf
** Tags added: cpe-onsite
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit
SFI/SFP+
To manage notifications about this b
** Description changed:
- I am using MAAS to commission and install machines. When I attempt to
commission a machine with a "82599ES 10-Gigabit SFI/SFP+" network adapter the
following happens:
+ [Impact]
+ MAAS commissioning may fail when deploying Xenial images or using grubx64.efi
from Xenia
** Also affects: grub2-signed (Ubuntu)
Importance: Undecided
Status: New
** Changed in: grub2-signed (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: grub2-signed (Ubuntu Xenial)
Status: New => In Progress
** Changed in: grub2-signed (Ubuntu Xenial)
Assigne
We should be able to SRU this patch to the relevant releases.
** Changed in: grub2 (Ubuntu)
Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)
** Changed in: grub2 (Ubuntu)
Status: Confirmed => In Progress
** Changed in: grub2 (Ubuntu)
Status: In Progress => Fix Rel
I'm gonna add the maas-images project to this, so that when fixes get
SRU'd we can just make sure new images get published.
** Also affects: maas-images
Importance: Undecided
Status: New
** Changed in: maas-images
Status: New => Triaged
** Changed in: maas-images
Importance:
I've replaced grubx64.efi from 16.04 with the one from 17.04 and problem
went away. This means that problem is indeed in grub or grub in 16.04
doesn't have needed workarounds for faulty firmwares.
** Changed in: grub2 (Ubuntu)
Status: Invalid => Confirmed
** Changed in: grub2 (Ubuntu)
I
@Russell I'd test it. I'm having this problem with latest packages in
Xenial.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-Giga
We're seeing this (or something very similar) on an Intel X540 10GbE
Dual port Mezzanine adaptor (Intel 82599 Controller) in a Dell server.
I'll follow up with firmware revision numbers when I have them. It'd be
helpful if others who've hit this provided them as far as they can.
Does this patch l
Thanks, Matt, the Lenovo agent has upgrade the UEFI and this issue has
gone.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-Gigab
https://downloadcenter.intel.com/downloads/eula/19186/Intel-Ethernet-
Connections-Boot-Utility-Preboot-images-and-EFI-
Drivers?httpDown=http%3A%2F%2Fdownloadmirror.intel.com%2F19186%2Feng%2FPreboot.tar.gz
~/APPS/BootUtil/Linux_x64$ sudo ./bootutil64e -IV -ALL
Intel(R) Ethernet Flash Firmware Util
Hi Matt,
Can you supply the latest firmware version? I meet this bug but not sure
whether the server has the latest firmware.
Thanks,
Andy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Final conclusion. I did not have the latest firmware for the adapter.
After updating the firmware I can UEFI boot the system.
** Changed in: maas
Status: Triaged => Invalid
** Changed in: grub2 (Ubuntu)
Status: New => Invalid
** Changed in: python-tx-tftp
Status: New => Inv
The first get status call (efi_call_3(net->get_status, ...)) returns
GRUB_EFI_SUCCESS and sets txbuf to 0. The second time this function is
called it enters the while loop and the get status call
(efi_call_3(net->get_status, ...)) returns GRUB_EFI_SUCCESS and sets
txbuf to 1 which does not match t
I checked out the latest version of grub, built an image using grub-mknetdir,
and the ARP storm is from the efinet driver. The
code is stuck in the following loop in net/drivers/efi/efinet.c lines 43
through 66. efi_call_3 always returns a txbuf that does not match dev->txbuf,
and eif_call_7
** Also affects: grub2 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-Gigabi
This bug actually seems to be related more to how MAAS handles the TFTP
request. Doesn't really seem to be a grub issue now that I look more a
the logs. Going to remove grub2 on this bug as the MAAS TFTP server
needs to be fixed.
I am seeing two different errors in the log.
http://paste.ubuntu.co
Seems that grubnetx64.efi is hanging with that interface as it should
next request the grub/grub.cfg file, but that never occurs. Feels like
its a grubnetx64.efi issue, targeting to that as well.
** Changed in: maas
Status: New => Triaged
** Changed in: maas
Importance: Undecided => Hig
47 matches
Mail list logo
