On Wed, Oct 7, 2020 at 4:30 PM Ryan Harper <email address hidden> wrote:
>
> @Dann Thanks.
>
> Can you provide the log without your changes? Or at least the
> efibootmgr dump before curtin starts processing things?
Well nuts. I got access to the system again and added that debug, and
now the problem has vanished:
.. and the system deploys fine (w/o my workaround hack). I'm pretty
sure I've seen issues like this before with early UEFI dev boards -
probably just need to figure out the right set of circumstances to
recreate it. I'll keep poking at it.
On Wed, Oct 7, 2020 at 4:30 PM Ryan Harper <email address hidden> wrote:
>
> @Dann Thanks.
>
> Can you provide the log without your changes? Or at least the
> efibootmgr dump before curtin starts processing things?
Well nuts. I got access to the system again and added that debug, and
now the problem has vanished:
[ 188.557031] cloud-init[4885]: DANNF: 0002,0006, 0003,0001, 0000 afcc79a9- d867-481c- 8d98-fa0fb8c606 3c,0x800, 0x100000) /File(\ EFI\UBUNTU\ SHIMX64. EFI) 0x0)/Pci( 0x1,0x0) /Pci(0x0, 0x0)/MAC( 2c600c6fbb15, 1)/IPv4( 0.0.0.00. 0.0.0,0, 0)..BO
[ 188.557313] cloud-init[4885]: BootCurrent: 0002
[ 188.557631] cloud-init[4885]: Timeout: 5 seconds
[ 188.558379] cloud-init[4885]: BootOrder: 0004,0005,
[ 188.560161] cloud-init[4885]: Boot0000 ubuntu
HD(1,GPT,
[ 188.562671] cloud-init[4885]: Boot0002* UEFI: NIC1 IPv4 Quanta Dual
Port 10G BASE-T Mezzanine
PciRoot(
.. and the system deploys fine (w/o my workaround hack). I'm pretty
sure I've seen issues like this before with early UEFI dev boards -
probably just need to figure out the right set of circumstances to
recreate it. I'll keep poking at it.