I’ve flashed Sailfish OS 5.0.0.77 on my Xperia 10 III (XQ-BT52) multiple times via the official flash.sh script on Linux Mint. Flashing always completes successfully, but the device has never shown a usable UI. Details below — this has been a long troubleshooting process so I have fairly detailed data.
Setup:
Sony stock firmware reinstalled via Emma before flashing
Sailfish X 5.0.0.77, Sony binaries v9a_lena (flashed as sparse image via img2simg due to max-download-size limit on oem_a — raw flash failed with “Requested download size is more than max allowed”, sparse conversion fixed it)
flash.sh via Linux Mint, fastboot 34.0.4
Boot behavior:
Standard boot sequence: “can’t be checked for corruption” (expected, unlocked bootloader) → Sony logo → Sailfish logo → screen goes dark
Device becomes unreachable via USB in most cases (no adb, no fastboot enumeration, not visible in lsusb)
However, on one occasion, adb devices showed the device as unauthorized while screen was dark — proving Sailfish had actually booted and USB/adb daemon was running, just no way to approve the on-screen authorization dialog (screen never lights up)
/var/log/systemboot.log (viewed via Jolla recovery shell) showed the system reaching USER state and running for extended periods (2+ hours in one boot) before a clean shutdown request from dsme — again suggesting the OS itself runs fine, but display never activates
What I’ve verified as healthy via Jolla recovery mode:
e2fsck on root and home partitions: completely clean, no errors
LVM volume group “sailfish” activates correctly (2 logical volumes) — except once, after using recovery’s “Reset device to factory state” option, which apparently wiped the LVM structure entirely (pvscan/vgscan found nothing). Reflashing userdata (sailfish.img001) restored it fine. Worth warning others: avoid the factory-state-reset recovery option, seems to break LVM.
Set up SSH pubkey auth manually via recovery (mounted /dev/sailfish/root and /dev/sailfish/home, added authorized_keys for defaultuser at UID 100000, enabled sshd.socket for multi-user.target) in hopes of getting a shell without needing the screen — but no network interface (USB or otherwise) appears on the host machine after boot, so I can’t confirm if sshd is actually starting.
Also tried:
A/B slot switching (was on slot a with retry-count already at 6/7 before I started troubleshooting — odd, as if boot had already failed a few times before I even got the phone into this state)
Full clean reflash of all partitions in one script run (not piecemeal)
Bootloader version appeared to shift between two of my getvar checks (LA2.0_R_49 vs LA2.0.2_T_205) though this may have been a misread on my part — worth double-checking if relevant
Given the evidence that Sailfish does boot and run in the background at least sometimes, I suspect this may be a display/kernel driver issue specific to this unit or this firmware combination, rather than a flashing/partition issue. Has anyone seen this pattern before, or have suggestions for further diagnosis (e.g., getting console/kernel logs without a working screen)?
Not sure it will help, but (while in recovery), enable persistent logging for systemd:
#### Assuming the root is mounted as /mnt/root
mkdir -p /mnt/root/etc/systemd/journald.conf.d/
printf '[Journal]\nStorage=persistent\n' > /mnt/root/etc/systemd/journald.conf.d/persist-logs.conf
reboot, wait until the problem appears, then reboot into recovery again.
Journal files should now be available at /mnt/root/var/log/journal, and you can read them using journalctl --directory=SOME_PATH or journalctl --file=/path/to/journal/file
Many have come across this same error (search the forum for discussions) and have successfully worked around it by adding a parameter to the flashing command to increase the file size limit (-S if I remember correctly).
Please note I have no idea if it would make any difference in your case compared to the sparse conversion (I guess in theory it should not), but in case you’re out of ideas, it may be worth trying.
I managed to get persistent journald logging working via Jolla recovery (mounted the root partition, added Storage=persistent to journald.conf.d, then transferred the journal file off the device via netcat since the recovery shell has no journalctl).
Found this in the kernel log, right after the display panel receives its power-on sequence:
kernel: @@@@ panel power on @@@@
...
kernel: dsi_panel_driver_oled_short_det_handler: VREG_NG interrupt!
kernel: dsi_panel_driver_oled_short_det_handler: VREG_NG!!!
VREG_NG = Voltage Regulator No Good — this is a hardware-level fault detector on the OLED panel’s power circuit, triggered right as the panel is powered on.
Right before that, several panel driver warnings appear during probe:
dsi_panel_driver_parse_gpios: failed get touch-vddio-en gpio
dsi_panel_driver_parse_gpios: touch-vddh-en gpio not present
dsi_panel_driver_parse_power_cfg: Not configured touch vregs
dsi_panel_driver_parse_power_cfg: Not configured vsp/vsn vregs
dsi_panel_driver_touch_pinctrl_set_state: invalid 'somc_ts_int_suspend' pinstate
dsi_panel_driver_touch_pinctrl_set_state: invalid 'somc_ts_int_active' pinstate (later)
Interestingly, MCE (display state manager) still reports display state req: ON and mdy_display_state_leave(): current display state = POWER_UP right after, but the screen never actually lights up — consistent with what I’ve been observing physically.
Important context: the screen does work fine under stock Android on this same unit (I confirmed this by booting to the Android welcome screen after an Emma repair flash, before flashing Sailfish again). So this doesn’t look like a permanent hardware fault — it looks like a power-sequencing/timing issue specific to how the Sailfish kernel (hybris-boot) initializes this panel, possibly related to the missing GPIO/vreg configuration entries noted above.
Full context on my setup and troubleshooting so far is in my earlier posts above. Happy to share the full journal file or more log excerpts if that would help pinpoint this further — is this a known issue with the pdx213 panel driver, or worth reporting upstream?
Perhaps you could try flashing a later Android version in EMMA - AFAIK, sailfish runs fine on Android 12 and 13 - and then try install sailfish again. In case you haven’t given this a go.
Test 1: Android 12 firmware (62.1.A.0.675) + Sailfish 5.0.0.77
Re-flashed stock firmware via Emma to Android 12, booted to Android UI, powered off, then flashed Sailfish again (same files, same v9a_lena binary per the guidance in the “which AOSP binary” thread — using A11 blobs with A12 firmware). Same boot pattern: dark screen, unreachable via USB.
Test 2: Fresh Sailfish X 5.1.0.11 download (on Android 12 firmware)
Downloaded 5.1.0.11 fresh from Jolla Shop (verified all files against md5.lst — 100% match), flashed on top of the Android 12 base. This time observed something new: the Sailfish logo stayed up for 7-11 minutes (vs. seconds/couple minutes before), and the screen would dim and wake on touch (backlight responds) — but no UI ever appeared behind the logo, and eventually it went dark permanently.
Pulled the persistent journal again for this 5.1.0.11 boot and found the identical VREG_NG fault, at the identical point in the panel init sequence:
kernel: @@@@ panel power on @@@@
kernel: dsi_panel_driver_oled_short_det_handler: VREG_NG interrupt!
This now rules out (confirmed identical failure across all combinations):
Wrong/corrupted binary (MD5-verified, using the officially-recommended v9a_lena blob for both A11 and A12 firmware)
Android 11 vs Android 12 base firmware
Sailfish 5.0.0.77 vs 5.1.0.11
Filesystem/LVM corruption (e2fsck clean both times)
The touch-responsive dim/wake behavior on 5.1.0.11 is new and wasn’t seen on 5.0.0.77, so there may be some difference in how the display/power management stack behaves post-VREG_NG-fault between versions, even though the underlying kernel fault is identical. Not sure if that’s a meaningful clue or a red herring.
At this point I suspect this might be a hardware-level issue (marginal panel power regulator) that’s only exposed by the specific power sequencing timing in the Sailfish/hybris kernel — possibly not triggered by the stock Android kernel’s different init sequence/timing. Open to any further ideas, but also starting to wonder if this particular unit’s display panel might have a real hardware fault that only manifests under this specific driver stack.
Happy to test anything else that might help narrow this down.
Instead of Android 11 binaries, can you try Android 12? This person was able boot Sailfish over a base of Android 13 and Android 13 binary - Android 13 and SailfishOS on Xperia 10 III - #22 by wetab73 - note the issue with VoLTE, but I haven’t researched this topic enough to know whether that’s resolved or what others have experienced, but I assume we’re just trying to see if you can get it to boot with a working screen. Note, the binaries can be flashed after a sailfish install - perhaps you can flash all versions to see if they make a difference - Updating the Vendor Image | Sailfish OS Documentation