Root Cyanogenmod12.1 Build Environment Set-Up

[scary alien]

I've queried @scary alien about this. He is trying to formulate (script) a way that will allow logs to run during bootup, so we can look at them for errors. I know I could use it.

Ah, my apologies, @HasH_BrowN...I hit a brick wall with my research re. this .

The boot animation hijack that I thought would work seems to not to, unfortunately.

I do think you could update the boot.img file to install the logcat capture (that's about as low-level as you can (or should need to) go), but I haven't done/tested this on any of my devices--I'll try to this weekend .

 

[MrMike2182]

Ah, my apologies, @HasH_BrowN...I hit a brick wall with my research re. this .

The boot animation hijack that I thought would work seems to not to, unfortunately.

I do think you could update the boot.img file to install the logcat capture (that's about as low-level as you can (or should need to) go), but I haven't done/tested this on any of my devices--I'll try to this weekend .

I actually tried to do this exactly and when I went to boot it after compiling it wouldn't even go past the first HTC splash screen.. Maybe I'm doing it wrong?

 

[scary alien]

I actually tried to do this exactly and when I went to boot it after compiling it wouldn't even go past the first HTC splash screen.. Maybe I'm doing it wrong?

Not sure, Mike--I'm still pretty baffled that some of the things I tried with the boot animation didn't work (I even wrote a custom binary (executable) to replace the boot animation file and its actions did not seem successful).

I'll have to do more monkeying around with a test device this weekend if I can find time (been a very busy last couple of weeks).

Cheers!

 

[MrMike2182]

Not sure, Mike--I'm still pretty baffled that some of the things I tried with the boot animation didn't work (I even wrote a custom binary (executable) to replace the boot animation file and its actions did not seem successful).

I'll have to do more monkeying around with a test device this weekend if I can find time (been a very busy last couple of weeks).

Cheers!

If I happen to get anywhere with mine I'll share it here but as of right now, it's not working out yet. Thank's for taking time to help!

 

[MrMike2182]

Not sure, Mike--I'm still pretty baffled that some of the things I tried with the boot animation didn't work (I even wrote a custom binary (executable) to replace the boot animation file and its actions did not seem successful).

I'll have to do more monkeying around with a test device this weekend if I can find time (been a very busy last couple of weeks).

Cheers!

I guess that this line, in the default.prop (persist.sys.usb.config=adb) doesn't really seem to help anything! A friend of mine did say that it is possible to build logcat right into the boot.img and thats actually what he does himself! So, he's going to show me how when he has some free time and I will post it here so others can try it out!

 

[MrMike2182]

Would adding this to the kernel config help anything?

For debugging while hardware bringup, you can enable..

CONFIG_PANIC_TIMEOUT=5
CONFIG_ANDROID_RAM_CONSOLE=y

 

[HasH_BrowN]

Would adding this to the kernel config help anything?

For debugging while hardware bringup, you can enable..

CONFIG_PANIC_TIMEOUT=5
CONFIG_ANDROID_RAM_CONSOLE=y

I don't know, which I why I ask:

• How do they affect or bring about debugging?
• Wouldn't that be running at the wrong time?
• Wouldn't that be debugging "hardware" and not the running of the "booting rom"?

 

[MrMike2182]

I don't know, which I why I ask:

• How do they affect or bring about debugging?
• Wouldn't that be running at the wrong time?
• Wouldn't that be debugging "hardware" and not the running of the "booting rom"?

It could mean that but I'm not sure that's why I asked because I just ran into that while I was reading another users git.

 

[scary alien]

Okay guys, I think I got something for you .

Fairly simple / straightforward.

I just tested this on my Nexus 5 and it works:

1. Take the boot.img file for your device

2. Unpack it, modify the ramdisk's init.rc file so that the bootanim section is changed like this (at least this is what my N5 looked like):

before:

service bootanim /system/bin/bootanimation
class core
user graphics
group graphics audio
disabled
oneshot
​

after:

service bootanim /system/bin/logcat -f /cache/logcatsnapshot.txt -d
class core
user root
# group graphics audio
disabled
oneshot​

i.e., your changing the bootanimation entry to:

a) invoke the logcat utility instead of the actual boot animation
b) run as root instead of the graphics user/group​

3. Re-pack newly modified ramdisk and your kernel into a new boot.img

4. Flash or softboot the new boot.img file and reboot

5. When the device reboots or otherwise hangs, at the point that the init.rc file tries to invoke the boot animation, a logcat snapshot will be written to the /cache/logcatsnapshot.txt file (change the name as you will)

6. If your device bootloops, then boot into your custom recovery and examine the /cache/logcatsnapshot.txt file for clues about the bootloop.

Lemme know if you guys have questions.

 

[HasH_BrowN]

Okay guys, I think I got something for you .

Fairly simple / straightforward.

I just tested this on my Nexus 5 and it works:

1. Take the boot.img file for your device

2. Unpack it, modify the ramdisk's init.rc file so that the bootanim section is changed like this (at least this is what my N5 looked like):

before:

service bootanim /system/bin/bootanimation
class core
user graphics
group graphics audio
disabled
oneshot
​

after:

service bootanim /system/bin/logcat -f /cache/logcatsnapshot.txt -d
class core
user root
# group graphics audio
disabled
oneshot​

i.e., your changing the bootanimation entry to:

a) invoke the logcat utility instead of the actual boot animation
b) run as root instead of the graphics user/group​

3. Re-pack newly modified ramdisk and your kernel into a new boot.img

4. Flash or softboot the new boot.img file and reboot

5. When the device reboots or otherwise hangs, at the point that the init.rc file tries to invoke the boot animation, a logcat snapshot will be written to the /cache/logcatsnapshot.txt file (change the name as you will)

6. If your device bootloops, then boot into your custom recovery and examine the /cache/logcatsnapshot.txt file for clues about the bootloop.

Lemme know if you guys have questions.

You should make a thread out this. This is good stuff.

I've got a bunch of questions. Lol. But for now only one (maybe two)
In step 5 when init.rc invokes bootanimation, wouldn't that snapshot be before it goes and loops? So the culprit wouldn't be acknowledged at that time of boot, because the bootanimation has already started prior to the loop. Is there a way to delay the snapshot or request a snapshot on halt (stop, error, etc.)?
Or am I looking at it wrong?

 

[scary alien]

You should make a thread out this. This is good stuff.

Thanks

(I might )

I've got a bunch of questions. Lol. But for now only one (maybe two)
In step 5 when init.rc invokes bootanimation, wouldn't that snapshot be before it goes and loops?

Not sure...that depends on when the boot loop occurs, of course .

Now that you mention it, I'm a little worried that a true "looping" behavior here would re-invoke the boot animation call, although a small amount of research I did seems to indicate that the bootanimation code receives a signal to stop, so that worry may be unwarranted.

So the culprit wouldn't be acknowledged at that time of boot, because the bootanimation has already started prior to the loop. Is there a way to delay the snapshot or request a snapshot on halt (stop, error, etc.)?
Or am I looking at it wrong?

I'm not sure if you're looking at it wrong--we probably have to see some actual examples of a bootlooping behavior (I know of a couple of ways of forcing a bootloop, but I would almost think that the nature and consequence of each might be different on a case-by-case basis).

Also, lemme do a little more testing where I'll have the logcat just "run" and not terminate after the "-d" dump behavior.

Also, lemme try building a binary that can sleep for a given period of time and then invoke the logcat (or optionally dump the kernel log (cat /proc/kmsg), etc.).

But let me know if you actually get a chance to try it .

 

[scary alien]

Okay, not much testing needed .

Changing the logcat invocation to simply drop the "-d" parameter causes the logcat to continuously record, all the way through a full, successful boot:

service bootanim /system/bin/logcat -f /cache/logcatcontinuous.txt
class core
user root
disabled
oneshot​

In fact, after the boot completed, I had to find and kill the logcat process's pid to stop the recording.

Lemme try to force a bootloop by deleting my build.prop file (a seemingly common faux pas ) and seeing what happens.

Back soon.

 

[scary alien]

Okay, forcing a boot loop by deleting the build.prop file (renaming it, really) hosed things up before the "bootanim" service apparently gets called, so there was nothing logged from that particular boot loop.

So, I'm guessing that would likely be true of other loops, too--i.e., the "damage" is done before this fairly late piece of code (i.e., the boot animation or its replacement) is invoked.

There are other boot/init debugging tools available, but I'm not familiar with them nor have I researched them in any detail to this point.

 

[HasH_BrowN]

In fact, after the boot completed, I had to find and kill the logcat process's pid to stop the recording.

So for a bootlooping device, that would capture everything? Only if it fully boots, it would then need to be killed?
In effect, that would be a "semi" proper way of logging the bootloop?
Okay I'll give a go tomorrow.

 

[Curtis1973]

So for a bootlooping device, that would capture everything? Only if it fully boots, it would then need to be killed?
In effect, that would be a "semi" proper way of logging the bootloop?
Okay I'll give a go tomorrow.

In regards to rom ports and them hanging during boot screen and never booting...if you are connected to pc you'll see that the actual point where the rom is about to boot but hangs is where the pc recognizes the usb connection,the pc will recognize the connection,but the windows prompt for opening the storage never appears and if you leave the pc connected while its hung you can visibly tell windows keeps getting the usb connected signaling. In a good boot,right after that detection is made the rom boots almost at the same time windows opens the usb/internal storage prompt.. So maybe starting log just before the rom starts the usb services would trim log size and narrow the range of detecting the exact cause of boot failure. Not sf the boot failure is related to storage detection or that is just a symptom of something else failing. But there is some thing to it. Because all the roms that fail have this in common among them.

 

[scary alien]

So for a bootlooping device, that would capture everything? Only if it fully boots, it would then need to be killed?
In effect, that would be a "semi" proper way of logging the bootloop?
Okay I'll give a go tomorrow.

Not 100% confident that a logcat invoked at the same place as the boot animation is triggered by the init.rc would capture the proper information from a boot loop as I experienced last night from a purposely wonked-out build.prop file (renamed).

I tried moving it up/earlier in the init.rc file, but didn't see anything recorded--guessing that the logcat "environment" was not yet ready/prepared.

I'm guessing that the bootanim step is later/after the component that is causing the looping issue (for this specific case, of course).

If the device does fully boot, then yeah, you'd want to kill the logcat afterwards and make sure you remove it from the test/debug boot.img file's init.rc (i.e., it's only needed / necessary to try to debug a bootloop issue).

Like I indicated, I did see some other things that might be helpful/useful for boot debugging (there were some init.rc - specific tools mentioned somewhere), but I can't speak to those at this point.

 

[LeGiT_dIaMoNd]

Seems like we need more people developing for our device,
Maybe you dont know how to set up the build environment...

Step 1- Download and install latest Ubuntu or LinuxMint (x64 is needed)

Step 2- Download Script and extract , then open script with text editor and edit "Your Email Address" and "Your Name" (keep the quotes)....Save file and check permissions to allow executing file as program

Step 3- Run script in Terminal, say Y when needed

Step 4- Get some coffee or clean the house (repo sync takes a while)

Thats really all there is to setting up the build environment... now you just need the trees

Step 5- Download the Device/Kernel/Vendor trees for our device (rename as necessary)

Once you are confident you have the trees set up correctly...

Step 6- Open Terminal and cd to the Cyanogenmod12.1 Directory

Step 7- run

. build/envsetup.sh && brunch x5

I just re-installed LinuxMint (wiped everything), but had this script for setting up Pac-rom, just modified it to suit my needs...Originally made by Metallica on XDA

My Device,Kernel,Vendor trees as of 5/28/15
frameworks/base/data/keyboards is a fix for back an menu key vibration

How did we get the device blobs for this device. I'm hoping back into the developing community but I'm lost on extracting/fetching the blobs required. I remember a bit that LG didn't give us this so how did we get a hold of it?