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
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
It didn’t 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
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 …
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 ?
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
Probably worth its own thread, but a couple of points
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.
I’m not sure where those notes come from - I don’t recall writing them .
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
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
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?
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.