Skip to content

YuROM Ultra V35 R33 — Stable (boot-loop fix)

Latest
Latest

Choose a tag to compare

View all tags
@yuefdev yuefdev released this 30 Oct 13:05
v35-r33
f3642b7

YuROM Ultra V35 R33 — Stable (boot-loop fix)

One UI 9 / Android 17 for Exynos SM-G970F, SM-G973F and SM-G975F.
R33 replaces R32. R32 shipped a vendor image whose filesystem root had no SELinux label, which can end in a boot loop or a hang on the boot logo. R33 contains the corrected vendor image and nothing else is different. Read the validation limits below before flashing: the release designation does not mean every device, installation path or feature has completed physical testing.

Already on R32? Use the hotfix, not R33

If R32 is installed (even if it does not boot), flash the small vendor label hotfix r1 in TWRP. It changes one block of /vendor, keeps userdata and needs no wipe.

The R33 installer will not accept an installed R32 as an upgrade source: the data-preserving path still accepts only the exact original v35-beta six-image set. Do not wipe or format your phone just to move from R32 to R33; the hotfix produces the same vendor image.

Calls and display fix (built into the installer)

Testers reported no ringback, calls that drop right after the other side answers, "emergency calls only", IMS error -1 and a broken status bar and screen resolution. The S26 base lacks the stock Galaxy S10 SELinux rules for the modem daemon multiclientd: the rules that let the phone and IMS apps connect to it, the rules that let it read its clients' names, and the rule that lets it run logcat. Without the last one the daemon's forked helper exits and drops the daemon's link to the modem RIL, so every later modem request fails and the call drops. The one-time display service also ran in a domain that cannot reach the display services.

The installer (r4, below) applies this fix by itself right after it installs and verifies the ROM, so a new installation needs only the DATA ZIPs and the MULTIPART installer: do not flash a separate hotfix. The built-in step is the published hotfix r3 ZIP, unchanged and pinned by SHA-256. It covers all three models and writes only /vendor.

Already running R33 from an r1 or r2 installer? Flash YuROM_Ultra_V35_R33_Call_Display_Hotfix_r3.zip in TWRP once, at any time. No wipe. It also upgrades a phone that already has hotfix r1, so do not install r1 first; the r1 files stay attached for reference only. It is undone with YuROM_Ultra_V35_R33_Call_Display_Hotfix_REVERT_r3.zip. Read README_EN.md. SHA-256 files and the source are attached.

Tested on one phone: an SM-G973F running R33 (Turkish carrier). Calls connect and stay connected, IMS registers, and the standalone ZIP was run in TWRP (apply, upgrade from r2, repeat, revert). The built-in step of installer r3 (r4 carries the same launcher and fix code) was run in TWRP on the same phone too (see the validation limits). The SM-G970F and SM-G975F carry the byte-identical policy file but were not tested. It does not address the missing VoLTE toggle or the missing SMS app.

What changed in R33

  • vendor.img: the root of the ext4 filesystem now carries u:object_r:vendor_file:s0. Each model's R33 vendor image differs from its R32 vendor image in exactly one 4 KiB block (38 changed bytes in total).
  • system, boot, dtb, dtbo and vbmeta are byte-identical to R32. The installer script, upgrade-source contract and safety checks are unchanged. Only the package version string and the vendor checksums in the manifest differ.
  • Installers r3 and r4 also apply the call and display fix described above. The six ROM images are unchanged.
  • The packing script now compares the SELinux label of the packed filesystem root with the candidate's and refuses to build if it is missing. R32 only compared the files inside the image, which is how the defect got through. A regression test covers it.

Installer r4 and three DATA ZIPs (same R33 ROM files)

The installers are now r4. The ROM images and every installer check are unchanged from r3. The only change is how the image data is packed: each model now has three DATA ZIPs instead of six, so there are fewer files to download and keep together. GitHub accepts at most 2 GiB per file and each model's compressed images come to about 4.9 to 4.9 GB, so three is the smallest number that is possible here. Each DATA ZIP is still a classic ZIP below 2,000,000,000 bytes (1.4 to 1.8 GB), which FAT32 can hold and the unzip in TWRP can read.

After a successful, read-back-verified install, the installer first applies the call and display fix above to /vendor, then clears the contents of /cache by itself. Apps, accounts, settings and files in /data are not touched and nothing is formatted. The /cache clearing replaces the manual Cache wipe, which can stall in TWRP, so updating from an older YuROM version needs no manual wipe and no format. Dalvik/ART Cache is deliberately left alone: emptying it made the first boot take about 18 minutes. Wait for the installer's message that the built-in call and display fix is installed before you reboot. If the fix step cannot run, the installer ends with an ERROR that names the standalone hotfix ZIP; the ROM itself is already installed, so flash that ZIP before rebooting.

Already downloaded an r1, r2 or r3 installer, or the former six *_DATA_01..06.zip files? Delete them and download the three new DATA ZIPs with the r4 installer. The r4 installer does not accept the old six DATA ZIPs, and the old installers do not accept the new three. The source of the built-in step and of the builders, including the tool that regrouped the chunks, is attached as YuROM_Ultra_V35_R33_INSTALLER_r4_Source.zip (GPL-3.0-or-later).

Downloads

R33 is delivered only as parts plus an installer that joins them. There is no single large ROM ZIP, neither on GitHub nor on Drive: the former complete *_TWRP.zip, its numbered .001 to .003 pieces, join_yurom.py, DOWNLOADS.json and the single-ZIP *_INSTALLER_r3.zip were withdrawn. The three DATA ZIPs of a model carry exactly the same six images.

For your exact model (SM-G970F, SM-G973F or SM-G975F) download all three DATA ZIPs (*_DATA_1of3.zip, *_DATA_2of3.zip, *_DATA_3of3.zip) and the matching *_MULTIPART_INSTALLER_r4.zip (with their .sha256 files) into one folder, keep the names, and flash only the MULTIPART installer in TWRP. The installer reads the DATA ZIPs from that folder, verifies every chunk, writes and reads back the six images, then applies the call and display fix. Do not flash or extract the DATA ZIPs, and do not mix models, R32 files or old beta/r7 files.

  • GitHub: the assets of this release. Each DATA ZIP is a classic ZIP below 2,000,000,000 bytes (1.4 to 1.8 GB), so no joining, Python or temporary full ROM is needed, and FAT32 can hold the individual files.
  • Google Drive: Download the verified R33 mirror, open your exact model folder, then Multipart_R33. Same files, same checksums. The existing R32 folders and the TWRP folders are unchanged.

ADB sideload is not supported: use TWRP Install from readable storage that holds all the files. Read INSTALLATION_EN.md.

Everything else carried over from R32

  • Updated Samsung camera integration and native compatibility repairs; basic photo/video operation was accepted on the reference G973F, not every camera mode on every model.
  • Dual-ABI WebView repair, including the Samsung Account web flow.
  • Bluetooth PCM/audio-policy compatibility repair. Accessory pairing, streaming and call-audio acceptance remain separate.
  • Galaxy Themes startup repair, Eye Comfort, media/metadata and Samsung application compatibility repairs.
  • Enforcing init restoration: SELinux stays Enforcing; file-based encryption of userdata is preserved.
  • Permanent real TEE storage for only two exact user-0 PDE owner stores (Now Brief / Now Bar). This uses TrustZone/TEE, not StrongBox isolation. Broad AI inference, weather, Moments, TTS and language-model functionality are not accepted by extension.
  • Retained applications: Video Library 1.4.22.81, Video Player 7.3.28.1, Interpreter 1.1.26.2, Calendar 12.8.01.0, Calculator 12.6.00.35, Good Lock 3.0.16.6, Device Care system base 13.8.82.1.

Verified first-beta upgrade — do not format

Only the exact original, model-specific v35-beta six-image source is accepted with existing userdata. The installer checks system, vendor, boot, DTB, DTBO and vbmeta before writing. Modified system/vendor, rooted or otherwise changed source boot, later builds (including R32) and partial previous flashes are rejected.

For a matching source, retain readable mounted ext4 /data, unmount System/System Root and Vendor, and run the MULTIPART installer beside its DATA ZIPs. Do not wipe or format for this path. Keep an external rollback backup.

Fresh installation and safety

Fresh ext4 userdata uses the same ROM without an automatic format. This release does not contain a selectable-format menu and never formats or repartitions userdata. Migrating from another ROM or encryption scheme is not a supported no-wipe upgrade. Any separately chosen manual Format Data irreversibly erases apps, accounts, photos and internal storage; back up externally first.

For a clean install (stock firmware, another ROM or a phone that never booted), do Wipe → Format Data before flashing (keep the ZIPs on microSD/OTG) and create nothing in /data from TWRP; the installer then clears /cache itself. Updating from an older YuROM version needs no format. One user reported that Format Data plus a Cache wipe stopped a restart at the setup screen; we could not reproduce that restart, so this is a precaution, not a confirmed fix. Details in INSTALLATION_EN.md.

The installer writes complete system/vendor/boot/DTB/DTBO/vbmeta images. It does not erase /data/app updates, camera preferences or Magisk modules; those can override packaged applications. Recovery, modem, EFS, bootloader and the partition table are not written. Read INSTALLATION_EN.md.

Validation limits

What was checked:

  • The three complete R33 ROM ZIPs (since cut into the DATA ZIPs, which carry the same six images, and no longer published as single files) were derived from the verified public R32 ZIPs. Every chunk and every image SHA256 was recomputed, and every entry other than the vendor chunks and the manifest is byte-identical to R32.
  • Each corrected vendor image passes a read-only e2fsck, shows security.selinux = u:object_r:vendor_file:s0 on its root, and has a SHA256 that matches the manifest of its ZIP. The small installers were rebuilt and pinned to the new payload checksums.
  • On the reference SM-G973F, the public R32 system image with the corrected vendor image (SELinux Enforcing, userdata untouched) reached sys.boot_completed=1 and stayed up for the 45 s observation window, and was still running when this release was prepared. The same system with the released R32 vendor image did not complete boot within 180 s.
  • The /cache step (added in r2, unchanged in r3 and r4) is covered by host tests (symlinks, odd file names, an unmounted /cache, refusal of any other path, and running only after the original installer exits 0). Its exact commands were also run once in TWRP on the reference SM-G973F with R33 installed and set up (not through the installer): /cache went from 8 entries to only lost+found, the 72 top-level entries of /data stayed, and the next normal boot reached sys.boot_completed=1 after 61 s in Enforcing with the same 304 packages. An earlier run that also emptied /data/dalvik-cache booted but took about 18 minutes, so the installer does not touch it.
  • Installer r3's built-in call and display fix: the ZIP carried inside each installer is byte-identical to the published Call_Display_Hotfix_r3.zip, and the installer checks its SHA-256 before it writes anything. Both launcher types (single and multipart; only the multipart one is published) passed host tests against copies of the released SM-G973F vendor image: order of the steps, a failing or damaged fix, a recovery that lacks a tool, an unsupported device, a repeat run and a failing original installer. Both were also run in TWRP 3.7.0 on the reference SM-G973F with a stand-in for the ROM payload: the fix applied to the released vendor (policy and display-service label read back right), a repeat run changed nothing, a damaged embedded fix stopped before any write, and a fix that fails ended in the documented ERROR. The phone then booted (Enforcing, 1080x2280, modem daemon running).
  • Installer r4 (three DATA ZIPs): every chunk was copied out of the verified r3 DATA ZIPs, compared with its SHA-256 in chunks.tsv while it was copied, and read back from the new ZIPs. Compared with r3, only the DATA ZIP checks and chunk routes inside install.sh and the SHA-256 of that script pinned in the launcher differ; the launcher code, the embedded fix, the manifest and the partition, chunk and upgrade-source tables are byte-identical. On the host, the installer's own chunk reader returned every chunk of all three models with the right SHA-256, and it refused a missing and a damaged DATA ZIP. In TWRP 3.7.0 on the reference SM-G973F, the recovery's own busybox unzip -p (the command the installer's chunk reader uses) read all 12 chunks of that model's three DATA ZIPs, one ZIP at a time because /data cannot be read in that recovery, and every chunk had the right SHA-256. Nothing was flashed.

What was not checked:

  • The complete R33 packages (all DATA ZIPs with the MULTIPART installer) have not been installed on hardware. No clean install and no first-beta upgrade with the R33 installer was performed on any phone.
  • The complete r3 and r4 installers have not been run end to end on a phone: the real ROM payload was never installed through them, and no update from the original v35-beta was performed with them. The reported restart at the setup screen could not be reproduced, so it is not proven that clearing /cache prevents it.
  • SM-G970F and SM-G975F were not booted with the corrected vendor image; their images are verified on the host only. The built-in fix step was run on the SM-G973F only; it carries the same bytes and checks for the other two models.
  • The fix step accepts only the released SM-G973F/G970F/G975F vendor partition size. A phone with a differently sized (repartitioned) vendor partition gets an ERROR from it and no change is written; the standalone ZIP refuses the same way.
  • Calls/two-way audio, accessory Bluetooth, HDMI/DeX, all camera modes and long-term tuning stability are not universally verified.

Corresponding sources and credits

Thanks to XGSI, ArtisanROM/UN1CA, ExtremeXT/ExtremeROM, LineageOS, Samsung, Team Win/TWRP, EROFS, Android, kernel contributors and testers. Existing licences, credits and model-specific firmware provenance are retained.

Assets 54
Loading