[Bug 1879012] Re: GRUB does not bring up networking when loaded over HTTP

[Lee Trager]

> Not sure if we want a feature to automatically scan/find grub.cfg on
remote host by ip/mac/uuid/etc:

Currently MAAS only specifies the path to the bootloader, not the
bootloader config. It expects the bootloader will automatically request
the config from where the bootloader was downloaded from. Right now that
is <server>/grub/grub.cfg. That file attempts to chainload
<server>/grub/grub.cfg-${net_default_mac} and if that fails
<server>/grub/grub.cfg-default-amd64. MAAS could also respond to
<server>/grub/grub.cfg-$uuid as we have that information as well. Having
grub do that automatically would remove a request and a level of
chainloading.

https://git.launchpad.net/maas/tree/src/provisioningserver/boot/uefi_amd64.py

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

Title:
  GRUB does not bring up networking when loaded over HTTP

Status in MAAS:
  Confirmed
Status in grub2 package in Ubuntu:
  New
Status in shim-signed package in Ubuntu:
  New

Bug description:
  When using MAAS to HTTP boot on x86_64 UEFI grub drops to the command
  line. net_ls_addr shows the system has no address. If I run net_dhcp I
  get an address. I can then download the remote grub.cfg file and
  continue boot.

  When reproducing with QEMU you have to manually reconfigure the boot
  order to try HTTP before TFTP:

  # efibootmgr -v
  BootCurrent: 0002
  Timeout: 0 seconds
  BootOrder: 0002,0003,0001,0000,0004
  Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
  Boot0001* UEFI QEMU QEMU HARDDISK 	PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/SCSI(1,1)N.....YM....R,Y.
  Boot0002* UEFI PXEv4 (MAC:00163E03BE1A)	PciRoot(0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/MAC(00163e03be1a,1)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.
  Boot0003* UEFI HTTPv4 (MAC:00163E03BE1A)	PciRoot(0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/MAC(00163e03be1a,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()N.....YM....R,Y.
  Boot0004* EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
  # efibootmgr -o 0003,0002,0001,0004
  BootCurrent: 0002
  Timeout: 0 seconds
  BootOrder: 0003,0002,0001,0004
  Boot0000* UiApp
  Boot0001* UEFI QEMU QEMU HARDDISK
  Boot0002* UEFI PXEv4 (MAC:00163E03BE1A)
  Boot0003* UEFI HTTPv4 (MAC:00163E03BE1A)
  Boot0004* EFI Internal Shell

  grub> net_ls_addr
  grub>
  grub> net_dhcp
  efinet0:dhcp 00:16:3e:03:be:1a 10.0.0.75
  grub> configfile (http,10.0.0.2:5248)/grub/grub.cfg-default-amd64
  Booting under MAAS direction...

  The kernel and initrd are downloaded but it hangs there.

  I believe the bug is in grub. As MAAS receives its bootloaders from
  the stream at images.maas.io generated by lp:maas-images this affects
  all versions of MAAS. Currently MAAS uses GRUB and the Shim from
  Bionic however I have been able to reproduce this bug using GRUB and
  the shim from Focal as well.

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