** Changed in: maas
Milestone: 3.5.0 => 3.5.0-beta1
** Changed in: maas
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/1865515
Title:
Chainbooting
lower priority in oem-priority since no activity
** Changed in: oem-priority
Importance: Critical => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub
Upon further testing I was able to confirm Dimitri's suspicion that the
-no-reboot option in LXD is causing the SecureBoot failures. I have
reported this to LXD[1] and will work to resolve that separately. I am
able to get SecureBoot working when using libvirt with signed OVMF using
That _is_ the kernel, well, its EFI stub.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To manage
I just tried retesting with grub-efi-
amd64-signed_1.169+2.04-1ubuntu45_amd64.deb and shim-
signed_1.47+15.4-0ubuntu2_amd64.deb from Impish. I made sure those
versions of GRUB and the shim were served by MAAS and that they were
both used in the local deployed environment. During testing I added
I am concerned about the -no-reboot option, and what constitutes a
"reboot".
Because chainloader; exit 1; boot linux => all can look like reboots
depending what qemu is monitoring/trapping. As all of those things start
brand new EFI application via LoadImage2 call.
--
You received this bug
Can you please try to have the installed machine booting without 'quiet'
and with 'earlyprintk=efi' ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the
ltrager - the secure-boot.log ends with
"EFI stub: UEFI Secure Boot is enabled."
Which is the first message from the loaded linux kernel. At this point
grub & shim have all succeeded, no?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I'm using the default LXD settings, attached is qemu.conf.
** Attachment added: "qemu.conf"
https://bugs.launchpad.net/maas/+bug/1865515/+attachment/5489916/+files/qemu.conf
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I was told that the latest SHIM/GRUB from Hirsute may have fixed this
issue. It looks like chain loading from network GRUB to local GRUB works
but the VM turns off when it tries to start the kernel. Attached is GRUB
output with debug="all"
My test setup is as follows:
grub over the network and
> shim-signed is won't fix.
No, it absolutely is not.
The behavior of shim is WRONG and MUST be fixed; we've previously
idenitfied that this affects not only cross-distro chainloading, it also
impacts chainloading from the removable disk shim to
\EFI\ubuntu\shimx64.efi via fallback.efi on
shim-signed is won't fix.
but separately, we are working on making maas use grub from focal to
make "secureboot deployment with maas just work"
** Changed in: shim-signed (Ubuntu)
Status: Triaged => Won't Fix
** Changed in: shim-signed (Ubuntu Groovy)
Status: Triaged => Won't Fix
** Changed in: maas
Milestone: 2.9.2 => 2.9.x
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
I believe grub2 - 2.04-1ubuntu26.8 is causing an issue with deploying a
server using MAAS 2.9.1. See
https://bugs.launchpad.net/grub/+bug/1898550.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
This bug was fixed in the package grub2 - 2.04-1ubuntu26.8
---
grub2 (2.04-1ubuntu26.8) focal; urgency=medium
* debian/patches/grub-install-backup-and-restore.patch: Fix-up the patch
to correctly initialyze the names of the modules to restore. LP:
#1907085
*
This bug was fixed in the package grub2 - 2.04-1ubuntu35.2
---
grub2 (2.04-1ubuntu35.2) groovy; urgency=medium
* debian/patches/grub-install-backup-and-restore.patch: Fix-up the patch
to correctly initialyze the names of the modules to restore. LP:
#1907085
*
Ok, so I think we should release the grub2 parts even though they do not fix
the ultimate problem (since as mentioned, this is unfixable via grub). Let's
leave the shim task open to indicate that this is still something that will be
addressed.
Thanks!
--
You received this bug notification
There is a plan for fixing shim upstream, it's possible. But the way
it's being planned, I'm not sure we'll see it this year.
** Changed in: shim-signed (Ubuntu)
Status: Invalid => Triaged
** Changed in: shim-signed (Ubuntu Focal)
Status: Invalid => Triaged
** Changed in:
@rodsmith
That's not helpful, as that's now blocking grub2 release staged for the
point release. Despite this bug report being used to introduce `exit 1`
support, which this bug report now provides for focal.
Chainloading will not work, and will never be possible to fix. Thus yes,
MAAS bug
I'm the original bug reporter, and in that context (of MAAS
deployments), this fix does nothing helpful -- it literally does not
change the original observed problem in any way. Thus, I'm marking this
verification-failed-focal. (I've not tested under other Ubuntu
versions.)
** Tags added:
Rod, yes the chain loading will still fail, the solution that works as
Dimitri pointed out is to exit 1, which these SRUs backport to stable
releases. Did you read the test case?
Shim chain loading can't be fixed in grub. And shims we can't touch
right now, also upstream does not really consider
I may have installed it incorrectly, but what I've got is not working.
It boots fine with Secure Boot disabled, but it shuts down with the same
message about a compromised system as the stock GRUB. What I did to
test:
1) Installed grub-efi-amd64-signed (version
1.142.10+2.04-1ubuntu26.8)
2)
1.155.2+2.04-1ubuntu35.2 and 1.142.10+2.04-1ubuntu26.8 were sideloaded
onto MAAS to deploy Ubuntu Focal with secureboot on as part of
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1911439
verification.
** Tags removed: verification-needed verification-needed-focal
Hello Rod, or anyone else affected,
Accepted grub2 into groovy-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/grub2/2.04-1ubuntu35.2
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
** Description changed:
- MAAS (2.4.2 and 2.6.2) cannot deploy to a server with Secure Boot
- active. This appears to be a regression of bug #1711203; the symptoms
- are identical. Namely:
+ [Impact]
+
+ * UEFI Grub currently doesn't support exiting with an unsuccessful exit
+ code. That means,
We're in a bit of a bind here, even if we do fix LP:1906379 and
LP:1910600 there is no way for MAAS to fix existing deployments. Meaning
unilaterally using "exit 1" will break existing deployments which users
will have to manually fix.
Is it at all possible to create a grub.cfg which can detect
I've now verified the proposed `exit 1` menu entry, and i can
successfully boot via maas in secureboot mode.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over
There is no other way to deploy with secureboot, without modifying the
deployed OS shim.
Thus either we fix above two bugs as well, or those targets will not
have secureboot and continue to use chainloading.
Requirements for secureboot are:
* create valid uefi boot entries
* do not delete them
*
Using "exit 1" to to chainboot breaks if there is no UEFI boot entry.
MAAS currently has two known bugs where this is the case. There may be
more, we need to test all operating systems MAAS supports.
LP:1906379 - Ubuntu is removing the UEFI boot entry during shutdown for CentOS.
LP:1910600 - MAAS
** Changed in: oem-priority
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
I can use grub from hirsute, to boot into Ubuntu's grub, then execute
`exit 1` to fallback to the next BootOrder bootentry and boot into
centos8 with Secureboot on.
Meaning the chain of events is Ubuntu's Shim => Ubuntu's grub => exit 1
=> Centos Shim => Centos Grub => complete boot, and bootctl
** Changed in: grub2 (Ubuntu)
Status: Triaged => Fix Released
** Changed in: grub2 (Ubuntu Focal)
Status: New => Triaged
** Changed in: shim-signed (Ubuntu)
Status: Triaged => Invalid
** Changed in: shim-signed (Ubuntu Focal)
Status: New => Invalid
** Changed in:
** 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/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To manage notifications about
** Changed in: oem-priority
Assignee: (unassigned) => ethan.hsieh (ethan.hsieh)
** Changed in: oem-priority
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** 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/1865515
Title:
Chainbooting from grub over the network to local shim breaks
This is not a problem we can fix on our side. It is an upstream shim
problem. Every distribution you want to boot will need a fixed shim, and
it's not a priority right now, given that we have a moratorium on new
shims being signed.
We have the ability to secure boot Ubuntu already, by not
There is no movement and there will be no movement for some more months
at least.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim
Has there been any movement on this? We get asked about Secure Boot in
MAAS periodically by various hardware partners.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from
** Changed in: maas
Milestone: 2.9.0b7 => 2.9.x
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
** Changed in: maas
Milestone: 2.9.0b4 => 2.9.0b7
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
** Tags added: fr-24
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To manage notifications about this
** Changed in: maas
Status: Confirmed => Triaged
** Changed in: maas
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub
** Changed in: maas
Milestone: 2.9.0b2 => 2.9.0b3
** Changed in: maas
Milestone: 2.9.0b3 => 2.9.0b4
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over
I'll try to implement one last hack, and maybe that works, and is
acceptable enough that everyone picks it this year. We'll see. It's a
bit unfortunate the issue is in the second shim failing to unload the
first shim, as otherwise, we'd only need a fixed maas shim :/
--
You received this bug
As a workaround, MAAS may for the time being, chainload
EFI/ubuntu/grubx64.efi when the goal is to securely boot Ubuntu systems.
Secure boot for other systems will require work on those other systems,
once we have the patches available upstream, and is hopefully ready by
21.04, but other distros
** Changed in: shim
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
** Bug watch added: github.com/rhboot/shim/issues #221
https://github.com/rhboot/shim/issues/221
** Also affects: shim via
https://github.com/rhboot/shim/issues/221
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Further analysis today suggests the issue is that shim never uninstalls
the old shim protocols, and then things get weird. Patching shim to call
to the parent shim to uninstall itself, rather than falsely attempting
to uninstall it ourselves, makes it work, but it's just a hack so far.
We can
On Thu, Sep 10, 2020 at 05:23:14PM -, Lee Trager wrote:
> Secure boot must work for every operating system MAAS supports, not just
> Ubuntu.
Chainloading to shim instead of directly to grub is mandatory /even/ for
Ubuntu because it is not guaranteed over time that the shim in the MAAS
stream
MAAS tries to do
(FW) -> shim(net) -> grub(net) -> shim(local) -> grub(local)
When grub(net) runs MAAS send it this[1] config which searches for the
local bootloader as we don't know where it is. It prefers chainloading
the shim but will fall back on grub if that isn't found.
The reason we
The problem seems to be caused by having two shims, as we get the
"Bootloader has not verified loaded image" messages when loading this
way, but if we instead chainload the local grub directly, things work.
So it seems like local shim does not correctly uninstall and replace
remote shim protocol
On Thu, Sep 10, 2020 at 01:59:14PM -, Dimitri John Ledkov wrote:
> So what is the order of boot?
> (FW) -> grubnet -> shim (local) -> grub (local) ? I don't think that
> would work, given that grubnet doesn't know how to validate shim,
> without shim protocol installed.
> I thought the chain
So what is the order of boot?
(FW) -> grubnet -> shim (local) -> grub (local) ? I don't think that
would work, given that grubnet doesn't know how to validate shim,
without shim protocol installed.
I thought the chain must be (FW) -> shim -> grubnet -> shim (local) ->
grub (local). But I'm not
I could reproduce this by modifying my shim netboot testing script in
bug 1862171 to add a local hard disk to the VM, and then run chainloader
(hd0,gpt1)/efi/ubuntu/shimx64.efi, and boot; which successfully loads
grub, but kernel then reports it is compromised.
--
You received this bug
** Changed in: maas
Milestone: 2.9.0b1 => 2.9.0b2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
** Also affects: grub2 (Ubuntu Groovy)
Importance: Undecided
Status: Triaged
** Also affects: shim-signed (Ubuntu Groovy)
Importance: Undecided
Status: Triaged
** Also affects: grub2 (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: shim-signed
** Tags added: maas-grub
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To manage notifications about
** Changed in: maas
Milestone: 2.8.0 => 2.9.0b1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
By default an LXD VM boots from the disk first. However you can change
the boot order by adding "boot.priority" to your devices. The device
with the highest number boots first.
LXD devices config for booting off the boot disk.
devices:
eth0:
name: eth0
nictype: bridged
parent: br0
** Tags added: id-5ee24d297b5c2a5aa43fda04
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To manage
Can you elaborate on this step? "6. Modify LXD VM to boot from over the
network"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim
** Package changed: grub (Ubuntu) => grub2 (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
** Changed in: maas
Milestone: 2.8.0rc3 => 2.8.0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
** Changed in: maas
Milestone: 2.8.0rc1 => 2.8.0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
All bootloader files are pulled from the archive and provided on
images.maas.io by lp:maas-images. bootloaders.yaml describes what files
are pulled from what packages.
https://git.launchpad.net/maas-images/tree/conf/bootloaders.yaml
--
You received this bug notification because you are a member
The MAAS environment I've been using to reproduce this is virtual. I
have MAAS running in an LXD container connected to an LXD Pod. To
recreate this environment you'll have to install MAAS 2.8, python-pylxd
from github(if using the Debian packages), and apply this[1] patch to
reenable secure boot.
I'm just wondering where Maas is getting the grubx64.efi from, I
assume/hope it's the grubnetx64.efi binary built by the grub package.
Because the bug might be in there.
Anyway, this should be enough to investigate further and sounds somewhat
familiar too
** Changed in: shim-signed (Ubuntu)
As I said, the EFI/foo/grubx64.efi is taken from MAAS. It's presumably
netboot-enabled, but can't seem to find its config file, hence the need
for the manual entry in steps 9-11. Note that I'm not a MAAS developer,
so my understanding of its internals is limited.
--
You received this bug
I don't see a netboot in there, am I missing something?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
The grubx64.efi from #3 is probably a grubnetx64.efi?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
I've managed to create a procedure that duplicates this problem without
the involvement of MAAS, except for one file pulled from MAAS. The
procedure is awkward, but it reproduces the problem. Here's the
procedure:
1) Ensure that Secure Boot is enabled.
2) Install Ubuntu. (I used 20.04 LTS
Consider that we might need to upgrade grub on the MAAS server, and need
to test this on bionic, focal, groovy on both maas server and deployed
server sides.
e.g. we might need to test deploying a groovy server from a bionic MAAS,
and vice versa, and other combinations of this.
--
You received
Well, quite simply we'd like a minimal test case without involving maas,
so that we can test this in a sensible way. This is also important for
SRUs, as we need to test them before releasing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Unfortunately, capella in 1SS is not currently accessible by our team.
You can test on jehan in 18T, though; I'm sending you an e-mail with
details.
I don't know what you mean by "remote artifacts" and "local artifacts."
The steps to reproduce the problem is simply to enable Secure Boot and
Please provide remote artifacts
Please provide local artifacts
Please provide reproducer steps
Please provide details how local artifacts were installed
Please provide list of certs trusted by the node's firmware
Please provide access to MAAS with a secureboot on & off target nodes
** Changed in:
Can I have access to said MAAS environment and those machines?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
I tried modifying the MAAS local boot grub.cfg to directly chainboot
\efi\ubuntu\shimx64.efi. This gets rid of the failed to open/failed to
load errors. Local grub appears to load but halts saying the system is
compromised when it tries to boot the local kernel.
--
You received this bug
MAAS doesn't know for sure what operating system is deployed locally.
When booting locally MAAS sends a grub.cfg[1] which searches for the
shim or local bootloader. MAAS first tries \efi\boot\bootx64.efi as that
is the default location as per the UEFI spec. Most operating systems
including Ubuntu
On Tue, May 19, 2020 at 08:59:46PM -, Lee Trager wrote:
> Based on the MAAS logs the halt happens after the remote shim, grub, and
> grub.cfg have been loaded. I didn't see anything in the console to show
> grub running but it may have been cleared before I could see it.
> Console output:
>
Based on the MAAS logs the halt happens after the remote shim, grub, and
grub.cfg have been loaded. I didn't see anything in the console to show
grub running but it may have been cleared before I could see it.
Console output:
Booting local disk...
Failed to open \efi\boot\grubx64.efi - Not Found
On Tue, May 19, 2020 at 04:15:47PM -, Lee Trager wrote:
> I suspect but haven't verified that this may be due to the shim
> not being signed with a key GRUB has.
GRUB embeds no keys, it calls out to shim for verification of
signatures.
It would be helpful if someone could verify whether the
@Jeff MAAS uses the same bits as what the ISO uses. What is different is
how local booting happens with MAAS vs with the ISO. When installed with
the ISO the local boot process is UEFI Firmware -> Shim(from disk) ->
GRUB(from disk) -> Boot local kernel. When installed with MAAS the local
boot
** Tags added: rls-ff-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To manage notifications
FWIW, a partner is also hitting this in the field when trying to do
Secure Boot installs which break 100% of the time for them.
They have noted, however, that installing from ISO works and can
successfully install and boot on a secure boot enabled server. They've
only tested Focal ISOs at this
** Tags added: rls-bb-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To manage notifications
For LXD Pods[1] we had to disable secure boot to get around this issue.
When this bug is fixed we should reenable secure boot for LXD Pods.
[1]
https://git.launchpad.net/maas/tree/src/provisioningserver/drivers/pod/lxd.py#n515
--
You received this bug notification because you are a member of
86 matches
Mail list logo
