installation of third party codecs enabled in UI although subiquity goes for offline install

Olivier,
You just moved my bug here for failed 23.04. I replied to the email but don't think it went to you. Am I still able to use the installation since it let's me log in or should I try to reinstall and not select "Use 3rd Party...."?

Tim

Hello Timothy,

I did see your comment and replied to it :)

> Hello Timothy,
>
> I think it's safe to use this install. You will need to manually install the ubuntu-restricted-addons package if you want the third-party codecs to be installed. You can install the package using the following command, for instance:
> $ apt install ubuntu-restricted-addons
>
> If you would like to redo the installation though, you should be able to work around the issue by either:
> * connecting to your network / Wi-Fi _before_ reaching the screen that shows the `Download and install support for additional media formats` checkbox.
> * leave the checkbox unchecked and install the package manually after the installation.
>
> Hope this helps!
> Olivier

Thanks,
Olivier

Thanks. I wasn't sure as I saw that it went through a no-reply@ email.
I'll see how it performs and if need be reinstall it. I have 2 systems that have installation errors and won't allow me to update them so I'm just wiping them and reinstalling. One of the systems has been hanging on since 16.04. I'm hoping this system install will work smoothly and upgrade normally.
I appreciate your help.

Tim

> On 04/25/2023 1:32 PM Olivier Gayot <email address hidden> wrote:
>
>
> Hello Timothy,
>
> I did see your comment and replied to it :)
>
>
> > Hello Timothy,
> >
> > I think it's safe to use this install. You will need to manually install the ubuntu-restricted-addons package if you want the third-party codecs to be installed. You can install the package using the following command, for instance:
> > $ apt install ubuntu-restricted-addons
> >
> > If you would like to redo the installation though, you should be able to work around the issue by either:
> > * connecting to your network / Wi-Fi _before_ reaching the screen that shows the `Download and install support for additional media formats` checkbox.
> > * leave the checkbox unchecked and install the package manually after the installation.
> >
> > Hope this helps!
> > Olivier
>
> Thanks,
> Olivier
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (2017683).
> https://bugs.launchpad.net/bugs/2017278
>
> Title:
> installation of third party codecs enabled in UI although subiquity
> goes for offline install
>
> Status in subiquity:
> New
> Status in ubuntu-desktop-installer:
> New
>
> Bug description:
> We have had multiple private reports of failed installation with the
> following error:
>
> [[...], system-install', '-t', '/target', '--download-only', '--',
> 'ubuntu-restricted-addons']' returned non-zero exit status 100.
>
> Based on the logs files gathered, this seems to happen if:
> * the installation of third-party codes is enabled
> * subiquity decided to go for an offline install (i.e., no default route was present when the network model got configured).
>
> This is an inconsistency between the desktop installer and subiquity
> that we need to address.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/subiquity/+bug/2017278/+subscriptions

Possible changes:

## Making the desktop installer mark the network model configured again after a user connects to a network.
As long as Subiquity reevaluates the status of the network (but see below), it should update has_network accordingly.

Downsides:

 * When Subiquity evaluates the status of the network, it ignores temporary routes that NM spawned to test the connection (they have metric >= 20000). Consequently, evaluating the status of the network immediately after a user connects to a network using NM will likely cause Subiquity to treat the network as down.
 * Marking the network model configured does not make Subiquity automatically reevaluate the status. Only probert events do. There is no guarantee how long it would take for a new event to occur - although it is expected to be quite fast.

## Making the desktop installer mark the network model configured again after a user connects to a network + tell subiquity if we're online or not.

Downsides:

* It delegates the knowledge of the network status to the desktop installer.

## Marking the network model configured later in the process (e.g., after selecting the storage)

This is probably the simplest approach at the moment.

Downsides:

* Not really a long term solution. Currently, the desktop installer does not explicitly request mirror testing - which is something we would want it to do going forward. Because it is not explicitly requested, mirror testing will happen automatically at a later stage, during the installation. Explicitly requesting mirror testing earlier would help figure out if the connection is setup properly - and will provide the ability to failover to an offline install if needed.
Mirror testing does not run until the network model is configured.

A fix was merged in ubuntu-desktop-installer this week:

https://github.com/canonical/ubuntu-desktop-provision/pull/131

@ogayot - I see that the pull request was merged into a mantic branch - I don't see it in the main nor in the dev branch.

Hence I think that's why none of the mantic branch stuff dependabot hasnt picked up and merged into the ubuntu-flavor-installer nor ubuntu-budgie-installer.

Why hasnt the 14 commits been merged into dev/main to allow the flavour installer(s) to benefit?

@fossfreedom - Yes, when I noticed the presence of deb822 sources in your other bug report, I raised a similar concern.

I will let the desktop installer people find the right way to address the gap and come back to you.

Thanks,
Olivier

@fossfreedom @ogayot we've just finished reconciling the mess of branches/git submodules so these changes are now in the 'main' branch from ubuntu-desktop-installer -> ubuntu-desktop-provision -> subiquity_client.

subiquity_client will continue to track subiquity:ubuntu/mantic as my current understanding is that is where fixes will land for subiquity.

https://github.com/canonical/subiquity/pull/1812 should affect this bug as well.