Database Info

[Q] Personal CM 12 build gets stuck on boot

** Was not sure where to post this.
Today I was successful in building CM 12 for the first time using Docker on Ubuntu 14. The build went fine but when I try to flash my phone with the cm-12-2015-02-01.zip file the flashing goes fine without any errors but when I reboot the device it gets stuck on the Google boot screen and doesn't process to the CM boot screen. I have tried doing a full clean flash, as well as wiping cache(s).
This does not happen if I try flashing an official build from the CM site. This has something to do with my build but I cant figure out what because the build goes fine when I run it.
Thanks for the help in advance

Did you make sure you're building for hammerhead?

Lethargy said:
Did you make sure you're building for hammerhead?
Click to expand...
Click to collapse
Yes I definitely built for hammerhead.

waleed_k said:
Yes I definitely built for hammerhead.
Click to expand...
Click to collapse
Try running a repo sync and rebuild

Hi,
Did you figure it out? We are running into the same issue, build in plain Ubuntu is fine, but if we build in Docker container, then the phone stuck on boot screen.
waleed_k said:
** Was not sure where to post this.
Today I was successful in building CM 12 for the first time using Docker on Ubuntu 14. The build went fine but when I try to flash my phone with the cm-12-2015-02-01.zip file the flashing goes fine without any errors but when I reboot the device it gets stuck on the Google boot screen and doesn't process to the CM boot screen. I have tried doing a full clean flash, as well as wiping cache(s).
This does not happen if I try flashing an official build from the CM site. This has something to do with my build but I cant figure out what because the build goes fine when I run it.
Thanks for the help in advance
Click to expand...
Click to collapse

Still have not figured this out.

I think this is a generic issue about building Android in Virtual Environment (chroot, lxc, docker).
I know that someone else says that Android can be built in VE without any problems, in our company, we do have some Android projects which can be built in VE without any problems too, but somehow, some projects cannot, hope that someone knows Android and VE better can help on this.
waleed_k said:
Still have not figured this out.
Click to expand...
Click to collapse

[AOSP 6.0] Device not booting

Hi devs, this question is especially for you guys! So I tried to build AOSP 6.0 for my D6603 and the build itself was succesful but after flashing the boot, system and userdata IMGs, the device takes about 2sec before the Sony screen shows up and after 1sec the device reboots. I have followed the instructions on developer.sonymobile.com for the m-preview and changed the repo to the final 6.0_r1 branch, this is the only step I've made differently. First I used the blobs for the m-preview and after that, bc the build showed the mentioned symptoms, the ones for lollipop just to try it. For both the same result. So my question is, is it because of an bug in the aosp branch, was it a noob fault because I'm new to building roms or is it because I didn't use blobs for the final release (which aren't released yet)? Is there any way to resolve the problem by myself?
Info: I also tried using the boot.img from cm and other roms
bye

KERNEL COMPILE HELP Black Screen after flashing new kernel for CM13

Hi,
I have the note 10.1 (n8010) I am currently using Lirokoas CM13 build
The kernel that comes with this ROM is this https://github.com/littlelerroyy/android_kernel_samsung_n80xx
However I want to use this kernel instead (is newer, has f2fs support, want it for the basis for new modifications, etc) https://github.com/littlelerroyy/android_kernel_samsung_smdk4412
I have cloned the cm13 branch and compiled using the cyanogenmod_n8013 deconfig.
When i flash using the ramdisk supplied by the stock kernel. The system doesnt bootloop, it simply shows a black screen and never boots.
I need to know what I could be missing or what i need to start to do to fix this issue. Please ask any relevant questions, All suggestions welcome.
Cheers.

Flashing procedures for Pixel using clean 8.1.0_r38 build

Hi,
I'm looking for clarification on the proper flashing procedure of an unmodified home built version of the 8.1.0_r38 branch for the Pixel. I want to be sure I'm actually doing the flashing correctly.
This image was built on Ubuntu 18 after grabbing the 8.1.0_r38 branch directly from Google along with the correct corresponding Vendor image and driver files. As I said earlier no modifications or customizations were made to the source. It was a straight clean 8.1.0_r38 build.
The flashing procedure I had been using was as follows
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash userdata userdata.img
fastboot flash vendor vendor.img
These are the same steps I've been using since going back years. Here's the reason why I'm seeking verification on the flashing procedures.
Once flashed to the Pixel the device suffers a catastrophic failure running CTS. One module, the CtsAppSecurityHostTestCases module, has a test that causes communication with the device to stop and the device is left in an unusable state because the test put a number lock screen on the device and obviously I don't know the pass code.
I have tried numerous branches of Android 8.0 and 8.1 and they all run into this issue with this module on the Pixel when running CTS.
But the Factory images from Google do not exhibit this issue nor did an OEM Verizon Pixel. They all complete CTS without a problem.
So this is why I'm looking at the builds I'm making as the problem. But I'm not doing anything out of the ordinary with the builds...just a straight source build/ensetup.sh, lunch, and make once I copy the (unzipped files in the) Vendor folder over to the repo.
So that leaves two possibilities as far as I can tell.
Possibility 1: The images that are being built, even though I have got everything I can get from Google for them, are missing something in the driver/vendor area that's tripping up CTS.
Possibility 2: I'm not flashing my images correctly for this device. I started wondering about that when I pulled apart the Factory image for the Pixel to see what it was flashing and how it was flashing it. I'm specifically thinking about system-other.img, which I don't flash. But my understanding of system-other.img is that it's not strictly needed since it's for recovery purposes. So maybe that doesn't matter.
Since trying to eliminate Possibility 1 is all but impossible from where I'm at, I'm attacking Possibility 2. So this is why I'm seeking clarification on what the proper flash procedures are for a clean build of 8.1.0_r38 is on the Pixel.
Thank you for your time.

dswalen said:
Hi,
I'm looking for clarification on the proper flashing procedure of an unmodified home built version of the 8.1.0_r38 branch for the Pixel. I want to be sure I'm actually doing the flashing correctly.
This image was built on Ubuntu 18 after grabbing the 8.1.0_r38 branch directly from Google along with the correct corresponding Vendor image and driver files. As I said earlier no modifications or customizations were made to the source. It was a straight clean 8.1.0_r38 build.
The flashing procedure I had been using was as follows
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash userdata userdata.img
fastboot flash vendor vendor.img
These are the same steps I've been using since going back years. Here's the reason why I'm seeking verification on the flashing procedures.
Once flashed to the Pixel the device suffers a catastrophic failure running CTS. One module, the CtsAppSecurityHostTestCases module, has a test that causes communication with the device to stop and the device is left in an unusable state because the test put a number lock screen on the device and obviously I don't know the pass code.
I have tried numerous branches of Android 8.0 and 8.1 and they all run into this issue with this module on the Pixel when running CTS.
But the Factory images from Google do not exhibit this issue nor did an OEM Verizon Pixel. They all complete CTS without a problem.
So this is why I'm looking at the builds I'm making as the problem. But I'm not doing anything out of the ordinary with the builds...just a straight source build/ensetup.sh, lunch, and make once I copy the (unzipped files in the) Vendor folder over to the repo.
So that leaves two possibilities as far as I can tell.
Possibility 1: The images that are being built, even though I have got everything I can get from Google for them, are missing something in the driver/vendor area that's tripping up CTS.
Possibility 2: I'm not flashing my images correctly for this device. I started wondering about that when I pulled apart the Factory image for the Pixel to see what it was flashing and how it was flashing it. I'm specifically thinking about system-other.img, which I don't flash. But my understanding of system-other.img is that it's not strictly needed since it's for recovery purposes. So maybe that doesn't matter.
Since trying to eliminate Possibility 1 is all but impossible from where I'm at, I'm attacking Possibility 2. So this is why I'm seeking clarification on what the proper flash procedures are for a clean build of 8.1.0_r38 is on the Pixel.
Thank you for your time.
Click to expand...
Click to collapse
You can eliminate possibility 2 by doing this: after you run your lunch command, instead of just running 'make', run 'make otapackage'. This will create a flashable zip, then you can just flash it like so:
Flash the latest factory image
fastboot TWRP
Wipe system, both caches, and data
Flash the zip that was made from 'make otapackage'
Flash twrp
reboot recovery
Flash the vendor image. <- flash the one from this link, just to eliminate problems
flash gapps
reboot
Also, AOSP is very different than Google's factory images (It doesn't include all of googles closed source stuff).

shagbag913 said:
You can eliminate possibility 2 by doing this: after you run your lunch command, instead of just running 'make', run 'make otapackage'. This will create a flashable zip, then you can just flash it like so:
(snip)
Also, AOSP is very different than Google's factory images (It doesn't include all of googles closed source stuff).
Click to expand...
Click to collapse
Thanks. I'll try this but I have a very hard time believing Google would deliberately release source (AOSP) that when compiled blows up its own CTS test. I suppose it's possible but speaking as QA, it would bug the heck out of me if I let my company release something that breaks one of our own tools.

dswalen said:
Thanks. I'll try this but I have a very hard time believing Google would deliberately release source (AOSP) that when compiled blows up its own CTS test. I suppose it's possible but speaking as QA, it would bug the heck out of me if I let my company release something that breaks one of our own tools.
Click to expand...
Click to collapse
It turns out I don't need to do this after all. Android 9's CTS does not display this issue so that means the problem, whatever it is, is either the result of Android 8/8.1s AOSP being deficient in some manner or the Android 8/8.1 CTS test suite being wonky somehow. Either way the problem is not the result of something I was doing wrong since I used the same steps with Android 9 and it didn't display the issue.

Pixel (sailfish) bootloop (blackscreen after logo)

Ok, so I bought a used Pixel and it just blackscreens and bootloops after the Google logo. I can access bootloader/recovery mode and flash firmware, but whatever I do, it won't go past the logo. Seems like a hardware defect to me, anything I can do myself?

Try to install stock boot.img

Song0329 said:
Try to install stock boot.img
Click to expand...
Click to collapse
Like I said, can still get into recovery and bootloader, so I've tried flashing all official firmwares form 7 to 10, Lineage OS and PixelDust to no avail.

Velcorn said:
Like I said, can still get into recovery and bootloader, so I've tried flashing all official firmwares form 7 to 10, Lineage OS and PixelDust to no avail.
Click to expand...
Click to collapse
Try clean flash:
1. Download twrp.img
2. Fastboot boot twrp.img
3. Wipe advance,check all except sdcard and otg
4. Reboot recovery
5. Install stock rom
If still bootloop...smash your android to the ground :laugh:

Song0329 said:
Try clean flash:
1. Download twrp.img
2. Fastboot boot twrp.img
3. Wipe advance,check all except sdcard and otg
4. Reboot recovery
5. Install stock rom
If still bootloop...smash your android to the ground :laugh:
Click to expand...
Click to collapse
Tried all of it multiple times. I'll probably take the last advice
Edit: Not giving up on this device yet. Got it to boot Lineage 18.0 and managed to complete the setup. Still freezes up after 30-60 seconds though. Here are screens of the setting and BL info:

Velcorn said:
Tried all of it multiple times. I'll probably take the last advice
Edit: Not giving up on this device yet. Got it to boot Lineage 18.0 and managed to complete the setup. Still freezes up after 30-60 seconds though. Here are screens of the setting and BL info:
Click to expand...
Click to collapse
mine is doing the exact same thing. did you fix it?

i think thats hardware defect, mine doing aswell. dont know what to do.
cant boot to main screen, cant go to recovery mode, locked status. doom

BakolteLo said:
i think thats hardware defect, mine doing aswell. dont know what to do.
cant boot to main screen, cant go to recovery mode, locked status. doom
Click to expand...
Click to collapse
Mine keeps going into a boot loop. after flashing so many OTAs and factory images I was able to get it to boot on 7.1 nougat. Knowing me I can't leave well enough alone I decided to fast boot boot twrp. Once again boot loop. Now when I boot it it says writing to ext4. Ugh

Does anyone know if a 32 GB motherboard would fit in the 128 GB frame?

I had bought a used Pixel (sailfish) back in October of 2020 and it was perfectly fine until November where it ran into the bootloop problem. I had tried various things but what worked for me was disabling the 3rd and 4th cores of the processor.
I have read that the Nexus 6p and 5x had this problem where the heavy Snapdragon cores of these models (5th and 6th, being hexa-cores) were causing the bootloop and disabling them avoided the problem.
I haven't heard of this problem as far as the 1st gen Pixels are concerned but tried it anyway. Short story is that I had to download the factory images from google, modify the boot.img (using an application in linux, had to install ubuntu in my windows 10 laptop). Setting maxcpus=1 and boot_cpus=0 yielded the best result (in terms of not running into a bootloop), though maxcpus=2 and boot_cpus=0-1 also was a fairly stable setup. Since then I've been using the Pixel, mainly for the camera, but even with the dual-core setup, performance has taken a significant decline (shots would take several seconds, sometimes > 10s in HDR+ on) but for the price, definitely workable. No bootloops nor restarts since.
Perhaps try this if you're out of options. Best of luck.

gengriffron2 said:
I had bought a used Pixel (sailfish) back in October of 2020 and it was perfectly fine until November where it ran into the bootloop problem. I had tried various things but what worked for me was disabling the 3rd and 4th cores of the processor.
I have read that the Nexus 6p and 5x had this problem where the heavy Snapdragon cores of these models (5th and 6th, being hexa-cores) were causing the bootloop and disabling them avoided the problem.
I haven't heard of this problem as far as the 1st gen Pixels are concerned but tried it anyway. Short story is that I had to download the factory images from google, modify the boot.img (using an application in linux, had to install ubuntu in my windows 10 laptop). Setting maxcpus=1 and boot_cpus=0 yielded the best result (in terms of not running into a bootloop), though maxcpus=2 and boot_cpus=0-1 also was a fairly stable setup. Since then I've been using the Pixel, mainly for the camera, but even with the dual-core setup, performance has taken a significant decline (shots would take several seconds, sometimes > 10s in HDR+ on) but for the price, definitely workable. No bootloops nor restarts since.
Perhaps try this if you're out of options. Best of luck.
Click to expand...
Click to collapse
Hey, I'd love to try this; any chance you have a more in-depth guide on how to modify the boot image? What application to use, etc.?
EDIT: Through some extensive googling came across this guide which explains how to do this for the G4. So I just downloaded the latest marlin factory image, extracted the boot image from that, and followed the steps.
If you're on Win10/11 you can install WSL2 and via the Ubuntu distro get abootimg via
Code:
sudo apt install abootimg
Then copy the boot.img file to your ubuntu distro's home folder and run
Code:
abootimg -i boot.img
Copy the entire cmdline from the output and simply append
Code:
maxcpus=1 boot_cpus=0
to the start of the parameters, then run
Code:
abootimg -u boot.img -c "<cmdline>"
where <cmdline> is your edited cmdline output.
For me (Marlin, latest A10 image) that was
Code:
abootimg -u boot.img -c "cmdline = maxcpus=1 boot_cpus=0 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=marlin user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 [email protected] loop.max_part=7 buildvariant=user veritykeyid=id:34e81e2c57675086f628c1b2e4b4ade8e0a1941d"
Then it'll write to the same boot.img file with which you can try
Code:
fastboot boot boot.img
with the Pixel XL in fastboot mode to see if it'll work. I haven't tested the boot image yet, will report back here if it works.