/e/ OS “easy” installer: development thread about adding new devices

I’m not aware that you can run the IDE as normal user and then start/debug the installer as root.
Looks like the entire IDE needs to be run as root/with sudo.

1 Like

Yes that helped, i can debug now. Are you able to debug without root? The behavior on Elementary OS is that the tool starts way to big and then just hangs. When running as root no problem.

Seems to be an issue with the Elementary OS. The reason why the easy-installer was delayed for a day was we tested it on Elementary OS and the display was too large - no buttons showed up. Running as root solved the display problem there. Did not face the same issue with ubuntu OS though.

1 Like

/e/ OS Installer - 12 Linux-Derivate

Arch Linux · CentOS · Debian · elementary OS · Fedora · KDE Neon · Kubuntu · Manjaro · Linux Mint · openSUSE · Red Hat Enterprise Linux · Ubuntu

one Wind°ws Edition

Even though Wind°ws is not popular here, I would like to advance the /e/ OS installer for Wind°ws host machines.

1 Like

The whole point of releasing the easy-installer code to the community was to get more developers involved in modifying and improving the code. With more OS’s and devices integrated and tested with the code base it will truly live up to its name as a easy-installer.

1 Like

I can totally understand that and would also want to work on getting it running on windows later but time is limited.

And please, please,everyone, stop posting “unrelated” things in the topics that are actually trying to get things done :wink:
Or at least stick to existing topics like /e/ OS "easy" installer: how to help packaging it to MacOS and Windows when it’s about Windows support for the installer.

2 Likes

I’m just going step through the Java code and edit where needed to be able to debug the device specific scripts. For the first command “adb devices” i just made this change.

Edit: Found a better way to fix all path’s, change getRootPath() method. You would have to put scripts dir there also.

You not entirely wrong. Please forgive me for disturbing your circles.

Yeah, as a last resort that would have been my workaround, too.

But I was wondering how the /e/ devs did it, maybe there is something clever.

In the end I would want a solution that

  • works for both: execution in an IDE and in the distribution package
  • works out of the box without having to change the code (changing a local configuration file that will not be packaged is fine by me, too)
1 Like

BTW, I found a second reason why I would lock the bootloader at the end when adding the FP3 support: if the bootloader is unlocked, the FP3 shows a warning screen at each boot (I guess also after each OTA update) that might look frightening for the average user.

2 Likes

that’s a good reason

isn’t locking the bootloader also safer Re banking apps etc?

1 Like

I’ve just opened a new issue https://gitlab.e.foundation/e/backlog/-/issues/1307 because the FP3 does not use “heimdall” for the OEM unlocking step (or better: it doesn’t use “heimdall” at all).

And I’ve updated the issue https://gitlab.e.foundation/e/backlog/-/issues/1276 about running the installer in an IDE so that it is possible to do it without any manual changes to the build file or file locations.

:slight_smile: looks like we were too focused on the Samsung devices while writing the code.

1 Like

I solved this issue this way. I think one universal script to flash all will be to complex. I suggest to prefix device specific scripts. This way developers will not break other device code. For leeco the prefix would be le_s2_ww.

2 Likes

Today I pushed my work-in-progress for the FP3 to the /e/ gitlab instance.

Basically one has to do the following things

  • create two config files (YAML format)
    • one to call the actual flashing scripts with the right parameters
    • a second one to customize the screens with instructions and error messages matching the steps in the first file
  • add scripts to do the actual flashing if necessary

I’ve done that and tested the flashing scripts manually. Now I’m in the process of testing them as part of the installer.

At the moment I’m faced with one problem:
The currently supported Samsung models are flashed by a combination of download and recovery mode, but for the FP3 it’s done in fastboot mode all the time.
That means for now the step to flash the partitions starts too soon. It checks that the device is in fastboot mode, but it is always in fastboot mode after the OEM unlock step, even if the user has not confirmed the unlocking yet. That way the installer already starts flashing while the bootloader is still locked.

Two possible solutions come to mind

  • force the user to click ‘continue’ in the UI instead of continuing as soon as the correct mode is found
  • make the second time the phone is checked for fastboot mode also wait until the state of the bootloader is ‘unlocked’

I’ll keep a list of detailed todos at

Edit: went for option 2 and added a new script to check if the unlocking was successful. Currently pushed version ran successfully from my IDE and flashed the FP3. But the phone had /e/ on it already. Should probably test by first flashing the stock ROM again to both slots.

3 Likes

Currently I’m stuck again where I want to test the packaged installer with added FP3 support.

I’ve run ./gradlew dist which creates build/distributions/easyInstaller-linux-x64.zip

When I unzip that archive and run easy-installer from the bin subdirectory, the installer comes up and I can proceed to the screen where my FP3 gets detected.
But then the ‘Continue’ button is greyed out and the console shows an error:

Exception in thread "JavaFX Application Thread" java.lang.IllegalAccessError: class org.yaml.snakeyaml.TypeDescription (in module Easy.installer.merged.module) cannot access class java.util.logging.Logger (in module java.logging) because module Easy.installer.merged.module does not read module java.logging
        at Easy.installer.merged.module/org.yaml.snakeyaml.TypeDescription.<clinit>(Unknown Source)
        at Easy.installer.merged.module/org.yaml.snakeyaml.constructor.Constructor.<init>(Unknown Source)
        at Easy.installer.merged.module/org.yaml.snakeyaml.constructor.Constructor.<init>(Unknown Source)
        at Easy.installer.merged.module/org.yaml.snakeyaml.Yaml.<init>(Unknown Source)
        at ecorp.easy.installer/ecorp.easy.installer.threads.ThreadFactory.loadYAMLFile(Unknown Source)
        at ecorp.easy.installer/ecorp.easy.installer.threads.ThreadFactory.changeMould(Unknown Source)
        at ecorp.easy.installer/ecorp.easy.installer.controllers.MainWindowController.setDevice(Unknown Source)
        at ecorp.easy.installer/ecorp.easy.installer.controllers.subcontrollers.DeviceDetectedController.lambda$startDetection$0(Unknown Source)
        at javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(Unknown Source)
        at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(Unknown Source)
        at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
        at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
        at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
        at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
        at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(Unknown Source)
        at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(Unknown Source)
        at javafx.base/javafx.event.Event.fireEvent(Unknown Source)
        at javafx.graphics/javafx.concurrent.EventHelper.fireEvent(Unknown Source)
        at javafx.graphics/javafx.concurrent.Task.fireEvent(Unknown Source)
        at javafx.graphics/javafx.concurrent.Task.setState(Unknown Source)
        at javafx.graphics/javafx.concurrent.Task$TaskCallable.lambda$call$1(Unknown Source)
        at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(Unknown Source)
        at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(Unknown Source)
        at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
        at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)

I’m not familiar with the Java module concept. It seems I need to grant access to module java.logging for module org.yaml.snakeyaml (or for the entire bundled application?).
But I don’t know how to do that. My naive though was to try something like

opens java.logging to org.yaml.snakeyaml;

in module-info.java, but that gives an error:

> Task :compileJava
/x01/user/ingo/FP3/eelo/easy-installer/src/main/java/module-info.java:32: warning: package is empty or does not exist: java.logging
    opens java.logging to org.yaml.snakeyaml;
              ^

Any idea how to fix this?

Edit: Not sure if that is a good solution, but it works when I add mergedModule setting as below in build.gradle:

jlink {
    imageZip = project.file("${buildDir}/distributions/${appPackaging}.zip")
    options = ['--strip-debug', '--compress', '2', '--no-header-files', '--no-man-pages']
    mergedModule {
        requires "java.logging"
    }
    [...]
}

Unfortunately then the next error is when wiping the user data with fastboot -w:

/x01/user/ingo/FP3/eelo/linux-installer/bin/adb/mke2fs failed with status 1

fastboot: error: Cannot generate image for userdata

So I also need to package mke2fs.

I now have a working alpha version for the FP3 support :slight_smile:

No binary package yet, but in order to test it on Linux, you can try this (needs a working Java Development Kit)

  1. Download the sources: https://gitlab.e.foundation/Ingo-FP-Angel/easy-installer/-/archive/fp3/easy-installer-fp3.zip
  2. Unzip the sources to a folder of your liking; let’s assume /tmp/easy-installer-source
  3. Open a terminal and execute the following commands
    cd /tmp/easy-installer-source
    ./gradlew dist
    
  4. The last command creates a binary package /tmp/easy-installer-source/build/distributions/easyInstaller-linux-x64.zip; unzip that to a new folder; let’s assume /tmp/easy-installer-linux-x64
  5. In the terminal from step 3 run the installer by executing
    /tmp/easy-installer-linux-x64/bin/easy-installer
    
  6. Follow the steps in the installer UI

By running the installer from the command line you can see some debug output as it progresses. That might be helpful in case there is a poblem.

Things that still need to be done, known problems and a few ideas for future improvements at: https://gitlab.e.foundation/Ingo-FP-Angel/easy-installer/-/blob/fp3/TODO_FP3.md

Edit: if anyone wants to skip steps 1 to 3, I have uploaded the binary package to my e.cloud storage at https://ecloud.global/s/QLxnQj49iHKxtQz

5 Likes

Hi @Ingo_FP_Angel I am sorry I missed your call for help, as I am interested in this tool too, to ease /e/OS installation by Commown’s customers themselves. I just built and launched it successfully, but still need some time to try it. If you already see some work / review / fr t10n I could do, I’d be glad to help. Just to let you know, my java knowledge is completely out of date but as an experienced python dev I might be of some help.

Hi @fcayre, I think at this point in time it might not even be necessary to touch the java codebase. The design of the installer is such that adding a new device would mainly require just editing config files or batch scripts.

Right now I’d say the best ways to help are

  • testing my changes with an FP3
    • “works for me”; but I’ve done the flashing manually and with my version of the installer so many times, I might overlook problems others might be having
  • testing my changes with the initially supported Samsung models
    • sure, I don’t think I’ve touched any parts that could break the initial functionality of the installer, but I don’t have a Samsung device I could use to verify that assumption
    • ideally someone with both an FP3 and a supported Samsung model would test to identify what screenshots/images need to be created for the FP3 (I’ve never seen the screens of a successful installation on Samsung phones; so I’m not 100% sure how it’s supposed to look for the user)
  • finding out how to actually create a snap package and then testing that

I’ve encountered a problem. The locale object is used to determine what file should be used to display instructions, and images (instructions folder). In my case i’m implementing leeco s2. The device id is “le_s2_ww”. Resource bundle does not accept underscores or numbers in variation field of the locale object, it throws an exception. Futher AppConstants.DEVICE_MODEL is never assigned, it is null. I have this proposal to fix the problem: (i’ll make merge request when gitlab is up again).