Ubuntu Studio 22.04.1 and Secure Boot

[Aaron Rainbolt]

On Tue, Aug 2, 2022 at 12:39 PM Erich Eickmeyer <eeickmeyer at ubuntu.com> wrote:
>
> On Tuesday, August 2, 2022 10:16:53 AM PDT Simon Quigley wrote:
> > As for why this is coming up *now* in the first place, I don't have the
> > slightest clue. In the year 2022, flavors need to at least smoke test
> > *once*, *especially* for an LTS release, to ensure Secure Boot works.
> > Look, I get it, flavor teams may be short-staffed, some more than
> > others, but we really need to take a look at our QA processes as the
> > Ubuntu project to ensure something basic like this is caught in every
> > flavor. (Yes, I'm volunteering to write the ISO QA tests.) It's
> > embarrassing, as a fellow Ubuntu Flavor RM, that something like this was
> > not caught and brought to the attention of the Release Team
> > *immediately*. This isn't personal, I'm not trying to roast anyone in
> > particular, but come on everyone, we really need to do better here. I'll
> > link Lubuntu's thorough test suite here[2], and I would suggest other
> > flavors take our example.
> >
> [snip]
> > [1]
> > https://git.launchpad.net/livecd-rootfs/tree/live-build/auto/config#n132
> > [2] https://phab.lubuntu.me/w/release-team/testing-checklist/
> >
>
> This happened partially because of the transition from Xfce to KDE Plasma back
> in 2020 and the subsequent transition from Ubiquity to Calamares since
> Ubiquity's KDE modules are hard-coded for Kubuntu's branding. Ubiquity has the
> necessary facility to handle interfacing with mokutils and creating a MOK,
> whereas Calamares does not, and this was missed during the Ubuntu Studio
> testing.  And yes, your analysis of Ubuntu Studio lacking the manpower and
> resources to test every scenario of installation is correct. We're just not
> popular enough to attract the willing participants to want to help test.
>
> Additionally, I tested on real hardware. I was unaware, until recently, that
> my own hardware that I was testing on did not have secure boot enabled. This
> was a mistake on my part and I own this mistake.
>
> However, I will say that Calamares not having a facility for MOK is quite a
> shortcoming and also prevents the installation of drivers such as Nvidia
> drivers, which is something that Ubiquity can do. This makes other installers,
> such as Ubiquity and even the new flutter-based installer more attractive all
> the time for use cases like Ubuntu Studio, where advanced graphics processing
> is paramount for video production, photography, and graphics design. This,
> however, is a digression and probably worthy of a separate discussion.
>
> --
> Erich Eickmeyer
> Project Leader - Ubuntu Studio
> Member - Ubuntu Community Council--

As an avid user of both Ubuntu Studio and Lubuntu, I will be more than
happy to help with the testing process for Ubuntu Studio in the
future. I have the necessary hardware to do so painlessly, and we can
just do a full Ubuntu Studio installation test any time something
happens with Calamares that would warrant a Lubuntu installation test.

In case it would be helpful for future testing, I would like to point
out a new testing tool I discovered. It may work to reduce our testing
workload immensely, for Ubuntu Studio, Lubuntu, and possibly even the
larger Ubuntu ecosystem.

The tool is called openQA. Quoting from the description of its package
in the Ubuntu universe repository:

> openQA is a testing framework that allows you to run tests on pretty-much
> anything that you can get 'remote' control of (most often, anything you can run
> in a VM and point VNC at). This allows testing of things including GUI
> applications, system boot-up (BIOS, bootloaders, kernels), installers and whole
> operating systems.
>
> Tests (using Perl syntax) generally consist mostly of sequences of code like:
>   assert_and_click 'some_icon';
>   assert_screen 'some_prompt';
>   send_key 'ret';
> which are run using the os-autoinst test engine, by a worker. The tags named in
> scripts can then be associated with 'needles' (elements of screenshots) via the
> webUI (either from past tests, or while controlling a live test). Other testing
> possibilities include: serial-connected headless systems, multi-host networked
> tests, and non-VM 'real' systems.

I would like to suggest that we take a look at this tool and see if it
will help us. We're spending days of our time just testing the
installation procedure for our flavours - being able to automate away
a large portion of that work may be a huge benefit, especially in time
crunches like the one we're under now. And it might help us catch bugs
like this more easily in the future.

Hopefully this is helpful. Thank you all for all the work you put into
this system, and thank you for letting me contribute!

Sincerely,
Aaron Rainbolt
Newbie Lubuntu developer-in-training