UEFI testcases needed

Bug #1738833 reported by Walter Lapchynski on 2017-12-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Manual Tests
Walter Lapchynski

Bug Description

Currently there is no guarantee that images can boot in both UEFI and legacy modes, nor is there a guarantee that the installs can either. It seems the only resolution to this would be to double all of the testcases, but that seems insane. Still, something needs to be done.

Related branches

Kev Bowring (flocculant) wrote :

Not sure of the 'nitty-gritty' here but I would assume that if a machine installs ok UEFI using one option (for arguments sake the entire disk ) then would it not also install using other options?

Do we need (for example) to worry about the OEM install test? Up until quite recently few flavours used it (memory) - we only started using it during 17.04 cycle at Xubuntu. So assuming that Ubuntu weren't concerned should anyone else be?

If those assumptions are valid - then I'd say we just need to do 1 testcase for UEFI installs.

I'd agree that recreating the whole set against UEFI would be madness - not just the work involved in doing that, but also who would use them (currently Xubuntu wouldn't), would they even get results on the tracker - which to be honest is likely to not be much - just check recent results for everyone in the last few cycles - I'd be surprised if the total reports per test per milestone got to 50.

Walter Lapchynski (wxl) wrote :

I think those are appropriate assumptions. At the very least I don't
*KNOW* that there will be problems. That said, I think the best thing to
do would be to assume and let people file bugs if those assumptions
prove to be wrong.

That said, let's dig into the nitty gritty a bit. The thing we can't
guarantee is which boot manager a tester might use. On modern hardware,
it's probably true that UEFI is a safe assumption. However, at least in
VirtualBox, the default would be BIOS.

That said, I think the right thing would be to propose one testcase for
each boot manager. Something like:

 1. check boot manager is [bootmanager] - see [link to instructions]
 2. do normal install - see [link to regular testcase]

I think at least every flavor image would need one of these.

Does that seem reasonable?

Kev Bowring (flocculant) wrote :

We've already got testcases which do foo.

Suggest that we add 1 testcase to specifically test UEFI - that IIRC is the issue that caused this bug report in the first place.

As far as every flavour image goes - no, don't agree. 1 testcase, which those flavours wanting to specifically test UEFI can use.

Walter Lapchynski (wxl) wrote :

I'm with you on all points except that there should be one to specifically test both boot managers, since we don't know what we're testing otherwise.

… that is, unless the testcases specifically call it out.

Kev Bowring (flocculant) wrote :

My main point is that all of this has come around because someone had a problem with UEFI install, if that's the case - just make a UEFI one for flavours who want to use it.

The rest of us can carry on as we've been doing for cycles and cycles ... using the testcases as we've been doing.

Walter Lapchynski (wxl) wrote :

Well, I don't entirely agree, but if it's a problem, we'll discover it and fix it. I'll get to writing :)

Walter Lapchynski (wxl) wrote :

As I'm putting this together, a question comes to mind. There is two goals in mind, here:

 1. Ensure that the image can be booted with UEFI.
 2. Ensure that the resulting install is compatible with UEFI.

The 1st one is a no-brainer, but the 2nd one sort of suggests the inclusion of at least one of the testcases within the new testcase. It's the more important one, too, as it was a bug Lubuntu found in 17.10 post-release (☹) that inspired this movement. But I don't want to redouble efforts (include another testcase in a testcase) for obvious maintenance reasons. That said, I'm thinking something like:

 1. Ensure you're set to boot with UEFI.
 2. Boot the image -> should boot fine.
 3. Perform any install testcase -> reboot should work fine.

In our case, this would have failed in step 3 because the image lacked the necessary bits to finish the installation so as to be UEFI compatible, even though the booting worked fine.

To be fair, though, this was only the case in offline mode. If it was online, it would grab the updates and all would be well. So maybe ensuring it's in offline mode would be best?

I know, maybe I should write it and we should deal with this in the merge proposal, but hey, why not be proactive, right? ☺

Kev Bowring (flocculant) wrote :

That makes sense - the 1,2,3 - that's how the other installs are tested.

If the issue only occurs when offline, then that's what should get tested I'd assume.

Maybe we're in danger of overthinking this ... all we should be testing is does uefi install properly, maybe offline

Shouldn't really be any more complicated than any of the other iso install testcases imo

Kev Bowring (flocculant) on 2017-12-25
Changed in ubuntu-manual-tests:
assignee: nobody → Walter Lapchynski (wxl)
importance: Undecided → Medium
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers