Offline mode: ability to flash from local images with Easy Installer

Community Easy Installer
1

Hi!

@LePoissonLibre and I are planning a flash party at the beginning of April 2023.
We will have Internet access, but probably not enough bandwidth and/or mobile data plan to download many images.
However, as we will know the device models before D-day, we should be able to download them beforehand, and have them locally.

I did not see an option of Easy Installer to take a local file instead of downloading it. Is it possible?

If not, an alternative might be to be able to configure some kind of mirror of the download server (that we might setup locally)
I see that the download URL is in each device_fs.yaml (from src/main/resources/yaml · master · e / devices / Easy Installer · GitLab). At worst, I suppose we could change these URLs to the ones of a local HTTP mirror? Would it be necessary to recompile the software, or could we inject the yaml files in the java classpath, for example?

Of course, it’s always possible to flash through command-lines (without the Easy-Installer), but Easy-Installer is clearly easier & safer.

1 Like
2

Hi,

As Easy-Installer uses java.net.HttpURLConnection for downloads, I’d try with something like GitHub - abhinavsingh/proxy.py: ⚡ Fast • 🪶 Lightweight • 0️⃣ Dependency • 🔌 Pluggable • 😈 TLS interception • 🔒 DNS-over-HTTPS • 🔥 Poor Man's VPN • ⏪ Reverse & ⏩ Forward • 👮🏿 "Proxy Server" framework • 🌐 "Web Server" framework • ➵ ➶ ➷ ➠ "PubSub" framework • 👷 "Work" acceptor & executor framework with adding proxy configuration to the Easy-Installer launch script (Java Networking and Proxies).

3

This would be a great improvement for sure. It sounds similar to how the Windows Device Recovery Tool handles things for HoloLens and Windows Phone/Mobile.

Images that aren’t stored and hashed locally are fetched when a device is connected, and local copy is always used unless invalid or outdated.

4

Implementing this kind of HTTP proxy might work but would need to implement TLS interception too. And thus we would also need to add our own SSL certificate in the JVM certificate store. It’s probably feasible, but not straight-forward.

But I thought about another simpler idea.
Today, I flashed a FP3 with Easy-Installer, with the same computer I used a few days ago for another FP3. And it re-used the already-downloaded image file (it did not download it again)
So maybe we could simply put the relevant files in the directory it expects to find them. On Linux, it seems to be ~/snap/easy-installer/common/sources/
It found file ~/snap/easy-installer/common/sources/FP3/IMG-e-latest-r-FP3.zip . It looks like it downloaded again only its checksum ~/snap/easy-installer/common/sources/FP3/IMG-e-latest-r-FP3.zip.sha256sum, and checked it. Which is an acceptable compromise in my case: I still needs an Internet access, but it would download only small files.

I suppose we can guess the expected directory and file name from src/main/resources/yaml · master · e / devices / Easy Installer · GitLab : it’s probably the ones at the end of the sources.rom.url of the device_fs.yml

I unfortunately don’t have any more device to test that

1 Like
5

You’re totally right, I missed it when reading the code!
If the file exists, has the right length & modification timestamp, it may not be downloaded again: src/main/java/ecorp/easy/installer/tasks/DownloadTask.java · master · e / devices / Easy Installer · GitLab.
So you could download manually all files, just before going to the party.
Hopefully the Murena Team won’t publish a new version while you’re at the party…
As a side note, as I can see all URL are …latest…, so this is probably a link/redirect which may change of size and timestamp, without changing name.

1 Like
6

Thanks for the pointer to the code @smu44
I agree, it should work.

Based on how the timestamp is used as an “If-Range” HTTP request header, we should simply take care that the last-modified dates of our local images are kept (it should be the timestamp when they have been downloaded).
And yes, we should download/update the images shortly before the flash party, and rename them accordingly if necessary

2 Likes
7

there’s an installer (in its infancy) that does offer a “choose file” dialog for image and recovery, so might fit your use case?

By the time of your flash party it should have more devices but it is close to parity already. It’s rom agnostic, but by default targets lineage. Expect more bugs as it is new

I found it when searching for installers to contribute to. It’s under active development with funding for a few more months. It’s flutter+python based where easyinstaller is java+shell. Conceptually they’re very similar: yaml per device + generalized steps + predefined scripts per device when necessary.

2 Likes
8

Just to give some feedback on this:

We have successfully applied this strategy this week-end.
We had downloaded the images before the flash-party, and Easy-Installer recognized them: it checked their checksum and installed them on the devices (skipping the download delay)

To preserve the timestamp, I simply used wget to download the images (using the URLs from the yaml source files), and have put them in the expected directories. No need to rename them.
I could even make a .tar.gz of this “sources” directory to transfer it to another computer.

4 Likes