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

I’ve been struggling for days to make am /e/ custom build that boots, but it keeps re-booting to twrp. I see the following warnings in my build output, but I don’t know whether they might be causing the problem

DEPMOD 4.4.247-whatawurst+
make[1]: Leaving directory ‘/home/pete/srv/custom/out/target/product/lilac/obj/KERNEL_OBJ’
make: Leaving directory ‘/home/pete/srv/custom/kernel/sony/msm8998’
depmod: WARNING: could not open modules.order at /home/pete/srv/custom/out/target/product/lilac/obj/PACKAGING/depmod_vendor_intermediates/lib/modules/0.0: No such file or directory
depmod: WARNING: could not open modules.builtin at /home/pete/srv/custom/out/target/product/lilac/obj/PACKAGING/depmod_vendor_intermediates/lib/modules/0.0: No such file or directory

In the past, this error has been a problem with the vendor blobs, but nothing has changed there since my most recent custom build.

I have tried formatting data before installation. Always wiping cache and dalvik before booting.

Any other ideas?

[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 :slight_smile:

Full dmesg.log here: https://ecloud.global/s/pfqPwHEioxM9gRx
I don’t realy know what I’'m looking for but I’ve had a quick scan and pasted possible interesting bits at https://pastebin.com/81kW4mdn

Looks like missing drivers or bad hardware source :thinking:

Found this from XDA (see local manifest), if it can help …

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

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

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

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

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

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

Fingers crossed, it will work :slight_smile:

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

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

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)

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

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

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 ?

:slight_smile: 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

Sorted now. Thanks for the help and advice

1 Like

Happy to read that you sorted it out ! :slight_smile:

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

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

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.

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.
  1. I’m not sure where those notes come from - I don’t recall writing them :slight_smile: .
  2. 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
  3. 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
  4. 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
  1. The problem in that thread is (almost certainly) a completely different problem, even though the symptoms may be the same :slight_smile:

@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 :frowning: Please can you add a warning to those pages that they are not reliable, and following them may cause problems with the upgrade?

1 Like

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.

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.

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