Samsung - Galaxy S9 - starlte - Documentation Suggestions

Rebooting after flashing TWRP: I was supposed to reboot to recovery (twrp), but my only option was to reboot to system - no other reboot options, or power off, is possible at that point. However when that reboot to system happened, and I rebooted again to recovery, twrp was lost. So I flashed TWRP again, rebooted to system, but as soon as the screen turned off for reboot, immediately switched from Vol Down + Power (key combo to reboot to system) to Vol Up + Bixby + Power (key combo to boot to recovery). This worked, TWRP loaded, and the sun was shining again.

After installing s.th, TWRP presents yo a “reboot” button, but you can just ignore it and continue/go back to main menu. There you have access to all reboot options regularly. Maybe that was the point where you have been.

“Patch the device” section The no-verity thing was not going to happen, at all. Flashing any version failed with a red ERROR 1 line. I tried the linked no-verity thing samsung edition 1.0, the standard no-verity 6.1, 5.1, 4.1, all failed with the dreaded ERROR 1. I searched for solutions but nothing seemed to work. Then I stumbled upon this XDA thread , flashed it, and the console said success. Then I proceeded with the original install instructions.

I had also issues with this patch, but continued with the /e/ installation, and it is now running without problems. As far as I understand, the patch disables the forced encryption of user data at first boot, and doesn’t remove the ability to encrypt, correct?
Does this influence the ability of TWRP to decrypt user data? I have the experience, that TWRP isn’t able to mount the encrypted user data, when user data is not forcefully encrypted, but manually, is TWRP able to mount it then?

Like @legrec14 and @helicase and many others, for me installation of the patch no-verity-opt-encrypt-6.1.zip failed with error 1, but i proceeded to sideload /e/OS and it worked.
However at first boot I got the message “Wait while your phone is being encrypted”. I don’t know whether this is related and will come back to bite me later.
I installed TWRP 3.6.1 and e-0.22-q-20220226166118-dev-starlte.zip.

The main problem I see is that the installation guide doesn’t explain the purpose of any of the steps (not just this one) and users are supposed to just mimic along like monkeys without understanding anything. In my opinion, this only gives us enough rope to hang ourselves. It’s like handing over a loaded gun to untrained people.

Spreading /e/OS and privacy to the masses won’t succeed without some education. The /e/ Foundation should offer some basic, non-device-specific course on smartphone technology to explain the basic concepts and the essential terminology and should advice people to take it before trying installation.

1 Like

One more suggestion for improvement: instruct users to back up the stock Samsung ROM first of all things as soon as they have TWRP up and running before even attempting to install /e/OS. This way they have a safe fallback.

Shouldn’t the documentation link to where to find a Samsung Galaxy S9 official Android 10 system image ? I need one which, if I understand well, now serves as a “vendors file” and prerequisite to installing Q /e/ - but I fail to find the Samsung official source…

/e/ documentation provides this information

Samsung stock ROM
We downloaded the ROM from the sammobile site

on this page https://doc.e.foundation/pages/revert_samsung_to_stock_on_windows.

There are three other sources here

What is a stock ROM and how do I get one?

Thanks to both of you. I had not realized that it is normal in Androidland to get manufacturer binaries from third parties… To me Sammobile didn’t look legit. Oh well, I did get a “vendor file” from some file hosting service so I suppose it isn’t worse. This whole universe is a baroque throwback to the world of Windows shareware download sites circa 2000.

Now, I had supposed that installing the Samsung OS image was a job for TWRP but it actually uses heimdall and Download Mode. Does that mean that I have no choice but to step through manual PIT mapping ?

The “Revert Samsung” link above uses Windows and Odin3. If you use Heimdall/Linux be sure to study carefully the GUI or heimdall-frontend method; not very well documented.

Mostly Linux and BSD around here, except the Mandatory Corporate Windows Laptop which is out of bounds for our purposes. I suppose I’ll guinea pig an heimdall method then.

I mostly followed that method, with help from the following command to match partition names to the available files:

# ls -1 | sort | while read i; do grep -B 1 $i S9.pit; done
Partition Name: BOOT
Flash Filename: boot.img
Partition Name: CACHE
Flash Filename: cache.img
Partition Name: CM
Flash Filename: cm.bin
Partition Name: DQMDBG
Flash Filename: dqmdbg.img
Partition Name: HIDDEN
Flash Filename: hidden.img
Partition Name: KEYSTORAGE
Flash Filename: keystorage.bin
Partition Name: RADIO
Flash Filename: modem.bin
Partition Name: CP_DEBUG
Flash Filename: modem_debug.bin
Partition Name: ODM
Flash Filename: odm.img
Partition Name: OMR
Flash Filename: omr.img
Partition Name: PARAM
Flash Filename: param.bin
--
Partition Name: UP_PARAM
Flash Filename: up_param.bin
Partition Name: RECOVERY
Flash Filename: recovery.img
Partition Name: BOOTLOADER
Flash Filename: sboot.bin
Partition Name: SYSTEM
Flash Filename: system.img
Partition Name: UP_PARAM
Flash Filename: up_param.bin
Partition Name: USERDATA
Flash Filename: userdata.img
Partition Name: VENDOR
Flash Filename: vendor.img

And from that we get the meat of the heimdall command:

# ls -1 | sort | while read i; do grep -B 1 $i S9.pit; done | sed s/Partition\ Name:\ /--/g | sed s/Flash\ Filename:\ // | tr '\n' ' '
--BOOT boot.img --CACHE cache.img --CM cm.bin --DQMDBG dqmdbg.img --HIDDEN hidden.img --KEYSTORAGE keystorage.bin --RADIO modem.bin --CP_DEBUG modem_debug.bin --ODM odm.img --OMR omr.img --PARAM param.bin -- --UP_PARAM up_param.bin --RECOVERY recovery.img --BOOTLOADER sboot.bin --SYSTEM system.img --UP_PARAM up_param.bin --USERDATA userdata.img --VENDOR vendor.img

Room for improvement: “–UP_PARAM up_param.bin” appears twice, and a stray “–”

Good thing I built my own command: it contains two partitions and relevant files absent from the aforementioned method.

Soooo…

# heimdall flash --BOOT boot.img --CACHE cache.img --CM cm.bin --DQMDBG dqmdbg.img --HIDDEN hidden.img --KEYSTORAGE keystorage.bin --RADIO modem.bin --CP_DEBUG modem_debug.bin --ODM odm.img --OMR omr.img --PARAM param.bin --RECOVERY recovery.img --BOOTLOADER sboot.bin --SYSTEM system.img --UP_PARAM up_param.bin --USERDATA userdata.img --VENDOR vendor.img
Heimdall v1.4.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...

Initialising protocol...
Protocol initialisation successful.

Beginning session...

Some devices may take up to 2 minutes to respond.
Please be patient!

Session begun.

Downloading device's PIT file...
PIT file download successful.

Uploading BOOT
100%
BOOT upload successful

Uploading CACHE
100%
CACHE upload successful

Uploading CM
100%
CM upload successful

Uploading DQMDBG
100%
DQMDBG upload successful

Uploading HIDDEN
100%
HIDDEN upload successful

Uploading KEYSTORAGE
100%
KEYSTORAGE upload successful

Uploading RADIO
72%
ERROR: Failed to send file part packet!
ERROR: RADIO upload failed!

Ending session...
ERROR: Failed to send end session packet!
Releasing device interface...

Result: failure.

Relevant bit:

Uploading RADIO
72%
ERROR: Failed to send file part packet!
ERROR: RADIO upload failed!

And I reproduce that behaviour at each attempt.

Well, progress - but we’re not there yet: I find absolutely no sense in the upload failing at that specific point each time. I found another person with the same symptom, but he never found the cause.

@aibd suggested that the error could be a regional variant mismatch and he was right: download mode screen in Korean should have been a hint - mine is a SM-G965N from South Korea. Regional hardware variants… Damn. I suppose I’m a poster child for Android cluelessness and that my experience is therefore relevant for documentation improvement !

Anyway…

unzip G965NKSU5FVA2_G965NOKR5FVA2_SKC.zip && for f in *.tar.md5; do tar xf $f; done && lz4 -dm *.lz4
heimdall print-pit --no-reboot > S9.pit
heimdall flash `ls -1 | sort | while read i; do grep -B 1 $i S9.pit; done | sed s/Partition\ Name:\ /--/g | sed s/Flash\ Filename:\ // | tr '\n' ' ' | sed s/--\ //`
# Actually the command produces a duplicate "--UP_PARAM up_param.bin" I pruned by hand - exercise for the reader

The good news is that heimdall flash reported all successful. Reboot, an Android appears with a progress bar and…

The bad news is that the device is now in a boot loop - wiping cache partition from recovery didn’t help, nor did “wipe data/factory reset”, but at least I get the stock recovery rather than TWRP. On to clear the next hurdle on my path to get stock Samsung Android 10 so that I can install the latest /e/ to check if it solves my “SIM not detected SM-G960F after OTA Upgrade” problem…

Tried all the Korean G965N flavors too
G965NKSU5FVA2_G965NOKR5FVA2_SKC.zip
G965NKSU5FVA2_G965NOKR5FVA2_KOO.zip
G965NKSU5FVA2_G965NOKR5FVA2_LUC.zip
G965NKSU5FVA2_G965NOKR5FVA2_KTC.zip

I am sorry, @lottier, but perhaps we could return to your originl thread (or a new one) and add a contrbution to Document Suggestions when we have found a solution. :slight_smile:

My guess you have a Korean device | Korea firmware, where you require a Korean device | your Region firmware. CSC Codes for Korea: SKT, LUC, SKC, KTC

… and /or … star2lte - SM-G965N | starlte - SM-G960N

Yes, I now have a generic problem unrelated to documentation or to my original problem - I’ll stop updating here and find more a relevant location. Thanks !

2 Likes

Device : Samsung S9 [SM-G960F/DS]
eOS : e-1.9-q-20230310268292-stable-starlte.zip
Documentation : https://doc.e.foundation/devices/starlte/install

I ve just finished the installation on my New Second-Hand S9 Phone using the documentation linked above.

Everything went as written and I see absolutely nothing to add to this documentation.
Thank you so much :+1:

Continuing the discussion from Samsung - Galaxy S9 - starlte - Documentation Suggestions:

Android T dev /e/os 1.15 samsung s9

(Via r 1.15)

Zip file contains recovery.img… extract amd then use heimdall with s9 in bootloader mode

Next put into recovery mode - factory reset option before sideloading with adb the complete zip

In my experience you get bootloop if no factory reset stage in recovery (of course means a lot of re setting up after).

But, can report I have working android t v1.15 on my S9

Which one do you use ? Here the recovery image for T build is not yet available.

Do you mean download mode ? I though there was no bootloader mode for samsung.

Maybe because (supposition) you didn’t get the right recovery image ?

I noticed no recovery image on the usual web page. But if you look inside the lonely zip file there is a recovery.img file inside… The one I used.

Yes download mode (not boot) with blue screen on Samsung (bixby vol-down power) heimdall the recovery.img

If you then adb sideload the whole zip in recovery mode after factory reset, all works, but need to resetup… Otherwise, when at first I tried no factory reset, the boot-loop (e bounce . forever happened after sideload and reboot).

Hope that is a little clearer

OK thank you!

I really try to find a really detailed workflow to upgrade from Q to T without data loss via sideload. Your repport here give me less hope…

Understand… I was on Q, upgraded to R (was not good), hence endeavor to try T…

Fortunately for me, I was well backed up on data before the boot loop. Fortunately no bricking as I recovered as described earlier.

But, it still did take me best part of a day to get all going again.

T is (eventually) much better. In hindsight I probably would have been better off staying on stable channel and waiting for OTA update, but, wanted to report that it is doable today, as there seemed not much testing on the forums at this early point.

Good wishes

1 Like

NO, it is because the device tree have not the same organisation now…