On a current MAAS 2.0 installation, I've discovered that MAAS is now overriding the PXE-boot settings, causing the system to attempt to boot directly from the grubx64.efi on the hard disk's EFI System Partition (ESP). After installation, the result looks like this:
Note that BootOrder specifies Boot0005 as the first option, causing the computer to attempt to boot from the hard disk rather than PXE-boot (any of the other Boot#### options on this computer). This causes at least two problems:
* If Secure Boot is enabled, the computer may fail to boot, because the "ubuntu" entry points
to grubx64.efi, not shimx64.efi. (If the computer silently falls past the SB failure, it
will boot; but on the Fujitsu system I tested, it displays a console message about the SB
failure that requires human interaction, and therefore hangs indefinitely in a MAAS
environment.)
* Re-deploying the node is impossible without manual intervention, because the system
will try to boot from the hard disk rather than PXE-booting under MAAS control.
This problem has occurred on a server running MAAS 2.0.0+bzr5189-0ubuntu1~16.04.1 (see below for detailed version information). Another server running MAAS 2.1.0+bzr5480-0ubuntu1~16.04.1 does NOT have the problem. I suspect the problem is with the ephemeral images, though, not the MAAS version per se. I'm attaching the log files from the MAAS 2.0 system as requested.
I've tested this with three systems: A Fujitsu RX2530M2R2, a Fujitsu RX2540M2R1, and an IBM x3650 M2. (The MAAS 2.1 server controlled an Intel NUC DC53427HYE.) The Fujitsu systems are new (to us), but the IBM has been in our possession for an extended period and has never exhibited this problem (except perhaps when bug #1311827 was current), so I'm confident this is a regression.
All tests involved deployments of Ubuntu 16.04. Most used the certification custom images (for 16.04.1), but I've verified the results on one system deploying the standard MAAS image for xenial.
MAAS version information:
rodsmith@weavile:~$ dpkg -l '*maas*'|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============================-==============================-============-==================================================
ii maas 2.0.0+bzr5189-0ubuntu1~16.04.1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cert-server 0.2.25-0~64~ubuntu16.04.1 all Ubuntu certification support files for MAAS server
ii maas-cli 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS client and command-line interface
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server common files
ii maas-dhcp 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS DHCP server
ii maas-dns 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS DNS server
ii maas-proxy 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS Caching Proxy
ii maas-rack-controller 2.0.0+bzr5189-0ubuntu1~16.04.1 all Rack Controller for MAAS
ii maas-region-api 2.0.0+bzr5189-0ubuntu1~16.04.1 all Region controller API service for MAAS
ii maas-region-controller 2.0.0+bzr5189-0ubuntu1~16.04.1 all Region Controller for MAAS
un maas-region-controller-min <none> <none> (no description available)
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-maas-provisioningserver <none> <none> (no description available)
ii python3-django-maas 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.0.0+bzr5189-0ubuntu1~16.04.1 all MAAS server provisioning libraries (Python 3)
This bug is a regression of bug #1311827.
On a current MAAS 2.0 installation, I've discovered that MAAS is now overriding the PXE-boot settings, causing the system to attempt to boot directly from the grubx64.efi on the hard disk's EFI System Partition (ESP). After installation, the result looks like this:
ubuntu@ oil-hatanaka: ~$ sudo efibootmgr 0002,0003, 0004
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0005,0001,
Boot0001* UEFI: IP4 ELX NIC Bus:Dev:Func 3:0:0 - Fujitsu DynamicLoM Emulex OCl14000-LOM
Boot0002* UEFI: IP6 ELX NIC Bus:Dev:Func 3:0:0 - Fujitsu DynamicLoM Emulex OCl14000-LOM
Boot0003* UEFI: IP4 ELX NIC Bus:Dev:Func 3:0:1 - Fujitsu DynamicLoM Emulex OCl14000-LOM
Boot0004* UEFI: IP6 ELX NIC Bus:Dev:Func 3:0:1 - Fujitsu DynamicLoM Emulex OCl14000-LOM
Boot0005* ubuntu
Note that BootOrder specifies Boot0005 as the first option, causing the computer to attempt to boot from the hard disk rather than PXE-boot (any of the other Boot#### options on this computer). This causes at least two problems:
* If Secure Boot is enabled, the computer may fail to boot, because the "ubuntu" entry points
to grubx64.efi, not shimx64.efi. (If the computer silently falls past the SB failure, it
will boot; but on the Fujitsu system I tested, it displays a console message about the SB
failure that requires human interaction, and therefore hangs indefinitely in a MAAS
environment.)
* Re-deploying the node is impossible without manual intervention, because the system
will try to boot from the hard disk rather than PXE-booting under MAAS control.
This problem has occurred on a server running MAAS 2.0.0+bzr5189- 0ubuntu1~ 16.04.1 (see below for detailed version information). Another server running MAAS 2.1.0+bzr5480- 0ubuntu1~ 16.04.1 does NOT have the problem. I suspect the problem is with the ephemeral images, though, not the MAAS version per se. I'm attaching the log files from the MAAS 2.0 system as requested.
I've tested this with three systems: A Fujitsu RX2530M2R2, a Fujitsu RX2540M2R1, and an IBM x3650 M2. (The MAAS 2.1 server controlled an Intel NUC DC53427HYE.) The Fujitsu systems are new (to us), but the IBM has been in our possession for an extended period and has never exhibited this problem (except perhaps when bug #1311827 was current), so I'm confident this is a regression.
All tests involved deployments of Ubuntu 16.04. Most used the certification custom images (for 16.04.1), but I've verified the results on one system deploying the standard MAAS image for xenial.
MAAS version information:
rodsmith@weavile:~$ dpkg -l '*maas*'|cat Unknown/ Install/ Remove/ Purge/Hold Not/Inst/ Conf-files/ Unpacked/ halF-conf/ Half-inst/ trig-aWait/ Trig-pend /Reinst- required (Status,Err: uppercase=bad) ======= ======= ======= ======= -====== ======= ======= ======= ===-=== ======= ==-==== ======= ======= ======= ======= ======= ======= ==== 0ubuntu1~ 16.04.1 all "Metal as a Service" is a physical cloud and IPAM 0~64~ubuntu16. 04.1 all Ubuntu certification support files for MAAS server 0ubuntu1~ 16.04.1 all MAAS client and command-line interface controller <none> <none> (no description available) 0ubuntu1~ 16.04.1 all MAAS server common files 0ubuntu1~ 16.04.1 all MAAS DHCP server 0ubuntu1~ 16.04.1 all MAAS DNS server 0ubuntu1~ 16.04.1 all MAAS Caching Proxy controller 2.0.0+bzr5189- 0ubuntu1~ 16.04.1 all Rack Controller for MAAS 0ubuntu1~ 16.04.1 all Region controller API service for MAAS controller 2.0.0+bzr5189- 0ubuntu1~ 16.04.1 all Region Controller for MAAS controller- min <none> <none> (no description available) maas-provisioni ngserver <none> <none> (no description available) 0ubuntu1~ 16.04.1 all MAAS server Django web framework (Python 3) 0ubuntu1~ 16.04.1 all MAAS python API client (Python 3) maas-provisioni ngserver 2.0.0+bzr5189- 0ubuntu1~ 16.04.1 all MAAS server provisioning libraries (Python 3)
Desired=
| Status=
|/ Err?=(none)
||/ Name Version Architecture Description
+++-===
ii maas 2.0.0+bzr5189-
ii maas-cert-server 0.2.25-
ii maas-cli 2.0.0+bzr5189-
un maas-cluster-
ii maas-common 2.0.0+bzr5189-
ii maas-dhcp 2.0.0+bzr5189-
ii maas-dns 2.0.0+bzr5189-
ii maas-proxy 2.0.0+bzr5189-
ii maas-rack-
ii maas-region-api 2.0.0+bzr5189-
ii maas-region-
un maas-region-
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-
ii python3-django-maas 2.0.0+bzr5189-
ii python3-maas-client 2.0.0+bzr5189-
ii python3-