On Thu, Feb 22, 2018 at 6:28 PM, Steve Langasek
<email address hidden> wrote:
> On Thu, Feb 22, 2018 at 11:06:51PM -0000, Jeff Lane wrote:
>> > Is /efi/ubuntu/grubx64.efi on your EFI System Partition definitely the
>> > Canonical-signed image from grub-efi-amd64-signed?
>
>> I presume so? dpkg says it is:They look the same to me:
>
>> ubuntu@xwing:/boot/efi/EFI/ubuntu$ dpkg -S grubx64.efi
>> grub-efi-amd64-signed: /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
>
> That doesn't establish that /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
> and /boot/efi/EFI/ubuntu/grubx64.efi match. Can you please verify that they
> do?
>> > Which version of Ubuntu's grub are you booting via pxe?
>
>> ubuntu@xwing:/boot/efi/EFI/ubuntu$ dpkg -l |grep grub|awk '{print $2": "$3}'
>> grub-common: 2.02~beta2-36ubuntu3.16
>> grub-efi-amd64: 2.02~beta2-36ubuntu3.16
>> grub-efi-amd64-bin: 2.02~beta2-36ubuntu3.16
>> grub-efi-amd64-signed: 1.66.16+2.02~beta2-36ubuntu3.16
>> grub-pc: 2.02~beta2-36ubuntu3.16
>> grub-pc-bin: 2.02~beta2-36ubuntu3.16
>> grub2-common: 2.02~beta2-36ubuntu3.16
>
>> That is what is installed on the node.
>
> Sorry, I was asking about the other end of this: what version of
> grubnetx64.efi is being served by maas?
I have no idea. Andres?
As far as I can tell, it's serving up a copy of grubx64.efi out of
/var/lib/maas/boot-resources/current
which has files dated Feb 5.
bladernr@critical-maas:/var/lib/maas/boot-resources/current/bootloader/uefi/amd64$
ll
total 2328
drwxr-xr-x 2 maas maas 4096 Feb 22 17:34 ./
drwxr-xr-x 4 maas maas 4096 Feb 22 17:34 ../
-rw-r--r-- 2 maas maas 1196736 Feb 5 07:29 bootx64.efi
-rw-r--r-- 2 maas maas 1173368 Feb 5 07:29 grubx64.efi
>
> (But it is also good to confirm what version of grub is installed on the
> node's disk.)
>
>> So I re-enabled SecureBoot and removed all NICs from the boot order. I
>> added in the HDD (since this is an EFI boot, the HDD is an entry called
>> "Ubuntu" under "OTHER" in the boot order)
>
>> This fails to boot, I get an error from the system:
>
>> Error 1962: No operating system found. Boot sequence will automatically
>> repeat.
>
>> Because I have no NICs listed in the boot order, this just churns as it
>> keeps retrying the HDD entry.
>
>> So next, I went back and disabled SecureBoot once more. It immediately
>> booted straight from the HDD.
>
>> I also just tried a USB install with Secure Boot enabled. I was able to
>> install bionic from USB, but it too fails to boot with the same error.
>
>> To be fair at this point, given that this does work elsewhere, I'm
>> suspicious that this is possibly an issue with my server.
>
> Agreed. Something is wrong with the boot configuration of this node, which
> is independent of the question of whether we have a viable workaround for
> the netboot chainloading bug.
I'm going to see if I can update the firmware on this node and maybe
that will make a difference. Otherwise, we'll need to try that C240
in the lab.
On Thu, Feb 22, 2018 at 6:28 PM, Steve Langasek grubx64. efi on your EFI System Partition definitely the amd64-signed? xwing:/ boot/efi/ EFI/ubuntu$ dpkg -S grubx64.efi amd64-signed: /usr/lib/ grub/x86_ 64-efi- signed/ grubx64. efi.signed grub/x86_ 64-efi- signed/ grubx64. efi.signed EFI/ubuntu/ grubx64. efi match. Can you please verify that they
<email address hidden> wrote:
> On Thu, Feb 22, 2018 at 11:06:51PM -0000, Jeff Lane wrote:
>> > Is /efi/ubuntu/
>> > Canonical-signed image from grub-efi-
>
>> I presume so? dpkg says it is:They look the same to me:
>
>> ubuntu@
>> grub-efi-
>
> That doesn't establish that /usr/lib/
> and /boot/efi/
> do?
Doh!... indeed. EFI/ubuntu/ grubx64. efi grub/x86_ 64-efi- signed/ grubx64. efi.signed 2129626683f12f3 b5 /boot/efi/ EFI/ubuntu/ grubx64. efi 2129626683f12f3 b5 grub/x86_ 64-efi- signed/ grubx64. efi.signed EFI/ubuntu/ grubx64. efi grub/x86_ 64-efi- signed/ grubx64. efi.signed EFI/ubuntu/ grubx64. efi and grub/x86_ 64-efi- signed/ grubx64. efi.signed are identical
ubuntu@xwing:~$ md5sum /boot/efi/
/usr/lib/
474a3900382e54c
474a3900382e54c
/usr/lib/
ubuntu@xwing:~$ diff -s /boot/efi/
/usr/lib/
Files /boot/efi/
/usr/lib/
>> > Which version of Ubuntu's grub are you booting via pxe? xwing:/ boot/efi/ EFI/ubuntu$ dpkg -l |grep grub|awk '{print $2": "$3}' 36ubuntu3. 16 36ubuntu3. 16 36ubuntu3. 16 amd64-signed: 1.66.16+ 2.02~beta2- 36ubuntu3. 16 36ubuntu3. 16 36ubuntu3. 16 36ubuntu3. 16
>
>> ubuntu@
>> grub-common: 2.02~beta2-
>> grub-efi-amd64: 2.02~beta2-
>> grub-efi-amd64-bin: 2.02~beta2-
>> grub-efi-
>> grub-pc: 2.02~beta2-
>> grub-pc-bin: 2.02~beta2-
>> grub2-common: 2.02~beta2-
>
>> That is what is installed on the node.
>
> Sorry, I was asking about the other end of this: what version of
> grubnetx64.efi is being served by maas?
I have no idea. Andres?
As far as I can tell, it's serving up a copy of grubx64.efi out of maas/boot- resources/ current
/var/lib/
which has files dated Feb 5.
bladernr@ critical- maas:/var/ lib/maas/ boot-resources/ current/ bootloader/ uefi/amd64$
ll
total 2328
drwxr-xr-x 2 maas maas 4096 Feb 22 17:34 ./
drwxr-xr-x 4 maas maas 4096 Feb 22 17:34 ../
-rw-r--r-- 2 maas maas 1196736 Feb 5 07:29 bootx64.efi
-rw-r--r-- 2 maas maas 1173368 Feb 5 07:29 grubx64.efi
That all comes from maas.io.
I presume its one of these?
http:// images. maas.io/ ephemeral- v3/daily/ streams/ v1/com. ubuntu. maas:daily: 1:bootloader- download. json
>
> (But it is also good to confirm what version of grub is installed on the
> node's disk.)
>
>> So I re-enabled SecureBoot and removed all NICs from the boot order. I
>> added in the HDD (since this is an EFI boot, the HDD is an entry called
>> "Ubuntu" under "OTHER" in the boot order)
>
>> This fails to boot, I get an error from the system:
>
>> Error 1962: No operating system found. Boot sequence will automatically
>> repeat.
>
>> Because I have no NICs listed in the boot order, this just churns as it
>> keeps retrying the HDD entry.
>
>> So next, I went back and disabled SecureBoot once more. It immediately
>> booted straight from the HDD.
>
>> I also just tried a USB install with Secure Boot enabled. I was able to
>> install bionic from USB, but it too fails to boot with the same error.
>
>> To be fair at this point, given that this does work elsewhere, I'm
>> suspicious that this is possibly an issue with my server.
>
> Agreed. Something is wrong with the boot configuration of this node, which
> is independent of the question of whether we have a viable workaround for
> the netboot chainloading bug.
I'm going to see if I can update the firmware on this node and maybe
that will make a difference. Otherwise, we'll need to try that C240
in the lab.