Trusty SRU - nova instances can't boot with 3.13.0-92

[Tim Gardner]

On 08/10/2016 10:10 AM, Kamal Mostafa wrote:
> On Tue, Aug 09, 2016 at 10:49:56AM -0600, Tim Gardner wrote:
>> On 08/09/2016 10:47 AM, Tim Gardner wrote:
>>> http://bugs.launchpad.net/bugs/1608854
>>>
>>> This backport is the result of an oversight made when applying UEFI
>>> patches to support signed module enforcement in a secure boot [...]
> 
>> The following changes since commit af29983bbae30cfaf4124879b50cb12e68a84195:
>>
>>   powerpc/tm: Always reclaim in start_thread() for exec() class syscalls (2016-07-29 09:15:59 -0700)
>>
>> are available in the git repository at:
>>
>>   git://kernel.ubuntu.com/rtg/ubuntu-trusty.git arm64-efi-lp1608854
>>
>> for you to fetch changes up to bfba7f3e1d73db181f52d58494f22cb43e0a2722:
>>
>>   UBUNTU: SAUCE: UEFI: Set EFI_SECURE_BOOT bit in x86_efi_facility (2016-08-09 09:39:34 -0600)
>>
>> ----------------------------------------------------------------
> 
> The 56 reverts (then re-applys) make sense in the context of "replace
> this whole huge patch set with a slightly different whole huge patch
> set", but may be confusing to somebody looking at the patches individually.
> The individual reverts do not mention why they're being reverted...
> 
> bbf4ccd x86/efi: Fix boot failure with EFI stub
> 28b55e2 Revert "x86/efi: Fix boot failure with EFI stub"
> d3788cd x86/efi: Fix boot failure with EFI stub
> 
> 633a14b x86/efi: Fix off-by-one bug in EFI Boot Services reservation
> adcd8d0 Revert "x86/efi: Fix off-by-one bug in EFI Boot Services reservation"
> 965918e x86/efi: Fix off-by-one bug in EFI Boot Services reservation
> 
> So ... How about?:
> 
> Squash all of the 56 reverts into one commit titled e.g. "UBUNTU: SAUCE:
> Back out UEFI secure boot changes to prepare for replacement", with a
> paragraph explaining why.  (Don't squash the re-applys).
> 
>  -Kamal
> 

Though the reverts don't have any commit comments other then the
Buglink, I did explain my method in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1608854/comments/17
which includes the rationale for the reverts.

Many of the reverts were stable commits, so having the list of reverts
also allows one to check that the relevant stable commits were re-added.

On the other hand, meh. I'm fine with squashing them into one commit.

rtg
-- 
Tim Gardner tim.gardner at canonical.com