[SOLVED] Build for lilac wont run - eventually reboots to TWRP

[petefoth]

Thanks. Yes, the last time I had this, when I was first building for lilac, it was because I was picking up vendor files from a repo that wasn’t maintained. I fixed it by extracting the blobs from a running device as described in that link. I put them in a repo that I have been using successfully ever since. Not sure why this would have changed, but it may be time to do it again

[petefoth]

@petefoth

but it may be time to do it again

I think I need to do this when attached to a running device?

[smu44]

you can extract them from a Lineage (or /e/ ) ROM zip : https://wiki.lineageos.org/extracting_blobs_from_zips.html

Also, sorry for my link above, it leads to non-existent sources
Better link : https://github.com/whatawurst/android_device_sony_lilac

[petefoth]

@smu44

you can extract them from a Lineage (or /e/ ) ROM zip : https://wiki.lineageos.org/extracting_blobs_from_zips.html

Yes, I looked at that first time around and decided it was easier to extract from a running device Just flashed an unofficial LOS ROM to give it a try

@smu44

Better link : https://github.com/whatawurst/android_device_sony_lilac

That’s the repo that all my stuff is based on, so this should work

[smu44]

Fingers crossed, it will work

I just launched a build using the “sausage” roomservice, just in case you need to compare something …

[petefoth]

@smu44

Fingers crossed, it will work

It didn’t extracted vendor files identical to what is in my repo. Built ROM refuses to boot in exactly the same way

I just launched a build using the “sausage” roomservice, just in case you need to compare something …

What is the “sausage” roomservice?

I’m going back to building my unofficial ROM (rather than the custom one I’m working on) and see if that works. (I wish I had a clue what is going on and why a build made on 4th May worked fine, but ones made on the 5th and onwards refuse to boot)

[smu44]

“sausage” like “Wurst” in German (from “whatawurst”), sorry for the poor word play

I don’t have an explanation either for what happened with your 5th may build
For your information the build I have currently running is using release v1-q, I’ll keep you posted as soon something happen …

[smu44]

@petefoth

It didn’t extracted vendor files identical to what is in my repo. Built ROM refuses to boot in exactly the same way

If a previous build runs fine, it’s not a device problem.
Better guess that a repo get corrupted, involving LOS as well … or a building computer issue ?

[petefoth]

@smu44

“sausage” like “Wurst” in German (from “whatawurst”), sorry for the poor word play

I need to lighten up. Should have worked that out - I do speak enough German to know what Wurst is.

I’ve got back to a working build (using builde.sh) and I’ll work from there. Thanks for your help

[petefoth]

Sorted now. Thanks for the help and advice

@petefoth

[EDIT] Problem found and solved

The problem came about because I made a local change to my device.mk which I did not commit to git. All was OK until I did a repo sync --force-sync which lost the local change and made some other changes which ended in a mismatch between what fles should be present in the ROM and what files were actually present
Moral: don’t ignore repo sync failure messages and don’t use --force-sync unless you really don’t want whatever local changes you have made

[smu44]

Happy to read that you sorted it out !

If you’re not Luke, the Force may not be your luck

[smu44]

Just for your information : docker build with Wurst roomservice failed :

16:22:56 Build sandboxing disabled due to nsjail error.
device/sony/yoshino-common/BoardConfigPlatform.mk:143: error: device/qcom/sepolicy-legacy-um/SEPolicy.mk: No such file or directory

[mike_from_ireland]

Sorry to revive this thread.

Having same issue on Z5C trying to upgrade from e18-Q to e21-R.
Followed these notes

Found older thread here

But not sure what the solution is.

[petefoth]

Probably worth its own thread, but a couple of points

1. There is a problem with the 0.21-r build reported in this thread. It has been fixed, but the fix won’t be available until the v0.22 build. If you need your hotpsot to work, then don’t flash the v0.21-r buiild.

@mike_from_ireland

Followed these notes

2. I’m not sure where those notes come from - I don’t recall writing them .
3. This post describes the steps I have used to successfully ‘dirty flash’ R ROMs over an existing Q installation: Week 36 : Development and Testing Updates - #11 by tcecyk
4. If the dirty flash doesn;t work, then you should format - not just wipe - the data partition in TWRP before flashing the R ROM. Then reboot the device and go through the first time setup, before restoring teh data backup and following steps 2 and 3 in the linked post
5. I have never tried the process of upgrading Q → R and going to the next /e/OS version (i.e. 18-q to 21-r). My testing involves upgrading Q → R with the same /e/OS version (i.e. 21-q to 21-r). It shouldn’t make a difference, but I would always update tp the latest /e/ version before upgrading

@mike_from_ireland

Found older thread here

6. The problem in that thread is (almost certainly) a completely different problem, even though the symptoms may be the same

@Manoj We will need to do something about the misleading and wrong ’ /e/ OS Version Upgrade’ documentation for suzuran and z3c. I don’t recall reviewing them, and they contain some pretty serious errors and omissions Please can you add a warning to those pages that they are not reliable, and following them may cause problems with the upgrade?

[Manoj]

Hi @petefoth, as discussed on the channel Pl share your version of the upgrade guide for the devices you maintain. I shall have that included in the Documentation.
I have raised this issue with the developer who maintains the code for the Documentation and will have it updated for all documents. There were some code level changes recently which broke the flow in the Upgrade documents. Will need to rework the upgrade guides.

[mike_from_ireland]

@petefoth

There is a problem with the 0.21-r build reported in this thread.

I was reading that thread as adb sideload was doing it’s thing… unlucky timing but not a biggy as the battery on my z5c doesn’t last long anymore so it’s not my DD - which I do use hotspot on a lot.

Will try to upgrade to 22Q and then 22R with your notes above.

[petefoth]

OK. I’m working on a Q → R upgrade document, so I’ll be interested to hear how you get on. Good luck

[tcecyk]

(@petefoth isn’t the workaround in backlog#3712 supposed to be no longer needed? I didn’t test yet, but it is marked resolved and saw changes)

[petefoth]

@tcecyk

isn’t the workaround in backlog#3712 supposed to be no longer needed? I didn’t test yet, but it is marked resolved and saw changes)

Yes that is true - it’s a while since I’ve looked at this.

I was able to dirty flash suzuran from Q → R but doing so means that SeedVault is not enabled in the R ROM, when it is supported after a clean install.

I was not able to successfully dirty flash z3c, the other official device I support.

And for lilac, the question does not arise, since I cannot produce an up-to-date R build

I will be creating a new forum post about this, and raising the issue in the development team to find a way of supporting the ‘upgrade from Q → R without losing user data’ use case

[petefoth]

@Manoj

Hi @petefoth, as discussed on the channel Pl share your version of the upgrade guide for the devices you maintain.

Please see this post:
https://community.e.foundation/t/howto-upgrade-q-r-suzuran-z3c/38666

@Manoj

I have raised this issue with the developer who maintains the code for the Documentation and will have it updated for all documents.

I think that those documents should be pulled for now, especially as it is not yet possible to upgrade Q → R without losing at least some user data and/or access to some Android R functionality. More thought needs to go into how to manage the upgrade process, and the process should be tested thoroughly beforeit is published: the current process is an undocumented mess, and not good enough (in my humble opinion )