Confirming the version installed was the withdrawn shim SRU from trusty,
still installed in the xenial system.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1652147
Title:
UEFI secure boot fails
Timestamps are of no use since I did other modifications.
Ok, I think I now know what happened. I had proposed enabled in Trusty
(in my case to have those act as canaries for updates). So I got those
new versions of shim/shim-signed back then. And together with grub2 (or
maybe kernel) this was
On Thu, Jan 05, 2017 at 09:03:04AM -, Stefan Bader wrote:
> In sources.list on the laptop proposed is disabled now. I think I did
> not manually change this. So it seems that it got disabled during
> upgrade.
Check timestamps?
> Which would make sense with my second upgrade where I disabled
In sources.list on the laptop proposed is disabled now. I think I did
not manually change this. So it seems that it got disabled during
upgrade. Which would make sense with my second upgrade where I disabled
proposed manually before the release upgrade. The weird thing is anyway
where those
On Tue, Jan 03, 2017 at 05:19:24PM -, Brian Murray wrote:
> ubuntu-release-upgrade should disable -proposed to prevent situations
> like this. Please include your the file /var/log/dist-upgrade/main.log
> which should contain information about your upgrade from 14.04 to 16.04.
>
>
ubuntu-release-upgrade should disable -proposed to prevent situations
like this. Please include your the file /var/log/dist-upgrade/main.log
which should contain information about your upgrade from 14.04 to 16.04.
DistUpgradeController.py contains the following code:
653 # Disable
Would it not be really nice if update-manager would then disable
proposed before that? Also I just did another upgrade and had disabled
proposed *before*. Still I end up with the same non-xenial versions of
shim and shim-signed.
** Changed in: shim (Ubuntu)
Status: Invalid => New
--
You
dist-upgrading with -proposed enabled gives unsupportable results as it
pulls in all packages that have not yet completed SRU verification. See
also https://lists.ubuntu.com/archives/ubuntu-
release/2016-October/003950.html ff.
** Changed in: shim (Ubuntu)
Status: New => Invalid
--
You
Looks like the sbverify command failing is not relevant. Retrying to boot with
secure boot enabled in BIOS _after_ I downgraded shim/shim-signed to the
versions that are in the archive for Xenial(updates pocket) was successful and
brought up mok manager once, allowing to again disable secure
** Package changed: 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/1652147
Title:
UEFI secure boot fails after 14.04 to 16.04 upgrade
To manage notifications about this bug
Thank you for taking the time to report this bug and helping to make
Ubuntu better. It seems that your bug report is not filed about a
specific source package though, rather it is just filed against Ubuntu
in general. It is important that bug reports be filed about source
packages so that people
Oh, one thing to add: looking at the versions of shim and shim-signed,
those were beyond the versions for Xenial, rather Yakkety. Maybe because
of proposed being enabled before (it is turned off now after the
upgrade. I manually downgraded both now to Xenial(updates), still
sbverify fails with the
12 matches
Mail list logo
