Fastbooting the recovery image fails on Xperia 10 II

I am already out of disk space for “SailfishOS and other data” so I am trying to follow instructions to expand the partition so that I can install the update (and also have a working handset, it’s gotten very buggy since I’m up against the limit). But I can’t even get started as I cannot boot the recovery image on my Xperia 10ii!

I press Volume Up while plugging it in, using the right data cable, wait til the light is blue, double check using “fastboot devices” that the phone shows up, navigate to the right directory, then:

fastboot boot hybris-recovery.img
downloading ‘boot.img’…
OKAY [ 0.431s]
booting …
FAILED (remote: unknown command)
finished. total time: 0.431s

The phone is plugged in to a Linux machine running Mint - the very same one I used to flash over Sailfish last weekend. Fastboot is up to date I believe (version 1:8.1.0+r23-5~18.04). I re-downloaded the SailfishOS files just in case so I am using the right hybris-recovery.img
I can reboot the phone using “fastboot reboot” so a few other commands work. I can flash over hybris-recovery.img but not boot from it for some reason.

It is already unlocked. I have developer mode enabled and logged in as “devel-su” before powering off and plugging in to try to access recovery (just in case).

Any ideas? XDA forum is full of people with other phones having trouble just executing OEM unlock but I haven’t found anything else out there that would help.

Thanks for any assistance … I don’t know why I am having so much trouble with this particular install … this is my 4th Sailfish device…

Definitely a strange collection of circumstances … A few things to try - different fastboot version, (even if it’s older), reboot phone and computer , different cable, etc… I’ve been fastbooting since about '08, and I’ve never seen it flash an IMG, but fail to boot it…

Fastbooting a SailfishOS recovery image is not supported on the Xperia 10 II (only).
I.e., trying to fastboot the recovery image on a Xperia 10 II is futile!

For the official workaround, see [Jolla’s Zendesk] Xperia 10 II: How to use the Recovery Mode.
I.e., currently you have to overwrite the two boot partitions with the recovery image, by flashing it there. After performing your work with the recovery image, you have to flash the boot image to the two boot partitions A and B.

Technical background: This is well known (since Jolla designed how to use Sony’s partition layout on the Xperia 10 II), a proper solution is implemented by Jolla, but not yet released; click here for the details and Jolla’s plans for this.

3 Likes

Thank you, @olf! This was the solution I needed. I didn’t realize that the 10ii was so different! And I was looking at the zendesk Xperia recovery mode page but not Xperia 10ii.

Does that mean I should be using an updated version of this guide for resizing the partitions too? If so, where would I find one? (Guide: Installing Sailfish X on Xperias - together.jolla.com)

A million thanks.

as far as I know, you don’t need to resize with the 10 II - the /home partition is much larger than with the X or even XA2

1 Like

but he has no problem with the home partition, or did you not read his post?

Well, reading thoroughly often helps, i.e.:

  1. […] I was looking at the zendesk Xperia recovery mode page but not Xperia 10ii.

  2. Does that mean I should be using an updated version of this guide for resizing the partitions too?

    You should not use an oudated version of this guide, which the one at TJC implicitly is, because TJC has been put into read-only mode in October 2020.

  3. If so, where would I find one? (Guide: Installing Sailfish X on Xperias - together.jolla.com)

    The P.S. there tells you: The original source of this guide is at Gitlab.com and is rendered better there […]

  4. A million thanks.

    Mind that using inappropriate values for the LVM resizing may easily brick your device.
    If you follow that route, please document the values you used, Xperia 10 II specific issues you had to overcome etc. here and / or in an issue at Gitlab.

    As the an Xperia 10 II should have a 4000 MB root volume size after flashing, please check that per lvdisplay (executed as root) and copy its output here (I never had the chance to look at this on an Xperia 10 II, hence this will be helpful for future development of aforementioned guide).
    I also wonder why the root filesystem is already full on your device: Please check per df -h and also copy its output here.

1 Like

Thanks @cartron. Yes my 10ii has 4.8G on root and I know this is bigger than prior Xperias, but apparently I’m at 98% regardless and I don’t know why.

@olf thank you for the additional help and info. Here is lvdisplay:

root@Xperia10II-DualSIM defaultuser]# lvdisplay

--- Logical volume ---
LV Path                /dev/sailfish/root
LV Name                root
VG Name                sailfish
LV UUID                [UUID string here]
LV Write Access        read/write
LV Creation host, time SailfishSDK, 2021-05-20 08:25:13 -0400
LV Status              available
# open                 1
LV Size                4.88 GiB
Current LE             1250
Segments               2
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           252:0

--- Logical volume ---
LV Path                /dev/sailfish/home
LV Name                home
VG Name                sailfish
LV UUID                [UUID string here]
LV Write Access        read/write
LV Creation host, time SailfishSDK, 2021-05-20 08:25:13 -0400
LV Status              available
# open                 1
LV Size                97.14 GiB
Current LE             24869
Segments               2
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           252:1

And here is df -h readout:

root@Xperia10II-DualSIM defaultuser]# df -h
Filesystem                Size      Used Available Use% Mounted
on
/dev/sailfish/root        4.7G      4.6G     97.3M  98% /
devtmpfs                  1.6G    732.0K      1.6G   0% /dev
tmpfs                     1.7G      8.0K      1.7G   0% /dev/sh
m
tmpfs                     1.7G     10.3M      1.7G   1% /run
tmpfs                     1.7G         0      1.7G   0% /sys/fs
/cgroup
tmpfs                     1.7G     16.0K      1.7G   0% /tmp
/dev/mmcblk0p48         359.9M    135.8M    224.0M  38% /vendor
/firmware_mnt
/dev/mmcblk0p50          27.5M     13.1M     13.7M  49% /vendor
/dsp
/dev/mmcblk0p46          64.0M    832.0K     63.1M   1% /vendor
/bt_firmware
/dev/mmcblk0p2           27.0M      1.4M     24.7M   5% /mnt/ve
ndor/persist
/dev/mmcblk0p66          11.5M     72.0K     10.9M   1% /metada
ta
/dev/mmcblk0p83         368.9M    250.5M    110.6M  69% /odm
/dev/block/loop0         95.1M     95.1M         0 100% /apex/c
om.android.runtime@1
/dev/block/loop0         95.1M     95.1M         0 100% /apex/c
om.android.runtime
/dev/block/loop3        840.0K    812.0K     12.0K  99% /apex/c
om.android.tzdata@299900000
/dev/block/loop3        840.0K    812.0K     12.0K  99% /apex/c
om.android.tzdata
/dev/block/loop1          5.3M      5.3M         0 100% /apex/c
om.android.media@299900000
/dev/block/loop1          5.3M      5.3M         0 100% /apex/c
om.android.media
/dev/block/loop2          1.6M      1.6M         0 100% /apex/c
om.android.resolv@299900000
/dev/block/loop2          1.6M      1.6M         0 100% /apex/c
om.android.resolv
/dev/block/loop4          5.0M      4.9M         0 100% /apex/c
om.android.conscrypt@299900000
/dev/block/loop4          5.0M      4.9M         0 100% /apex/c
om.android.conscrypt
/dev/block/loop5         20.9M     20.9M         0 100% /apex/c
om.android.media.swcodec@299900000
/dev/block/loop5         20.9M     20.9M         0 100% /apex/c
om.android.media.swcodec
/dev/block/loop8        232.0K     36.0K    192.0K  16% /apex/c
om.android.apex.cts.shim@1
/dev/block/loop8        232.0K     36.0K    192.0K  16% /apex/c
om.android.apex.cts.shim
/dev/mapper/luks-[alphanumeric-string]
95.1G      5.8G     89.3G   6% /home
tmpfs                   355.8M    468.0K    355.4M   0% /run/us
er/100000
/dev/mmcblk1p1           14.8G      2.7G     12.1G  19% /run/me
dia/defaultuser/[SD card ID]
tmpfs                     1.7G     10.3M      1.7G   1% /run/fi
rejail/dbus

I did attempt a resize but didn’t get far before running into problems – I can say more about that here or on Gitlab.

I am sure curious and would also extend the guide, if necessary or valuable additions can be extracted from your experience.
With a bit of luck, I may be able to guide you through the process (i.e., point out what went wrong and how to do it right).

Either place is O.K. for me: An issue at Gitlab or continuing this thread here at FSO. Usually I would say, “let us avoid filling this forum thread with stuff uninteresting for most”, but as the original questions are all answered, we might simply (ab)use this thread for researching the details of adapting section 3.3.2.b to the Xperia 10 II.

Which value did you calculate / intend to use for the resizing step 15?
At which step did issues occur, and what was the error message?

But in your own interest, you should determine what eats all the space on the root file-system, first!
Ade’s space inspector might be helpful to do that easily at the GUI: Space Inspector | OpenRepos.net — Community Repository System

2 Likes

Yes, nice tool.
But it takes quite some time on each view change.
If you are not afraid of the CLI then I suggest using ‘du’ (maybe you need to pkcon install coreutils?).
And then start from root /

du -xsh /
du -xsh /*
du -xs /* | sort -n

First one will give you an overview of the whole directory
Second one will give you for each single directory
Third one output sorted in order of disk usage.

That way you can descend pretty fast and find the culprit.

1 Like

Thank you both! The Ade tool looks good but I always prefer the command line! :wink: I appreciate the pointers – I couldn’t detect what the title “System Data/Sailfish OS and other files” label in Settings-Storage referred to or how the partitions were organized and OS files allocated, so this helped me find what I needed and get more familiar with the system.

The culprit turned out to be a file in /root called “android_storage” (but not a directory). Although I thought all Android app data lived in /home, it was suspiciously the same size as a rather large backup I used to transfer my Signal account info… :-/ (I know, I know, Whisperfish…). Now that’s gone, I’m back to 2.1G in /root, and so far my android apps work just fine… Now to see if I can install Verla…

As the main issues here have been resolved and experimenting with partition resizing may be helpful for others to find in future, I will start another thread for those interested in expanding root size on 10ii, with intention of creating a section 3.3.2.c in the Gitlab guide. Will post a link here when that’s started.

1 Like