A dev progress update on ubuntu desktop provisioning

Hello everyone,

In this post I’ll provide a progress update on our move from installation to provisioning and where we’re making adjustments to meet feature freeze. Features missed this cycle will likely be deferred to the 24.10 cycle but it’s too early to commit either way. For variants interested in adopting the new experience read on :rocket:

The plan and things to be aware of

  • You can find the code for all stages in canonical/ubuntu-desktop-provision and our working branch is main.
  • From this we will build two snaps: ubuntu-desktop-bootstrap (Stage 3) and ubuntu-desktop-init (Stages 4 and 5). For the eager, you can find these in Launchpad here.
  • The interface’s look and feel is driven by whitelabel.yaml. Full schema to follow, but with this you can replace images, adjust titles, customise the slideshow, toggle some screens on or off (e.g. the EULA in Stage 4), and so forth. We’ll start simple and then grow as requirements evolve.
  • If you need help or want to file an issue you can do so against the Launchpad project or the GitHub project.
  • We plan to archive ubuntu-desktop-installer and ubuntu-flavor-installer once it’s safe to do so.

Getting started

A complete step-by-step guide is difficult because variants all have nuances. So, rather than attempting that and failing miserably, below is a general guide for Ubuntu Desktop which will hopefully serve as a blueprint for everyone else. If you bump into challenges do reach on #desktop-dev:ubuntu.com so we can work through them together.

  1. Add snap:ubuntu-desktop-bootstrap/classic in your live seed. We haven’t switched yet so the link shows the old installer still.
  2. Include a whitelabel.yaml and associated assets on the live cd. We recommend that you package these as part of your variants settings package (e.g. ubuntu-settings).
  3. Point your systemd unit’s ExecStart to the new binary (i.e. Ubuntu Desktop here in the livecd-rootfs package or Ubuntu Studio here in their ubuntustudio-default-settings package).
  4. Test and iterate.

Some additional notes

  • We won’t land ubuntu-desktop-init before feature freeze because the bar for main inclusion is high and time is tight.
  • So, we will keep user creation in Stage 3 and not offer Stage 4 for classic or flavours.
  • The theme and accent colour picker are not in Stage 3. Let us know if you have a strong opinion on this.
  • We aim to land Stage 3 in the dailies sometime wc 5 Feb 24.
  • Because our OEM team has more flexibility on package inclusion we will continue maturing Stage 4 for inclusion in their experience.

And that’s it!

Kind regards,

Tim

3 Likes

Hi TIm,

Just some thoughts and questions to clarify some confusion on my end from a flavors standpoint since that’s where I’m coming from and I believe I speak for all flavors when I write this.

I mean, I’m all for the fallacy of sunk cost, but does this mean that we’re no longer depending on the ubuntu-flavor-installer framework in the very, very near future? This means that all the work we’ve all just done is all-for-not and it would’ve been nice to know this ahead of time. I guess either way this got us ready for what’s coming, so there’s the silver lining.

Looking at whitelabel.yaml, it looks fairly incomplete in terms of documentation as to what can be done with it. For instance, with the Edubuntu installer I was able to, using the flutter layout, uniquely make the layout exactly the way it was, or at least as close as it was, with Ubiquity.

Furthermore, where in the file structure would you recommend these assets go? I guess somewhere in /usr/share but then it gets muddy from there.

Can you provide some context? What is this?

In this case, it’s a good thing Kubuntu chose to go with Calamares because this would be a huge blocker for them as they have an OEM partner (and my former employer) that depends on this functionality.

I’m going to have to say this might be a branding issue. For Ubuntu Studio, we use Blue. For Edubuntu, we’re going with Purple. For Xubuntu, they use Blue. I’m fairly certain Ubuntu Budgie also uses Blue. If Ubuntu MATE chooses to use this (we haven’t heard a peep from them), they’ll likely want to use Green. See where the problem is? We can’t be sticking Orange everywhere. This is, of course, if I’m understanding what you mean here correctly.

I hope this all helps. I know you are looking at things specifically through the lens of Ubuntu Desktop since that’s your world, so I hope that I can lend a perspective through the lens of the flavors.

Best,
Erich

For the encryption is it going to be guiding people towards FDE? If so; do you have a plan to fix the various FDE bugs first? These are the ones I hit:
https://github.com/canonical/ubuntu-desktop-installer/issues/2371
https://github.com/canonical/firmware-updater/issues/236
https://github.com/fwupd/fwupd/issues/6264
This one was also reported:
https://github.com/canonical/firmware-updater/issues/236

@superm1

I’m putting my discourse moderator hat on with this one and not speaking as a flavor lead.

It doesn’t appear as though what you’re addressing is within the scope of this conversation and is somewhat off-topic. I looked at those links, and those issues look like they’re being addressed inside those issues and should not be brought to this particular conversation as that’s not what this conversation is addressing.

Therefore, I ask that you would please stick to the items that @tim-hm is addressing in his original post and not deviate.

Thanks.

1 Like

My apologies. I saw the screenshots in the links above and thought it was a dev focused topic. Carry on!

1 Like

It is a dev focused topic, but is mostly focused on provisioning for the flavors aside from Ubuntu Desktop, so Kubuntu, Lubuntu, Xubuntu, Edubuntu, Lubuntu, Ubuntu Studio, Ubuntu MATE, Ubuntu Budgie, Ubuntu Kylin, and Ubuntu Cinnamon.

2 Likes

@eeickmeyer:

I mean, I’m all for the fallacy of sunk cost, but does this mean that we’re no longer depending on the ubuntu-flavor-installer framework in the very, very near future? This means that all the work we’ve all just done is all-for-not and it would’ve been nice to know this ahead of time. I guess either way this got us ready for what’s coming, so there’s the silver lining.

The ubuntu-flavour-installer uses ubuntu-desktop-provision as a git submodule. So, if you’ve made ubuntu-flavour-installer work, and provided you haven’t customised massively, then it should be straightforward to migrate.

@eeickmeyer:

Looking at whitelabel.yaml, it looks fairly incomplete in terms of documentation as to what can be done with it.

As I mentioned above, the format should come out later this week and we’re open to comments to make sure it meets flavour requirements. However, for this iteration we didn’t plan on supporting custom layouts due to resource constraints. With regard to asset location but the working assumption is that will look something like this:

/usr/share/desktop-provision/
  /assets/
  /slides/
  /eula/ # oem only
  - whitelabel.yaml

@eeickmeyer:

Can you provide some context? What is this?

I assume you’re referring to ubuntu-desktop-init, if so, this is essentially a replacement for gnome-initial-setup and our support for an OEM/OOBE. Read about Stages 4 and 5 here .

With regard to using your flavours accent colours, we expect that to be set in whitelabel.yaml. I was specifically referring to the screen in the installer where the end user could set a dark/light theme and accent color for the default desktop.

Hope that helps!

1 Like

I have a personal desire to make TPM backed FDE the default if the machine supports it, but as you pointed out, there’s a lot we need to address before we’re ready to revisit that. I can’t imagine it happening in the near future.

1 Like

So, that tells me that we won’t have our slideshows as set-up in slides.dart with the previous version? I’m not sure how I feel about this if true.

Let me chat with the team and see if we can accomodate. Will come back to you this week.

3 Likes