[Bug 1785859] Re: [REGRESSION] ppc64el grub in bionic may be auto-generating MAC address instead of using the assigned to the VM.
Launchpad Bug Tracker
1785859 at bugs.launchpad.net
Sun Aug 26 14:13:49 UTC 2018
This bug was fixed in the package grub2 - 2.02+dfsg1-5ubuntu1
---------------
grub2 (2.02+dfsg1-5ubuntu1) cosmic; urgency=medium
[ Mathieu Trudel-Lapierre]
* Merge against Debian unstable; remaining changes:
- debian/control: Update Vcs fields for code location on Ubuntu.
- debian/control: Breaks shim (<< 13).
- Secure Boot support: use newer patchset from rhboot repo:
- many linuxefi_* patches added and modified
- dropped debian/patches/linuxefi_require_shim.patch
- renamed: debian/patches/no_insmod_on_sb.patch ->
debian/patches/linuxefi_no_insmod_on_sb.patch
- debian/patches/install_signed.patch, grub-install-extra-removable.patch:
- Make sure if we install shim; it should also be exported as the default
bootloader to install later to a removable path, if we do.
- Rework grub-install-extra-removable.patch to reverse its logic: in the
default case, install the bootloader to /EFI/BOOT, unless we're trying
to install on a removable device, or explicitly telling grub *not* to
do it.
- Move installing fb$arch.efi to --no-extra-removable; as we don't want
fallback to be installed unless we're also installing to /EFI/BOOT.
(LP: #1684341)
- Install a BOOT.CSV for fallback to use.
- Make sure postinst and templates know about the replacement of
--force-extra-removable with --no-extra-removable.
- debian/patches/add-an-auto-nvram-option-to-grub-install.patch: Add the
--auto-nvram option to grub-install for auto-detecting NVRAM availability
before attempting NVRAM updates.
- debian/build-efi-images: provide a new grub EFI image which enforces that
loaded kernels are signed for Secure Boot: build gsb$arch.efi; which is
the same as grub$arch.efi minus the 'linux' module. Without fallback to
'linux' for unsigned loading, this makes it effectively enforce having a
signed kernel. (LP: #1401532)
- Verify that the current and newer kernels are signed when grub is
updated, to make sure people do not accidentally shutdown without a
signed kernel.
- debian/default/grub: replace GRUB_HIDDEN_* variables with the less
confusing GRUB_TIMEOUT_STYLE=hidden. (LP: #1258597)
- debian/patches/support_initrd-less_boot.patch: Added knobs to allow
non-initrd boot config. (LP: #1640878)
- Disable os-prober for ppc64el on the PowerNV platform, to reduce the
number of entries/clutter from other OSes in Petitboot (LP: #1447500)
- debian/patches/shorter_version_info.patch: Only show the upstream version
in menu and console, and hide the package one in a package_version
variable. (LP: #1723434)
- debian/patches/skip_text_gfxpayload_where_not_supported.patch: Skip the
'text' payload if it's not supported but present in gfxpayload, such as
on EFI systems. (LP: #1711452)
- debian/patches/bufio_sensible_block_sizes.patch: Don't use arbitrary file
fizes as block sizes in bufio: this avoids potentially seeking back in
the files unnecessarily, which may require re-open files that cannot be
seeked into, such as via TFTP. (LP: #1743249)
* util/grub-install.c: Drop extra handling for x.efi.signed files for mok
and fallback binaries: shim now installs them without the .signed
extension. (LP: #1708245)
- debian/patches/dont-fail-efi-warnings.patch: handle linuxefi patches and
the casting they do on some architectures: we don't want to fail build
because of some of the warnings that can show up since we otherwise build
with -Werror.
* debian/rules: shuffle files around for now to keep putting build artefacts
for signing at the same location as they were expected by Launchpad.
[ Julian Andres Klode ]
* debian/patches/ofnet-init-structs-in-bootpath-parser.patch: initialize
structs in bootpath parser. Fixes netboot issues on ppc64el. (LP: #1785859)
grub2 (2.02+dfsg1-5) unstable; urgency=medium
[ Colin Watson ]
* Change Maintainer to pkg-grub-devel at alioth-lists.debian.net, following
Alioth lists migration.
* Backport from upstream:
- Use grub-file to figure out whether multiboot2 should be used for
Xen.gz (closes: #898947).
- x86-64: Treat R_X86_64_PLT32 as R_X86_64_PC32.
* Fix some test failures:
- Disable sercon in SeaBIOS.
- Fix qemu options for UHCI test.
[ Philipp Hahn ]
* Disallow unsigned kernels if UEFI Secure Boot is enabled
(patch by Linn Crosetto <linn at hpe.com>)
* Add patch to fix lockdown mode
(patch by Luca Boccassi <bluca at debian.org>)
* Build monolithic EFI binaries for signing (closes: #851994)
* Add template for signing monolithic EFI binaries
* debian/build-efi-images: Use correct EFI vendor (closes: #769172)
[ Luca Boccassi ]
* template packages: install changelog and copyright
* Override lintian error about template rules file
* Add XB-Efi-Vendor metadata to efi-*-bin packages
grub2 (2.02+dfsg1-4) unstable; urgency=medium
* Adjust restore_mkdevicemap.patch to fix format-overflow warning with GCC
7 (the overflow was in fact impossible in practice, but GCC couldn't
prove that).
* Cherry-pick upstream patch to disable -Wformat-truncation on GCC >= 7 in
printf_unit_test.
* Build with GCC 7 (closes: #892397).
grub2 (2.02+dfsg1-3) unstable; urgency=medium
* sparc64: Don't use devspec to determine the OBP path (closes: #854568).
* ieee1275: Fix crash in of_path_of_nvme when of_path is empty (closes:
#891773).
* sparc64: Limit nvme of_path_of_nvme to just SPARC.
grub2 (2.02+dfsg1-2) unstable; urgency=medium
* Build-depend on libparted-dev on powerpc and ppc64 (closes: #891070).
* Add support for modern sparc64 hardware (thanks, Eric Snowberg via John
Paul Adrian Glaubitz; closes: #854568).
* Build without PIE on sparc and sparc64 (thanks, John Paul Adrian
Glaubitz; closes: #891733).
grub2 (2.02+dfsg1-1) unstable; urgency=medium
* Switch to tracking debian/grub-extras/ using "git subtree" rather than
submodules.
* Update debian/README.source for Salsa migration.
* Use pkg-config to find FreeType (closes: #887721).
* Change various binary packages' priorities to optional, since "Priority:
extra" is now deprecated.
* Repack upstream tarball without grub-core/lib/libgcrypt*/cipher/crc.c,
and provide a replacement implementation backported from more recent
versions of libgcrypt (closes: #745409).
* Cherry-pick upstream patch to avoid -Werror=unused-value build failure
(closes: #890431).
* Handle the case where udevadm exists but is non-functional, as warned
about by Lintian 2.5.75.
grub2 (2.02-3) unstable; urgency=medium
* Use current location for upstream signing key
(debian/upstream/signing-key.asc).
* Update upstream signing key to a non-expired version.
* Install bootinfo.txt and grub.chrp in grub-ieee1275-bin for ppc64, and
install and use prep-bootdev on powerpc and ppc64 as well as ppc64el
(thanks, John Paul Adrian Glaubitz; closes: #881730).
* Cherry-pick upstream patch to change the default TSC calibration method
to pmtimer on EFI systems (closes: #883193).
* Move VCS to salsa.debian.org.
* Consistently create /boot/grub in the postinst of all grub-<platform>
packages (closes: #884883).
[ Debconf translations ]
* [sq] Albanian (Silva Arapi; closes: #874497).
-- Mathieu Trudel-Lapierre <cyphermox at ubuntu.com> Thu, 23 Aug 2018
15:00:14 -0400
** Changed in: grub2 (Ubuntu)
Status: Fix Committed => Fix Released
--
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/1785859
Title:
[REGRESSION] ppc64el grub in bionic may be auto-generating MAC address
instead of using the assigned to the VM.
Status in maas-images:
Fix Released
Status in grub2 package in Ubuntu:
Fix Released
Status in grub2 source package in Bionic:
In Progress
Bug description:
[Impact]
grub2 on ppc64el wrongfully configures two interfaces for the same card when running in qemu with a tftp boot. This causes net_default_mac to point to the wrong mac address, amongst other things.
[Test case]
(1) grub-mknetdir --net-directory=$dir
(2) qemu-system-ppc64le -device virtio-net-pci,netdev=mynet,mac=$mac -netdev user,id=mynet,tftp=$dir,bootfile=boot/grub/powerpc-ieee1275/core.elf
grub loads successfully via tftp.
Verify that
(1) net_ls_cards shows the card with the correct mac addr $mac
(2) net_ls_addr shows one interface with mac $mac
(3) echo $net_default_mac shows the mac $mac
[Regression potential]
grub now correctly stores the mac address in variables, meaning that code now might not fallback to a default.
Apart from that/On the other hand, the fix is a simple case of
initializing variables, therefore that was possible before too, as it
was basically random anyway.
[Original bug report]
In MAAS, we use grub-mkimage to create a bootloader for VM's to PXE boot of MAAS by a grub bootloader that we provide over the network. (we call this bootppc64.bin).
This bootloader is created with the following grub configuration:
grub_config: |
# MAAS GRUB2 pre-loader configuration file
# Load based on MAC address first.
configfile (pxe)/grub/grub.cfg-${net_default_mac}
# Failed to load based on MAC address.
# Load arm64 by default, UEFI only supported by 64-bit
configfile (pxe)/grub/grub.cfg-default-arm64
When we use bionic bootloader, we see the following output in the
console:
"Booting under MAAS direction... [ grub.cfg-default-ppc 642B 100%
57.16B/s ]"
And in rackd.log we see:
2018-08-07 17:37:21 provisioningserver.rackdservices.tftp: [info] bootppc64.bin requested by 10.245.136.136
2018-08-07 17:37:24 provisioningserver.rackdservices.tftp: [info] /grub/grub.cfg-80:1c:b0:c0:7d:c5 requested by 10.245.136.136
2018-08-07 17:37:24 provisioningserver.rackdservices.tftp: [info] /grub/grub.cfg-default-ppc64el requested by 10.245.136.136
2018-08-07 17:37:24 provisioningserver.rackdservices.tftp: [info] ubuntu/ppc64el/ga-18.04/bionic/daily/boot-kernel requested by 10.245.136.136
This means that the VM attempted to PXE boot with MAC address
"80:1c:b0:c0:7d:c5", but the VM itself has a different MAC address
"52:54:00:7f:83:62"
<interface type='network'>
<mac address='52:54:00:7f:83:62'/>
<source network='maas'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</interface>
If we are to switch the bootloader to the one created with xenial as a
base, we see correct behavior.
"Booting under MAAS direction... [ grub.cfg-52:54:00:7f 640B 100%
0.62B/s ] "
And the result is that grub has used to correct MAC address for the
PXE process.
2018-08-07 17:07:45 provisioningserver.rackdservices.tftp: [info] bootppc64.bin requested by 10.245.136.136
2018-08-07 17:07:46 provisioningserver.rackdservices.tftp: [info] /grub/grub.cfg-52:54:00:7f:83:62 requested by 10.245.136.136
2018-08-07 17:07:47 provisioningserver.rackdservices.tftp: [info] ubuntu/ppc64el/generic/bionic/daily/boot-kernel requested by 10.245.136.136
2018-08-07 17:08:17 provisioningserver.rackdservices.tftp: [info] ubuntu/ppc64el/generic/bionic/daily/boot-initrd requested by 10.245.136.136
It would seem as the firmware in bionic is automatically generating a
new MAC address.
Bionic console log
-------------------------------------------------------------------------------
Using default console: /vdevice/vty at 30000000
Welcome to Open Firmware
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
This program and the accompanying materials are made available
under the terms of the BSD License available at
http://www.opensource.org/licenses/bsd-license.php
Trying to load: from: /pci at 800000020000000/ethernet at 4 ...
Initializing NIC
Reading MAC address from device: 52:54:00:7f:83:62
Requesting information via DHCP: done
Using IPv4 address: 10.245.136.136
Requesting file "bootppc64.bin" via TFTP from 10.245.136.6
Receiving data: 1665 KBytes
TFTP: Received bootppc64.bin (1665 KBytes)
Successfully loaded
Booting under MAAS direction... [ grub.cfg-default-ppc 642B 100% 57.16B/s ]
OF stdout device is: /vdevice/vty at 30000000initrd 55.89MiB 100% 647.54KiB/s ]
Preparing to boot Linux version 4.15.0-30-generic (buildd at bos02-ppc64el-011) (gcc version 7.3.0 (Ubuntu 7
.3.0-16ubuntu3)) #32-Ubuntu SMP Thu Jul 26 17:43:11 UTC 2018 (Ubuntu 4.15.0-30.32-generic 4.15.18)
Detected machine type: 0000000000000101
command line: BOOT_IMAGE=ubuntu/ppc64el/ga-18.04/bionic/daily/boot-kernel nomodeset ro root=squash:http:/
/10.245.136.6:5248/images/ubuntu/ppc64el/ga-18.04/bionic/daily/squashfs ip=::::maas-enlist:BOOTIF ip6=off
overlayroot=tmpfs overlayroot_cfgdisk=disabled cc:{datasource_list: [MAAS]}end_cc cloud-config-url=http:
//10-245-136-0--21.maas-internal:5248/MAAS/metadata/latest/enlist-preseed/?op=get_enlist_preseed apparmor
=0 log_host=10.245.136.6 log_port=514 BOOTIF=01-80:1c:b0:c0:7d:c5
Xenial console log
--------------------------------------------------------------------
Using default console: /vdevice/vty at 30000000 [1032/2975]
Welcome to Open Firmware
Copyright (c) 2004, 2017 IBM Corporation All rights reserved.
This program and the accompanying materials are made available
under the terms of the BSD License available at
http://www.opensource.org/licenses/bsd-license.php
Trying to load: from: /pci at 800000020000000/ethernet at 4 ...
Initializing NIC
Reading MAC address from device: 52:54:00:7f:83:62
Requesting information via DHCP: done
Using IPv4 address: 10.245.136.136
Requesting file "bootppc64.bin" via TFTP from 10.245.136.6
Receiving data: 1714 KBytes
TFTP: Received bootppc64.bin (1714 KBytes)
Successfully loaded
Booting under MAAS direction... [ grub.cfg-52:54:00:7f 640B 100% 0.62B/s ]
OF stdout device is: /vdevice/vty at 30000000initrd 55.89MiB 100% 958.95KiB/s ]
Preparing to boot Linux version 4.15.0-30-generic (buildd at bos02-ppc64el-011) (gcc version 7.3.0 (Ubuntu $
.3.0-16ubuntu3)) #32-Ubuntu SMP Thu Jul 26 17:43:11 UTC 2018 (Ubuntu 4.15.0-30.32-generic 4.15.18)
Detected machine type: 0000000000000101
command line: BOOT_IMAGE=ubuntu/ppc64el/generic/bionic/daily/boot-kernel nomodeset ro root=squash:http:/$
10.245.136.6:5248/images/ubuntu/ppc64el/generic/bionic/daily/squashfs ip=::::fast-cow:BOOTIF ip6=off ove$
layroot=tmpfs overlayroot_cfgdisk=disabled cc:{datasource_list: [MAAS]}end_cc cloud-config-url=http://10$
245-136-0--21.maas-internal:5248/MAAS/metadata/latest/by-id/4ysp63/?op=get_preseed apparmor=0 log_host=1$
.245.136.6 log_port=514 rootdelay=60 BOOTIF=01-52:54:00:7f:83:62
Max number of cores passed to firmware: 2048 (NR_CPUS = 2048)
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/1785859/+subscriptions
More information about the foundations-bugs
mailing list