Recovery mode: which image to fastboot?

Devices
#1

This is a question regarding Sailfish X devices which need to launch recovery mode.

According to https://jolla.zendesk.com/hc/en-us/articles/360002996893#2, recovery mode is launched thusly:

  1. get device into fastboot mode
  2. connect to a computer
  3. using the fastboot tool, upload and boot hybris-recovery.img from the installation/flash media. We are told:

Also here it states:

I have a device that was originally flashed with SFOS 3.2.1. Then OTA updated to 3.3. Current available SFOS image (downloadable from the store) is 3.4.

Questions:

  1. Which hybris-recovery.img version is the correct one to fastboot with? 3.2? 3.3? 3.4? Does it matter at all?
  2. Where to get that image, if the correct one is not the latest available one from the store? (related question)

I would really like a definitive answer/guidance/recommendation from Jolla if at all possible.

1 Like
#2

Well, I’m neither definitive nor Jolla, but in the meantime, what I can tell you from experience flashing X: 1) if it is the img that is in the firmware zip, it will probably work, and 2) the fastboot “boot” command causes a temporary action which doesn’t persist after reboot, so of one doesn’t work just try the other one; there’s no risk, (the command “flash” is different, so always be careful with that)…

1 Like
#3

I used the hybris-recovery.img I originally downloaded when I first installed SFOS 3.2 to my phone to fix the borked version 3.4 update and it worked just fine.

1 Like
#4

This is a very good question!
And would be another reason for Jolla to host older images as well.

I would ask this question on zendesk as there you will get definitely an answer (I am very curious of).

**Never** use an older recovery image than the installed Sailfish OS release!

This does not sound like you can go with any image. Probably some older tool set or changes in partition layout or other irreversible changes?

2 Likes
#5

My advice comes from the simple fact, that newer software versions are usually backward compatible, but often not “forward compatible” (because that would require completely “stable” / frozen APIs, file formats etc.).

  • One crucial term is “installed Sailfish OS release”, which is explained to address the one which is currently installed (e.g. by having upgraded per OTA) on the device.
  • The core statement is “Never use an older recovery image than the installed Sailfish OS release!”.
  • So if you have not already downloaded the recovery image for the currently installed Sailfish OS release, “do download the recent installation image, unpack it and boot that recovery image.”
  1. Do these statements make sense for you now?
  2. Do you have specific suggestions how to rephrase these sentences to make them easier to understand?
    If so, please create a MR (or at least an issue) at https://gitlab.com/Phoen7x/sailfishX
3 Likes
#6

@olf this answers question #1 in detail
–edit
(even I could not visit that gitlab site neither SFOS browser nor WebCat nor Android Fennec :frowning: )
(even I could not visit that gitlab site neither SFOS browser nor WebCat :frowning: but Android Fennec :slight_smile: )

But for me the main question #2 here is:
oh no, :embarassed:
@nephros just go with the latest, here 3.4

1 Like
#7

E.g., a broken cryptsetup in a v3.0.x recovery image would not let you access an encrypted (e.g., /home) volume or partition.

2 Likes
#8

Works fine for me with Fennec, Firefox and IceCat-mobile (all three) under AlienDalvik.

Side note: I stopped using the native browsers since the demise of WebPirate and the fact that @leszek’s better / more recent QtWebKit contribution to SFOS was shrugged off multiple times by Jolla (apparently by consistent inactivity each time, after a few warm, fuzzy, but promising words the last two times).

1 Like
#9

Thanks everyone who replied.

I guess my reason for asking was twofold: First, to underline that Jolla should make older images available (though I guess Support if contacted would be able to provide links if really required). Or maybe even provide versioned recovery images independently from release images proper.

Secondly, to clarify why apparently using the installed version’s version of the recovery image is important. Thanks for clarifying, @olf and others.

I did have my suspicions it’s potentially about the compatibility of the tools involved. Although I trust most of the Linux tools wouldn’t make much of a difference (see also: the terribly outdated version if btrfs-utils that shipped with the J1).

However my suspicions lay more with the actual “recovery mode tools”, i.e. the fs check and factory reset functions of the recovery tool.
These I’m guessing are not written with either forward- or backwards compatibility in mind, and will simply assume an environment corresponding to their release version. And they have the potential to really wreak havoc if those assumptions turn out not to be true.

TL;DR I guess it boils down to:

  1. Older than installed: DON’T (though I’d guess just using it to drop into shell would be okay)
  2. Same as installed: RECOMMENDED
  3. Newer than installed: NOT RECOMMENDED but may work.

Corollary: do keep and archive all images for all releases you ever installed cause you never know when you’ll need them.

1 Like
#10

Thanks, they are quite clear, but I’d like some context added. Why is it that you should never use an old one? What may happen if you do?

Also: is it harmless to use a too-new version? (Like in my current situation where the installed version is not the latest one, but the current is the only one I can easily get to, and my copies of the older versions are long deleted.) And apparently, see posts below, it is okay.

#11

Nope, did so and got a simple “No, use current image”

#12

Interesting. So that is a valid way at least for some cases then.

#13

Well, these actually do (and shall) fit to the outdated btrfs in the outdated kernel the Jolla 1 uses.
See also the point below.

All filesystem-related tools should be used in a suitable version, i.e. at least the one a filesystem was created with, better the one it was last written to. Any newer version should work equally well (“upward compatibility”) when performing some recovery work, but mind that you will be back at older versions, when having recovered the SailfishOS installation proper and booting it.

Hence IMO your “TL;DR” for “recovery image release version versus installed SailfishOS release” might by:

  1. Older than installed: NOT RECOMMENDED (reading stuff and altering config files is O.K., but a fsck, resizing a filsystem and LVM actions etc. should be avoided)
  2. Same as installed: RECOMMENDED (theoretically the best)
  3. Newer than installed: RECOMMENDED, but may expose issues in niche cases, which might be avoided by directly upgrading to the SailfishOS release (or any newer one) the recovery image was from
1 Like
Hybris-recovery.img / hybris-boot.img files for SFOS 4.4
#14

Go ahead, MRs are welcome. But mind that this is just a small section in a large guide, plus merely a necessary prerequisite to describe, before explaining how to resize the LVM root volume. Hence extending this “Booting a recovery image” section shall be limited.

Generally not, but see this “but” half sentence.

What you specifically do, vastly determines the chances of triggering some extremely unlikely corner case.

And please do not complain. By using the command line interface you deliberately (and rightly so) decided to claim the powers and responsibility of a UNIX system administrator on this device. Thus it is within your power and responsibility to do the right things (or not) with sufficient knowledge (or not); if you fail, you know who is to blame. :wink:

1 Like
#15

When forcing an Xperia phone to the recovery mode, use the hybris-recovery.img version matching the OS version currently in the phone. In other words, download the latest Sailfish OS image and use the hybris-recovery.img in it (on condition that your phone has this latest OS version).

Apologies for the somewhat careless text in the Zendesk article. It is fixed now.

1 Like
#16

Thank you, @jovirkku!

This obviously leads to the follow-up question: how to get an out-of-date recovery image for the case the installed version is not the one currently downloable?
Is the recommendation that every user have the downloaded image for all their currently installed versions saved/backed-up somewhere?

2 Likes
Kolab Now and SFOS 3.4
#17

I am not complaining at all. On the contrary, I’m trying to do due diligence of understanding the tools used before executing them, and documenting the results for others.

Call me old-fashioned, but I was reared in a time where using Linux wasn’t taught as “copy paste this sudo command foo bar in your terminal”, and "curl http://github.com/frobnitz/install | xargs cat - | docker execute wasn’t a design pattern. :smiley:

I digress though.

1 Like
#18

You don’t, as @peterleinchen already inquired.

The next classic, “standard” statement you might trigger is “only the recent Sailfish OS release is supported (in general and always)”.

You can find these statements multiple times in TJC threads, and Jolla’s policies for end-user licensees are IMO reasonable from their perspective.
Yes, I also would like a couple of things to be handled more extensively by Jolla, but that is obviously not feasible with the manpower Jolla has. Specifically in the context of this thread: A much better quality assurance, so there is no reason not to install the most recent Sailfish OS release.