** Tags added: oem-priority
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications about this bug go to:
https://bugs.launchp
** Also affects: oem-priority
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notificati
Hi,
I know this bug was gone for a while, but now there are my findings
which may be a regression:
Test environment:
MAAS version: 2.5.0 (7442-gdf68e30a5-0ubuntu1~18.04.1)
1. Dell G3 3590 laptop with secure boot enabled
Deploying 18.04 from MAAS => Got the same error as bug described.
Deploying
Shim 15+ includes the fix for this chainloading trick; you should now be
able to chainload from:
tftp shim -> tftp grub -> disk shim -> disk grub
That shim 15+ version is in cosmic for now; pending more investigation
into the relocation bug that was identified in bionic.
** Changed in: shim (Ubu
The SRU of shim 15+ has been rolled back from bionic-updates while we
investigate this issue.
** Tags added: regression-update
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deploymen
Sorry, commenting on the wrong bug - this bug is obviously older than
the most recent SRU-induced problem.
** Tags removed: regression-update
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Tit
** Changed in: dellserver
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications about thi
** Changed in: maas
Status: Fix Committed => Fix Released
** Changed in: maas
Milestone: 2.3.0 => None
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when
** Merge proposal linked:
https://code.launchpad.net/~mpontillo/maas/+git/maas/+merge/342242
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
** Changed in: maas/2.3
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications a
** Changed in: maas/2.3
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications ab
** Merge proposal linked:
https://code.launchpad.net/~andreserl/maas/+git/maas/+merge/339444
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
** Changed in: maas
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications about
Jeff,
The Cisco C-240 M4 (boldore) that originally produced this bug seems to
have been returned to OIL, so I can't test with it, at least not
quickly; however, I did just run a test with feebas, a Cisco C220 M4. I
was able to deploy Ubuntu 16.04 and boot it with Secure Boot enabled,
and verified
On Fri, Feb 23, 2018 at 01:13:42AM -, Andres Rodriguez wrote:
> > bladernr@critical-maas:/var/lib/maas/boot-resources/
> > current/bootloader/uefi/amd64$
> > ll
> > total 2328
> > drwxr-xr-x 2 maas maas4096 Feb 22 17:34 ./
> > drwxr-xr-x 4 maas maas4096 Feb 22 17:34 ../
> > -rw-r--r-- 2
On Thu, Feb 22, 2018 at 7:55 PM, Jeff Lane
wrote:
> On Thu, Feb 22, 2018 at 6:28 PM, Steve Langasek
> wrote:
> > On Thu, Feb 22, 2018 at 11:06:51PM -, Jeff Lane wrote:
> >> > Is /efi/ubuntu/grubx64.efi on your EFI System Partition definitely the
> >> > Canonical-signed image from grub-efi-am
FWIW, I did a bit of extra testing. I killed maas' rackd (which provides
PXE). Rebooted the machine and I saw:
1. It attempted to PXE boot multiple times (like a lot)
2. It eventually gave up and booted from disk
So it successfully booted into the deployed OS.
I noticed that the curtin installat
On Thu, Feb 22, 2018 at 6:28 PM, Steve Langasek
wrote:
> On Thu, Feb 22, 2018 at 11:06:51PM -, 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 s
This brings a good point. What I didn’t test, which will do tomorrow, is
what happens if I kill Maas and let the same system boot from disk. I
wonder if it will boot.
On Thu, Feb 22, 2018 at 6:20 PM Jeff Lane
wrote:
> > Is /efi/ubuntu/grubx64.efi on your EFI System Partition definitely the
> > C
On Thu, Feb 22, 2018 at 11:06:51PM -, 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:
> ubuntu@xwing:/boot/efi/EFI/ubuntu$ dpkg -S grubx64.efi
> grub-efi-amd64-s
> 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:
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's the
** Package changed: grub2 (Ubuntu) => shim (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications about this bug go
On Thu, Feb 22, 2018 at 08:45:17PM -, Jeff Lane wrote:
> Can we please verify that with one of the original failing systems
> (Cisco UCS C-240 M4) as well?
> Because that supermicro system works, my Lenovo fails even with the
> workaround (comments #48 and #49).
Is /efi/ubuntu/grubx64.efi on
The workaround in #36 is now working for me on my home network, too.
Perhaps when I tested it in December (comment #39) I had different
software versions; or maybe I didn't correctly reproduce the changes in
comment #36.
I did a diff on what you posted in #48, Jeff, and it exactly matches
what I'm
** Changed in: maas
Status: Triaged => In Progress
** Changed in: maas/2.3
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail
Can we please verify that with one of the original failing systems
(Cisco UCS C-240 M4) as well?
Because that supermicro system works, my Lenovo fails even with the
workaround (comments #48 and #49).
Unless I somehow mangled the workaround (see comment #48) and should re-
try with slightly differ
** Merge proposal linked:
https://code.launchpad.net/~andreserl/maas/+git/maas/+merge/338584
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
Ok, so I've tested the workaround in a supermicro system provided by the
cert team, and this is my evaluation:
1. Without the workaround on #36, the machine fails to deploy (e.g.
Using the shim fails and the machine powersoff)
2. With the work around on #36, the machine deploys successfully.
I'm
** Also affects: maas/2.3
Importance: Undecided
Status: New
** Changed in: maas/2.3
Milestone: None => 2.3.1
** Changed in: maas/2.3
Importance: Undecided => High
** Changed in: maas/2.3
Status: New => Triaged
** Changed in: maas/2.3
Assignee: (unassigned) => Andres
Now, at this point, I'm stuck unbooted on the initial post-deployment
reboot. So I reset the node by hand (poked the reset button) and
disabled SecureBoot in the config and rebooted it again.
This time, the node booted, pxe booted, got the edict to boot local, and
successfully booted locally.
If
MAAS version: 2.3.0 (6434-gd354690-0ubuntu1~16.04.1)
This is my observation on a Lenovo RS140 with workaround enabled from comment
#36:
Also, to be sure it's not something we've injected, I am using the default
curtin_userdata, NOT our customized cert one.
1: edit:
/usr/lib/python3/dist-package
So I've enabled secure boot on my Intel NUC's and have *not* used to
workaround in #36, and the machines deployed just fine (that is, they
pxe boot off MAAS and they are told to load the shim). The same scenario
is when using workaround in #36.
That said, the interesting bit is I remember testing
I'm at a loss to explain that. This works quite well in my netboot
testing when I remove MAAS from the equation. You *are* meant to be able
to chainload grub from another grub; and the reason why grub can't
chainload shim is that you then get the wrong set of shim protocols to
properly validate the
Mathieu, the workaround of chainloading GRUB rather than shim that you
suggested in comment #36 does not work; see my comment #39.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deploy
I have provided a workaround in comment #36, has this not been applied?
Landing a fix for this is going to take time, as it depends on a full
roundtrip of getting shim prepared, tested, and signed by Microsoft.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
and Xenial
** Attachment added: "grub-fail-xenial.log"
https://bugs.launchpad.net/maas/+bug/1711203/+attachment/5056017/+files/grub-fail-xenial.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/17
Just as an update, this is still an issue with Grub in Bionic...
** Attachment added: "grub-fail-bionic.log"
https://bugs.launchpad.net/maas/+bug/1711203/+attachment/5056013/+files/grub-fail-bionic.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
** Tags added: id-5a28802797729aedf99dcd37
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications about this bug go to:
https
Hi Matthieu,
Any update on this? I'm also getting reports on this same issue from
one of the hardware partners as well who is unable to deploy nodes and
perform cert testing while Secure Boot is enabled.
** Tags added: blocks-hwcert-server
--
You received this bug notification because you are
I also face this issue with nodes running on Hyper-V 2016 and enabled
Secure Boot (Microsoft UEFI cert.).
My node (with deployed Ubuntu 17.10) shows following warning:
---
Bootloader has not verified loaded image.
System is compromised. halting.
---
After a few seconds, the node powers off.
I'm
Andres,
I've checked that, and it does *NOT* fix the problem; the system fails
to boot after a deployment in exactly the same way it did before.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
@Rod,
Any chance you can test the work around of comment #36. You will need to
manually modify a file under:
/usr/lib/python3/dist-
packages/provisioningserver/templates/uefi/config.local.amd64.template
And then restart maas-regiond & maas-rackd.
Thanks!
--
You received this bug notification
Lee, I tried http://162.213.35.187/proposed/streams/v1/index.json
earlier, in response to Andres' suggestion, and that stream did not
help. (See comments #24 and #25.) If you think that stream has changed
since I did my testing on November 27, I'm happy to try again; but if
not, it doesn't help.
-
That's not going to change anything -- grub is doing exactly what it
should: ask shim to validate the image it tries to chainload; and the
image *does* validate successfully. The chain of trust is technically
preserved, but shim doesn't manage to make sense of things, and refuses
to continue loadin
While reading through #1730493 and #1437024 I noticed both had various
UEFI bootloader issues fixed by switching to the Artful version of grub
and the shim. I've updated
http://162.213.35.187/proposed/streams/v1/index.json to use boot loaders
from Artful in case anyone wants to test.
--
You recei
Yes, it's absolutely possible to recreate the environment for testing
this without MAAS -- there's nothing all that special to it,
chainloading *any* image should work and maintain a Secure Boot-verified
chain provided all the links in the chain validate images.
This looks to be pretty clearly a b
>From Andres, the grub.cfg used for chainloading to local disk is:
set default="0"
set timeout=0
menuentry 'Local' {
echo 'Booting local disk...'
search --set=root --file /efi/ubuntu/shimx64.efi
chainloader /efi/ubuntu/shimx64.efi
}
It should be possible to recreate an environment ou
As per Rod's comments, I'm re-opening the grub task.
** Changed in: maas-images
Status: Fix Committed => Fix Released
** Changed in: grub2 (Ubuntu)
Status: Won't Fix => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu
Reviewing @slangasek's notes
> It's worth checking whether this problem
> mysteriously resolves once linux-signed is being pulled in; if it does,
> then it's possible we have a bug in grub (enforcing signature when it's
> not supposed to) or simply a bug in firmware.
It would appear that despite
I'd just like to emphasize that, although a change to always install the
linux-signed kernel on AMD64 systems is necessary to fix this bug, it's
not sufficient to fix the bug. As noted in my comment #25 (and
elsewhere), another change is also required -- either a change to Shim
or GRUB (I don't kno
I've updated lp:maas-images to produce new images using the linux-signed
kernel on AMD64. New images are produced when http://cloud-
images.ubuntu.com/daily/ adds new images so it may take a few days for
signed kernels to appear in the stream. Unsupported releases are no
longer updated so we'll hav
** Changed in: maas-images
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications
Should we re-open the grub2 task then? or add a shim task?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications about this
So to clarify, MAAS pxe config searches & chainloads
/efi/ubuntu/shimx64.efi. It seems here the issue is with the shim. As
per Rod's comments:
"Changes to Shim/GRUB so that it works in this configuration. This used
to be the case, but the Shim/GRUB configuration has been tightening
security, which
Here's the install log, cut-and-pasted from the MAAS web UI, for the
latest installation. Note that after the node shut down, I restarted it
and disabled Secure Boot to get it to complete.
** Attachment added: "install-log.txt"
https://bugs.launchpad.net/maas/+bug/1711203/+attachment/5015350/+
** Changed in: maas
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications about this bug
I've tried this and the problem persists. Note that MAAS *IS* installing
the signed kernel, which is necessary but insufficient for a fix; the
problem seems to be that Shim/GRUB is becoming confused by the handoff
from the PXE-boot version of GRUB to the GRUB stored on the hard disk.
If my analysis
@Rod,
Can you retry this URL as a different images source:
http://162.213.35.187/proposed/streams/v1/index.json
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when S
Andres, I've downloaded that file, but I have no idea where to put it. I
can't find a file called index.json on my MAAS server.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deploymen
We have a test streams that uses the signed linux kernel instead of the
non-signed for x86. Can you please test it from this stream:
http://162.213.35.187/proposed/streams/v1/index.json
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Branch linked: lp:~ltrager/maas-images/maas_images_signed_kernel
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications ab
** Changed in: maas-images
Assignee: (unassigned) => Lee Trager (ltrager)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notif
To be clear, although installing the signed kernel package is necessary,
a failure to do this is NOT the source of this bug, which seems to
relate to how Shim and/or GRUB handle the MAAS boot path, which involves
Shim and GRUB being PXE-booted and then chainloaded to (Shim and?) GRUB
on the hard di
** Changed in: maas-images
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications abo
** Branch linked: lp:~andreserl/maas-images/maas_images_signed_kernel
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications
** Also affects: maas-images
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notificatio
** Changed in: maas-images
Status: New => Confirmed
** Changed in: maas-images
Importance: Undecided => High
** Changed in: maas-images
Importance: High => Critical
** Changed in: maas
Importance: Undecided => Critical
** Changed in: maas
Milestone: None => 2.3.0
--
You re
On Thu, Nov 16, 2017 at 09:53:18PM -, Ryan Harper wrote:
> No one in this thread has answered how MAAS or curtin
> knows that it should install the -signed version of linux-image.
It should *unconditionally* prefer the -signed version of linux-image.
--
You received this bug notification bec
No one in this thread has answered how MAAS or curtin
knows that it should install the -signed version of linux-image.
Once that knowledge is passed on, we can work out if curtin
can detect that or if maas can and specify which kernel package
to use.
On Thu, Nov 16, 2017 at 3:25 PM, Steve Langas
If maas+curtin are not installing the signed variant of the linux-image
package on UEFI systems, this is not invalid for maas+curtin - when we
rev the grub secureboot policy (ETA January), these systems will be
unbootable BY DESIGN. Regardless of whether this configuration has
tickled a regression
any updates on this issue?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1711203
Title:
Deployments fail when Secure Boot enabled
To manage notifications about this bug go to:
https://bugs.launchpa
Set the Grub2 task to High to grab attention (and because it's at least
a High, if not Critical, bug). My gut says this should be critical as
it's blocking the deployment of systems from multiple vendors in
multiple datacenter and lab environments anytime SecureBoot is enabled.
** Changed in: gru
I am facing similar issue at Dell site and all Dell servers are
exhibiting this behavior when secure boot is enabled.
** Also affects: dellserver
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Since 2.02-beta2-36ubuntu3.11 works but .12 (which is the latest in
Xenial updates doesn't) this seems to confirm the regression in grub.
marking invalid for NAAS and curtin!
Maas will automatically pick up a fixed grub once on the archive.
** Also affects: grub2 (Ubuntu)
Importance: Undecided
74 matches
Mail list logo
