correct third workaround with example

Author: ebeahan

docs/release-notes/known-issues.md

@@ -236,8 +236,15 @@ Possible workaround require access on the hosts to unlock the situation:
 
 1. Define temporarily [`HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY` env variables](https://www.elastic.co/docs/reference/fleet/host-proxy-env-vars) on the Elastic Agent service - then restart Elastic Agent. **ATTENTION:** you will need to provide a correct `NO_PROXY` value in order to force Elastic Agent to use the proxy ONLY when accessing the URL of the artifacts, otherwise it will affect ANY HTTP communication to go through the proxy. Then restart the Elastic Agent and re-attempt the upgrade.
 
-Temporarily grant access to the public Artifacts repository (or the self-hosted one) without the need of the HTTP proxy. This might imply updating firewalls or host settings.
+2. Temporarily grant access to the public Artifacts repository (or the self-hosted one) without the need of the HTTP proxy. This might imply updating firewalls or host settings.
 
-Re-install Elastic Agent downloading the file locally via other methods. Note: this implies a re-enrollment & re-installation, losing the local state and therefore triggering possible re-ingestion of data.
+3. Re-install Elastic Agent downloading the file locally via other methods. You can download the agent upgrade `.zip` or
+`.tar.gz` along with the `.sha512` and `.asc` files and use the upgrade command with a `file://` URI to upgrade from
+local disk.
+
+```shell
+# --force is needed for fleet managed agents
+sudo elastic-agent upgrade 9.1.7 --force --source-uri file:///path/to/files
+```
 
 :::