I have migrated to new SfOS devices a few times. Soon it’s going to happen again. This time I want to be sure I migrate everything after I installed SfOS on the new device. I want to continue right where I left off, with little manual effort.
So far I think I need:
- a complete backup of the /home partition to SDcard which can be drop-in replaced as the new home folder. Yes, I have done this succesfully between same models. Unless you’re switching architectures (32/64bit) I don’t see a problem here, but this time I’m going to switch from X 10 II to X 10 III, could there be pitfalls?
Anyhow, this covers - as far as I can see - everything that all backup apps offer.
- additionally I’d like
- a list of all repositories and all installed applications, preferably in a format that allows easy reinstallation
- configuration that happens outside of /home - I know SfOS does this, e.g. lipstick, ambiences etc.
This also includes Patchmanger configs and possibly other apps.
Any more ideas?
Or maybe that magic script that does it all already exists? My search-fu did not vibe. (On a side note, the forum search does not seem to work well. E.g. a search for “talteen” returned nothing even though I saw it mentioned at least once)
I repeat, currently popular apps like My Backup and Talteen do not go outside the /home partition afaics. Of course the ideas gathered here could then be suggested to the devs.
6 Likes
I saw that. Really nice commands there, but all that also happens if you just move your defaultuser.bak to defaultuser (I did it in recovery).
edit: do not do this across different (Xperia) models! See #14
I have meanwhile found out that
- most libzypp (packagemanager) settings are in /etc/zypp, so addding selected or even all config in /etc could be eligible for drop-in replacement
- With zypper (needs to be installed) one can export & restore repos like this:
zypper lr -e all.repo and zypper ar -r all.repo
1 Like
You don’t need that, all you need is /etc/ssu/ssu.ini, fetch repository-urls from there
if you want to restore installed packages first gather them by running zypper se -i, then some multiline string manipulation in sublime and you’ll get list of packages, just skip the ones from adaptation repositories
As to restoring /home, i’m running /home that’s originated from 32bit g2 on op6 and now miami
Ambiences are in /home, the only thing you’ll miss is if something puts config in /etc and none of sfos apps should do such a thing
Also I’ll leave my rsync backup script for others who want to backup from time to time
#!/usr/bin/env bash
args=(
-e "ssh -i /home/nemo/.ssh/id_rsa"
--rsync-path="rsync --fake-super"
-axHAX
--delete
--delete-excluded
/
--exclude="/dev/*"
--exclude="/proc/*"
--exclude="/sys/*"
--exclude="/tmp/*"
--exclude="/run/*"
--exclude="/mnt/*"
--exclude="/media/*"
--exclude="/lost+found"
--exclude="/data/*"
user@server:/backup/x2
)
rsync "${args[@]}"
5 Likes
Thanks for the tip re ssu.
But that rsync script is not really what I’m looking for. It makes a full system backup. What I’m looking for is everything that is necessary to restore when migrating, after SfOS is installed on the new device.
I’m sure you read my OP only diagonally.
full /home backups is a great soln, though it takes a bit. i have had issues restoring /home/.appsupport data, so you might want to make a few crucial android app backups if you have any, jic.
i do a bottom-up soln, personally, which contains explicit backups to restore rather than backing up the entire home partition. your top-down soln is better, IMO, for sane people. i routinely reflash my phone and restore from scripts (partly to test stuff and develop, and partly to make sure that my backup/restore process is reliable). this flashing backup is the same as my daily backup, and part of this backup is my every-2h-backup-over-4g. (here is my collection of scripts for backup+restore GitHub - teleshoes/sx-config: Sailfish X phone config · GitHub if you want to look at it for some reason)
i think i have a pretty good place to answer your question from, and my conclusion is that i am pretty sure there just isn’t anything not covered by /home, except for packagekit and edited config files which should be covered by zypper se -i + ssu.ini + patchmanager for you. (and also microsd, but you arent flashing that)
1 Like
Same to you 
Because as I said
A thought popped into my mind: Android uses a different numerical user id for each app. It seems to assign them in order, so after migration, re-installing Android apps, they might have been assigned a different id and therefore do not have write access to the data.
Could be fixed with a chown after restoring.
Anyhow I still need to find a way to list all installed Android apps, better than just lsing
/home/.appsupport/instance/defaultuser/data/data/.
should be covered by zypper se -i + ssu.ini + patchmanager
Yes, patchmanager has a config in /etc but also puts patches in /usr/share. I wonder if the config is enough, and it then re-downloads the patches.
There was at least one more thing putting configuration or otherwise changing data under /usr/share, if I could remember that I’d say my research is complete.
There will of course be things I don’t deem eligible for migration, like passcodes and fingerprints.
The idea is still to make migration between SfOS devices as complete as feasible, after SfOS has been flashed to the target device.
1 Like
The only thing I didn’t manage to restore is wifi passwords, I think they’re somehow tied to device ID.
And also passwords in my musikilo app same as every other app that relies on hardware id, will not work
Listing all installed Android apps:
appsupport-pm listFull
This is good because it also shows stuff relevant to the SFOS side of things.
But it’s a little limited; this command shows much more:
devel-su appsupport-attach sh -c 'cmd package list packages -f -3 -i -U'
Theoretically this would allow me to extract the .apks even. This is not required because they’re stored/installed under /home/.appsupport.
1 Like
I have added my backup script to my sfos repo. Apart from the extra bits outlined above it’s all about what the file ~/.config/backup.sh/pre_tar_saves includes.
Currently it only includes
/etc
/usr/share/patchmanager
I guess one could make an effort to try to include fingerprint data and account credentials, but I don’t believe it would work.
Restoring the whole shebang on the new system will show me if manual effort can be reduced further.
I restored things outside /home manually. It was not 100% hassle free and a little messy tbh but definitely worth the effort.
But migrating Android apps worked 100%!
Note for next time: include /usr/share/lipstick*, esp. /usr/share/lipstick-jolla-home-qt5/launcher/* (menu).
Understand ssu.
1 Like
Yeah, no, this did not work well at all.
At first it seemed seemless, but soon I started getting
And possibly one or two other connected glitches, e.g. with Patchmanager or Advanced Camera.
Just to be clear, the script presented here is still super useful, you just can’t restore indiscriminately, at least not across devices.
I should’ve done more troubleshooting, but I just gave up and a) reinstalled stock Android (12) and b) flashed 5.1. from scratch. Now at the very least the audio problems are gone.
1 Like
I remember I had a 
moment here on initial read, because I tried the same thing on X10II → III migration, and discovered each Android app gets installed with unique uid/gid on different devices.
So unless you can somehow map those on the new device, it’s just not going to work out of the box.
Seems way more hassle than worth, I’ve just bit the bullet and reinstalled Android apps, restoring their individual databases in each app to the best of their instrumentation.
Some things are cloud synced, those obviously restore the easiest.
With some small python script that reads uid/gid from the new files and then apply that to those with the same name in backup files it should not be a big hussle. And such script could be universal.
Well the thing is that I didn’t even have to reinstall Android apps, they were just there, working, with launcher icons etc.
And seemed to work perfectly at first glance.
I actually really only noticed something was off when I later installed OsmAnd+ and it complained about no read and/or write access to certain folders, and trying to troubleshoot that on the road without my laptop quickly got way too daunting.
And I’m sure tar and mv did not change permissions while restoring.
As usual Android is way too intransparent there; I have noticed this many times and it was ultimately the reason I dropped it in favor of a real mobile Linux.
1 Like