I have a Google Pixel XL (marlin) device here with Android 11 (/e/OS 1.16-r-20231020343335-dev-marlin). Ich know that at least /e/OS U for this device available. Is it possible to upgrade the device - preferably without loosing all data (backup exists, of course). Is there a guide available, about how to do this?
Personally I would go for a clean install – the official advice would have been Clean install for each upgrade, but there was always a certain understanding of what you could get away with on certain devices say r → s → t.
There was a change to builds from A 13 (T) where for most devices vendor firmware partitions were now included in the build, so this became a bit safer. /e/ discontinued any Upgrade pages. They used to be based on the Lineage templates as Upgrade LineageOS on marlin | LineageOS Wiki … these Lineage pages contain the best guide … but what you can and cannot get away with changes with each build. Personal speculation possibly /e/OS builds are more sensitive to residual parts (in the case of dirty upgrade) than the equivalent Lineage build.
With a jump from /e/OS v1, A 11 (R) through 12, /e/OS v2, Android 13 (T), to a14 and /e/OS version 3 (plus it is unknown if the phone is running entirely problem free and has no adverse “history”) you are bound risk running into some sort of problem (with easy or difficult fix) without a clean install, imho; more importantly the device will probably run latest that is e-3.0.1-a14-20250607498954-community-marlin.zip very well and it is nice to have a clean phone with no potential hangups going forward.
having debugged why upgrades fail at times, it can hinge on little, entirely preventable changes. Imo one should give it a shot but have backups. In doubt it’s just another step two resetting userdata.
If an individual app acts up after upgrade (crashes) and couldn’t migrate, clearing its storage is synonymous to starting on a clean userdata with that app.
One might reasonably feel that one could make each of the upgrades individually on a phone that one knew quite well. What would be the method? One Android version at a time (but intermediate builds are not shown available) test for 3 or 7 days and deal with adjustments then the next upgrade. To attack the Upgrade all in one I might expect errors to compound in a way that might well take time and knowledge to fix, perhaps to include a Format data, what’s the chance of that? >25%?
I did make it clear that this would be my personal route for an easy life and good “hygiene”.
I understand your conservative stance being informed by experience, it’s certainly good policy, but if the code has a migration for its own database A11->A12, that migration will also run if you jump A11->A15. Ofc you can unearth other bugs unrelated to system-app migration (that take down the main thread). At times upstream Lineage itself say userdata cannot be preserved.
“Have backups, but jump releases” would be my motto to not make the upgrade too time consuming jumping individual release versions (and still fail).
The thing with backups, they can’t be made easily in <A14. What I mean is: a dav* tether and files.
For later readers preferring to be less “conservative” there are many threads found with Search Dirty upgrade many fully successful others which might mention known pitfalls and hazards.