This bug was fixed in the package grub2-signed - 1.66.6
---
grub2-signed (1.66.6) xenial; urgency=medium
* Rebuild against grub2 2.02~beta2-36ubuntu3.6. (LP: #1229458,
#1519836)
-- Mathieu Trudel-Lapierre Mon, 19 Dec 2016
21:12:45 -0500
** Changed in: grub2-signed (Ubuntu Xenia
This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu3.6
---
grub2 (2.02~beta2-36ubuntu3.6) xenial; urgency=medium
* Fix support for IPv6 PXE booting under UEFI: (LP: #1229458)
- grub_add_grub_env_set_net_property.patch: add grub_env_set_net_property.
- misc-fix-inva
Verified that both IPv4 pxeboot and IPv6 uefi boot cleanly into MAAS.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229458
Title
Hello Steve, 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.6 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https:
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229458
Title:
grubnetx64.efi tftp client does not work over ipv6
To manage notif
** Description changed:
[Impact]
Trying to PXE boot (with UEFI) over IPv6 with grub. This is especially
relevant for MAAS users in IPv6 setups.
[Test cases]
+
+ [IPv6 PXE boot]
0) Setup PXE boot infrastructure
(https://wiki.ubuntu.com/UEFI/SecureBoot-PXE-IPv6, also
https://github.co
This is a functionality change inasmuch as it gives admins the
possibility to use the same method for booting IPv4 and IPv6 using a URL
for HTTPClient rather than relying on the next-server/tftp for IPv4 only
(and thus a path) and either URL or path for IPv6 -- it's cleanup that
goes with the rest
@cyphermox -- having reviewed the SRU request in the queue, overall it
is looking reasonable as it is. There is some concern that there is
some potential for functionality changes for IPv4 clients. Also it
would be good to understand better how the HTTPClient vendor extension
might affect IPv4.
** Changed in: maas
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/1229458
Title:
grubnetx64.efi tftp client does not work over ipv6
To manage notifications ab
** Tags removed: verification-failed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229458
Title:
grubnetx64.efi tftp client does not work over ipv6
To manage notifications about this bug go to:
ht
** Changed in: maas
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229458
Title:
grubnetx64.efi tftp client does not work over ipv6
To manage notifications about
Fixed in yakkety:
grub2 (2.02~beta2-36ubuntu11) yakkety; urgency=medium
* debian/control: don't force building with GCC 5 when 6 is now the default.
* support_module_without_symbol_table.patch: fix checks for modules without
a symbol table to be allowed, since binutils' 'strip --stripunne
** Tags added: maas-ipv6
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229458
Title:
grubnetx64.efi tftp client does not work over ipv6
To manage notifications about this bug go to:
https://bugs.l
FWIW, I'm not sure what was releasing the IP; I only noticed that it was
being released. I've done more work on this and while I didn't notice
this behavior (didn't look, to be honest...) it appears that grub2 is
behaving correctly in terms of configuring the efinet device for IPv6,
and apparently
> It appears that bootx64.efi finished loading grub, released the
> IP, got the reply for the release, and launched grubx64.efi
That sounds buggy to me, why should shim release the IP instead of
leaving it provisioned in firmware? I'm sure we do still need grub
fixed to correctly dhcp in the case
** Attachment added: "screenshot of the failed attempt"
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1229458/+attachment/4724000/+files/1229458-screenshot.jpg
** Changed in: grub2 (Ubuntu)
Status: Fix Released => In Progress
--
You received this bug notification because you ar
With this dhcpv6 and the bootloaders from yakkety (as of yesterday's
date), we get http://people.canonical.com/~lamont/1229458-screenshot.jpg
(I'll attach that momentarily). It appears that bootx64.efi finished
loading grub, released the IP, got the reply for the release, and
launched grubx64.efi
Adding the MAAS project so that we have a vehicle to confirm the fix in
MAAS.
** Also affects: maas
Importance: Undecided
Status: New
** Changed in: maas
Status: New => Confirmed
** Changed in: maas
Importance: Undecided => High
** Changed in: maas
Milestone: None => 2.1
Hello Steve, 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.3 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https:
** Also affects: grub2-signed (Ubuntu)
Importance: Undecided
Status: New
** Changed in: grub2-signed (Ubuntu)
Status: New => Fix Released
** Changed in: grub2-signed (Ubuntu Xenial)
Status: New => In Progress
** Changed in: grub2-signed (Ubuntu)
Importance: Undecided =
** Description changed:
+ [Impact]
+ Trying to PXE boot (with UEFI) over IPv6 with grub. This is especially
relevant for MAAS users in IPv6 setups.
+
+ [Test cases]
+ 0) Setup PXE boot infrastructure
(https://wiki.ubuntu.com/UEFI/SecureBoot-PXE-IPv6, also
https://github.com/openSUSE/kiwi/wiki/
** Also affects: grub2 (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: grub2 (Ubuntu Xenial)
Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)
** Changed in: grub2 (Ubuntu Xenial)
Importance: Undecided => High
** Changed in: grub2 (Ubuntu Xenial)
This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu10
---
grub2 (2.02~beta2-36ubuntu10) yakkety; urgency=medium
* debian/patches/ip6_send_router_solicitation_7c4b6b7b.patch: handle long
RA intervals by explicitly sending a SOLICIT.
* debian/patches/ip6_fix_routing_eb
** Changed in: grub2 (Ubuntu)
Status: Confirmed => In Progress
** Changed in: grub2 (Ubuntu)
Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launch
I'm curious if there is any change in behavior when using a hostname
that resolves to a record instead of an IP address. Browsing the
grub source code, it looks like if it has an IP address, it assumes IPv4
and generates that (tftp,x.x.x.x) string you saw.
--
You received this bug notificati
This bug is still present in grub2 2.02~beta2-21 in vivid. The output
is no longer the same - the "Error: couldn't send network packet"
message is no longer shown - but the boot eventually drops to a grub
shell and the environment shows the same kind of corruption as before,
with a broken IPv4 add
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: grub2 (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/1229458
Title:
grub
Details on how to configure a DHCPv6 server in order to reproduce this can be
found here:
https://wiki.ubuntu.com/UEFI/SecureBoot-PXE-IPv6#DHCPv6_.28isc-dhcp-server.29
** Changed in: grub2 (Ubuntu)
Importance: Undecided => High
** Changed in: grub2 (Ubuntu)
Milestone: None => ubuntu-14.
28 matches
Mail list logo
