Check your private message.

The Sailfish recovery partition normally has 'xz' available.
(So you could pipe xzcat into dd)

At less than 300MB, you should be able to even store it on a FAT32 SD Card or safely send it over USB network cable with netcat.

It's the base I've rebuilt with my "factory-@" bla partitions.
It's formated as stated above (option compatible with Jolla kernel 3.2.108 + using "single" instead of "dup" for metadata).
That's the base out of which I've subsequently done my full restore (I copied all my rescued files on "@", "@home" after snapshotting).

Thx man, will try asap.

I found out more btw: the instructions I was following were for an older btrfs-tools. It should have been
That was the unsupported feature with code (0x100). Found out with
Seems I learned a lot so far about btrfs.

EDIT: LOL, just read your previous post. You explained the same thing.

What version is your snapshot from? 2.1.1.26?

Sadely no.
I've bought my phone back in 2014, so the "factroy-@" is some 1.xx old stuff.
You'll have to jump through several OTA until you reach the current 2.1.2 if you go this route.

Yup.

I would also recommend you to consider two other options, as I've said before :

• --uuid / -U : and you give it the same UUID as the old partition (use blkid command) and as in the /etc/fstab files.
  That will save tons of headache "why isn't the patition automatically mounted" ?
• --metadat / -m : set it to single (instead of the default dup).
  As I've written in the TJC post : dup doesn't make sense on flash media (both writes will often end up grouped together and you lose any benefit from duplication), and it wastes precious space on tiny flash partition.
  single helps a lot against enosp errors

A few key stuff :

• For checking the partition, periodically while mounted run :
  
  Code:

  btrfs scrub start -B /

  (-B to run it in foreground). This will scan all the chunks and check that they match their checksum.
  It's a bit more thorough than btrfs check : btrfs check only check if the general structure is coherent, something that the filesystem driver does any way upon mounting (to decide which copy to use). scrub will additionally check the content itself.
  I've put scrub as part of the "check for updates" script that I run every week or two.
• For space management, periodically while mounted run :
  
  Code:

  btrfs balance start -v -dusage=60 -musage=60

  This will rewrite data and metadata into new chunks, trying to group more data into less chunks (if two chunks are only 40% full - e.g.: because old deleted copies got enevtually garbage collected - they will be written into a single new chunk filled to 80%)
  The command :
  
  Code:

  btrs-balancer balance

  used internally by the installer does the same, but going by incremental steps (which help if there no space to allocate a new chunks) , and all the way to 100% so all the new chunks are filled to the brim and there's as much free space for newer chunks as possible.
  I run the 60% manually as above maybe once per month
• Every now and then, you can run :
  
  Code:

  fstrim /

  to tell the flashmedia that it can erase and consider the space free. Du to how copy-on-write works, there's no point in doing it online (no need to mount media with the "discard" option. Doing it every now and then (e.g.: after balancing when there a lot of space that got freed) is enough
• On heavily fragmented files you can run :
  
  Code:

  btrfs filesystem defrag -v <file>

  BTRFS is a Copy-on-write system (like ZFS, and a bit similar to log-structured filesystems like UDF and F2FS). It means in never overwrites. When you modify a file, it always write a new copy of this modified part, then updates the pointers to that modification, then eventually garbage collects the old copy if its not in use anymore (e.g.: by an older snapshot).
  That means that, for file that see a lot of small random writes, there's a lot of fragmentation, and to read anything from these, the btrfs driver has to travers a complex maze of pointer to finally reach the most up-to-date copy of the data (meaning a CPU and RAM performance hit). Typically this will happens with the various SQLite databases used everywhere. (You WhatsApp database is a prime example). Doing a defrag on such big SQLite files, will ask btrfs to rewrite the whole file as new continuous single copy, which helps a lot against fragmentation (and gives a small help on the overall phone performance).

OK, so I started the device to update to the version of my backup. There seems to be a problem about network. I can't start WLAN (please reboot for network) and SIM card is not recognized.

Is this because there are blobs incompatible or are there blobs missing at all?

Blobs might be incompatible.

You might want to either check the tutorials out there for manually resetting to factory,
Or see the content of the factory reset script inside the recovery
Or try a factory-reset from the recovery.

I seem to vaguely remember that the factory-reset needed to also flash a few blobs into the special purpose partition (all the other beside mmcblk0p28)

Or you could try to see if you can recover as much as possible using "btrfs restore" (including the file permission, extented attributes, etc.) on your laptop/desktop. It there aren't too many files missing you might as well be able to boot into your latest installation.

Yes, I'm getting close!

I reviewed all the steps while creating a new backup image. And I found a major stupidity of mine: I did btrfs restore into a new btrfs img mounted as loop. But I did not create any subvolumes, so the restored data were only directories. There is no visible difference when doing "ls" on the mounted img.

In the end, my new image was bootable after putting the backed up data into subvolumes.

Now there is on thing left: after boot, I get a white screen. While this tells me, it is booting to a kinda workable state, its not yet usable
I chrooted from recovery to unapply patches from patchmanager, as I have read these might be the cause. patchmanager --unapply-all didn't help, still only white screen.

Is there any other way to fix this? I am not on my home network, so the phone is not on the network automatically. Any reinstall has to come from within the phone I guess?

EDIT: on further inspection I found more errors
Seems all the btrfs scrub, btrfs check and btrfs restore didn't catch some stale file handles.
So doing ls -laR from the top is gives me the following stale file handles
@/usr/lib/qt5/qml/Sailfish/Store
@/usr/lib/qt5/qml/Sailfish/Lipstick
@/usr/lib/qt5/qml/Sailfish/Email/libsailfishemailplugin.so
@/usr/lib/qt5/qml/Sailfish/Email/qmldir

well, its not in factory-@ so I try to get those files... stay tuned

YES!!!!

I finally can use my phone again. And there is no reinstalling anything. It is just back normal with all my settings and data (well except, that I reverted patchmanager patches).

I will write a summary soon on what was actually needed. There are some catches, if someone (like me) follows older instructions.

Right now I am not in the mood for a writeup, just want to relax a moment and just enjoy my J1

EDIT: I put the instructions of what I did into another thread here

For the record, if anyone wants to use any such restore :

To flash the blobs that corresponds to some version of Sailfish :

You need to chroot into Sailfish if you're in recovery mode :
Once in Sailfish root, you need to run all the scripts that are in :
(Well, obviously, if you're in recovery, that means you already have a functional recovery, and don't need to run flash-recoveryimg-sbj.sh)

flash-bootimg-sbj.sh : will flash the kernel+initrd into the boot partition.
flash-persist.sh : will flash the content of /persist
flash-platform-images-sbj.sh : will flash all the device-specific blobs into their specific partition (as normally defined in the android standards) : /firmware, /drm, and several other partitions.


If you've chrooted from recovery, remember to exit and umount everything in reverse order.