I'm having trouble flashing my userdebug build after following the build guide and install guide exactly. Im flashing from the stable branch of 2024032500 to the userdebug version of the same release that I built using the guide. Idk why but after using flashall it automatically reboots and then gets stuck on the Graphene OS boot logo for a long time. Any fixes or ways to debug this? Everything in fastboot seems fine during flashing, but when I boot up the build it takes more than 5 minutes so I had to force restarted back to the bootloader and flash a stock user build. Still tryna flash this other build, idk why it's not working.
Stuck on boot screen after flashing debug build
zombiekitty527 I'm having trouble following the description of what was tried and what is happening. It might help to go over things in strict chronological order, and also good to indicate exactly which steps were taken.
With respect to ordering, the post first mentions "automatically reboots and then gets stuck", and then describes "seems fine during flashing, but when I boot up the build...". It's hard to tell whether what is being described is two incidents or one.
The description doesn't say which lunch command was used to configure the build. The description says "after using flashall", but the install guide doesn't say to use flashall. No details are provided about which release of which OS was used to do the build, etc.
I suspect that if a knowledgeable person will be able to help it will be necessary for there to be a description which is detailed and in strict temporal order.
- Edited
@de0u No problem, here's a more precise description of what's happening:
I Installed 2025032500 update for Pixel 8a. Unlocked bootloader and rebooted to fastboot.
ran "fastboot flashall -w" in fastboot. Everything flashes successfully (see the logs below)
$ fastboot flashall -w
--------------------------------------------
Bootloader Version...: akita-15.2-12862154
Baseband Version.....: g5300o-241205-250127-B-12973597
Serial Number........: 46011JEKB00414
--------------------------------------------
Checking 'product' OKAY [ 0.000s]
Checking 'version-bootloader' OKAY [ 0.000s]
Checking 'version-baseband' OKAY [ 0.001s]
Setting current slot to 'a' OKAY [ 0.105s]
[liblp] Partition system_a will resize from 0 bytes to 1492357120 bytes
[liblp] Partition system_dlkm_a will resize from 0 bytes to 11038720 bytes
[liblp] Partition system_ext_a will resize from 0 bytes to 510648320 bytes
[liblp] Partition product_a will resize from 0 bytes to 763224064 bytes
[liblp] Partition vendor_a will resize from 0 bytes to 756035584 bytes
[liblp] Partition vendor_dlkm_a will resize from 0 bytes to 26292224 bytes
Sending 'boot_a' (65536 KB) OKAY [ 1.377s]
Writing 'boot_a' OKAY [ 0.275s]
Sending 'init_boot_a' (8192 KB) OKAY [ 0.173s]
Writing 'init_boot_a' OKAY [ 0.037s]
Sending 'dtbo_a' (16384 KB) OKAY [ 0.346s]
Writing 'dtbo_a' OKAY [ 0.062s]
Sending 'vendor_kernel_boot_a' (65536 KB) OKAY [ 1.433s]
Writing 'vendor_kernel_boot_a' OKAY [ 0.267s]
Sending 'pvmfw_a' (1024 KB) OKAY [ 0.024s]
Writing 'pvmfw_a' OKAY [ 0.012s]
Sending 'vendor_boot_a' (65536 KB) OKAY [ 1.401s]
Writing 'vendor_boot_a' OKAY [ 0.263s]
Sending 'vbmeta_a' (8 KB) OKAY [ 0.001s]
Writing 'vbmeta_a' OKAY [ 0.007s]
Erasing 'userdata' OKAY [ 0.142s]
Erase successful, but not automatically formatting.
File system type raw not supported.
Erasing 'metadata' OKAY [ 0.014s]
Erase successful, but not automatically formatting.
File system type raw not supported.
Sending sparse 'super' 1/14 (254972 KB) OKAY [ 5.485s]
Writing 'super' OKAY [ 0.986s]
Sending sparse 'super' 2/14 (254972 KB) OKAY [ 5.443s]
Writing 'super' OKAY [ 0.953s]
Sending sparse 'super' 3/14 (254972 KB) OKAY [ 5.421s]
Writing 'super' OKAY [ 0.929s]
Sending sparse 'super' 4/14 (254972 KB) OKAY [ 5.426s]
Writing 'super' OKAY [ 0.965s]
Sending sparse 'super' 5/14 (254972 KB) OKAY [ 5.426s]
Writing 'super' OKAY [ 0.940s]
Sending sparse 'super' 6/14 (254972 KB) OKAY [ 5.454s]
Writing 'super' OKAY [ 0.923s]
Sending sparse 'super' 7/14 (254972 KB) OKAY [ 5.428s]
Writing 'super' OKAY [ 0.959s]
Sending sparse 'super' 8/14 (254972 KB) OKAY [ 5.458s]
Writing 'super' OKAY [ 0.937s]
Sending sparse 'super' 9/14 (254972 KB) OKAY [ 5.407s]
Writing 'super' OKAY [ 0.925s]
Sending sparse 'super' 10/14 (254972 KB) OKAY [ 5.400s]
Writing 'super' OKAY [ 0.946s]
Sending sparse 'super' 11/14 (254972 KB) OKAY [ 5.401s]
Writing 'super' OKAY [ 0.924s]
Sending sparse 'super' 12/14 (254972 KB) OKAY [ 5.388s]
Writing 'super' OKAY [ 0.953s]
Sending sparse 'super' 13/14 (254972 KB) OKAY [ 5.397s]
Writing 'super' OKAY [ 0.953s]
Sending sparse 'super' 14/14 (161564 KB) OKAY [ 3.432s]
Writing 'super' OKAY [ 0.611s]
Erasing 'userdata' OKAY [ 0.094s]
Erase successful, but not automatically formatting.
File system type raw not supported.
wipe task partition not found: cache
Erasing 'metadata' OKAY [ 0.013s]
Erase successful, but not automatically formatting.
File system type raw not supported.
Rebooting OKAY [ 0.000s]
Finished. Total time: 93.094s- When the device reboots, I it gets stuck on the Graphene OS boot animation, without loading into the OS. My only option here is to force reboot the phone and completely reflash to a known stable build.
I'm not sure what exactly is causing this, but I highly suspect that something is happening to cause it when I flash the 'super' partition. After the first 'frozen boot screen' I actually tried flashing boot.img, vendor_boot-debug.img, and vbmeta.img seperately and it works totally fine. The vendor_boot-debug.img was kind of interesting, because it gave me root adb shell access on a 'user' build when I didn't have it before (cannot use adb root on production builds). Didn't know this was a thing until now. Anyways, soon as I tried to flash 'system.img' on top of this setup, I started having the same issue that I described in the notes above. I suspect it's either that I'm missing something about properly flashing the super partition (i.e. system partitions), or perhaps my bootloader is not equipped to flash debug builds (with ro.secure = 0). Idk if the bootloader makes any difference, but it's the only other thing I can think of - I used the same bootloader from the 2025032500 stable build because my debug build is based on this version.
de0u The lunch command was akita-cur-eng while inside the repo for 2025032500 by the way (I forgot to mention). Some of the images are working if I flash them individually with the stable images on grapheneos.org (for example the recovery).
zombiekitty527
fastboot flashall -w
This is the second time you have mentioned this, so I will point out again that I don't think that is part of the GrapheneOS installation directions.
zombiekitty527 I actually tried flashing boot.img, vendor_boot-debug.img, and vbmeta.img seperately [...] As soon as I tried to flash 'system.img' on top of this setup, I started having the same issue that I described in the notes above.
Now I am completely lost, because the original post included "I'm having trouble flashing my userdebug build after following the build guide and install guide exactly". But it seems as if many things are being attempted that are not part of the build/install directions?
de0u Well, to be honest I tried to ask this in off-topic at first lol. But everything comes from the Graphene OS build guide up until that point. For the flashing part, I used this official documentation: https://source.android.com/docs/setup/test/running.
Quite honestly, this documentation is almost useless because it only talks about fastboot flashall -w. Since this failed for me, I was experimenting with different partitions like this https://source.android.com/docs/core/tests/vts/vts-on-gsi. Which is how I got the root adb shell on a user build.
I figure that this might by no man's territory. But if there's someone out there who can help me or point me towards some improved fastboot documentation, it would be helpful. I really want to avoid flashing the new bootloader unless necessary; I've bricked an old phone in the past doing this through trial and tribulation. I'm no stranger to fastboot and the bootloader, but the situation seems unique with Pixel series and the new A/B slots - a lot has changed since the Nexus days. I noticed my bootloader says things like 'secure-boot PRODUCTION' and 'nos-producetion: yes', I'm not sure if this would prevent me from running a non-production debug/eng build.
I only know I can get back to stock with Android Flashtool or the web installer as long as I don't mess with the bootloader. In general I've been leaving that alone. Worst case scenario, I think I can flash the 'eng' bootloader to the other slot and test it first without bricking my phone.
zombiekitty527 I figure that this might [be] no man's territory. But if there's someone out there who can help me or point me towards some improved fastboot documentation, it would be helpful.
That would not be me, I'm afraid. It's still not clear to me what you are trying to accomplish.
zombiekitty527 I really want to avoid flashing the new bootloader unless necessary; I've bricked an old phone in the past doing this through trial and tribulation.
If the goal is to flash an up-to-date GrapheneOS with an old bootloader, that might be the source of the problem. I believe that every now and then a new OS release requires a new bootloader release.
de0u I'm trying to get an eng build because of its extra leniency when dealing with certain things and dlkm. I want to port NetHunter to the Pixel 8a (I already have a working build) but ran into issues while flashing the new eng build. I'm open sourcing my work as well, once it's done.
If the goal is to flash an up-to-date GrapheneOS with an old bootloader, that might be the source of the problem. I believe that every now and then a new OS release requires a new bootloader release.
This is what I'm trying to figure out right now. It's true that an OS needs a new bootloader every once in a while, but is there difference between 'user' (for production builds) and 'eng' (for debug builds) bootloaders for the same release of Android? I know that my bootloader is the same because fastboot 'flashall' is designed to check if it's the correct version when flashing a new OS. Apparently 'flashall' is designed to make sure everything is compatible, but I still keep seeing bootloops, despite fastboot not throwing any critical errors. I have the correct bootloader for the 'user' release of the same Android version.
zombiekitty527 I'm trying to get an eng build because of its extra leniency when dealing with certain things and dlkm. I want to port NetHunter to the Pixel 8a (I already have a working build) but ran into issues while flashing the new eng build.
I am definitely not qualified to advise on that. I suspect you might be better off with one of the development chat rooms.
That said, I think it would be advisable to be very clear and open about your goals and processes from the start. This thread begins with a claim of trouble "flashing my userdebug build after following the build guide and install guide exactly", but apparently what is being pursued is not userdebug builds and certainly not following any GrapheneOS guidance "exactly". Among other things, it appears that, for an undisclosed reason, a different bootloader than GrapheneOS uses (for this version of the OS) is being used. With respect to dynamically loaded kernel modules, my vague understanding is that the GrapheneOS project views them as an undesirable security risk.
With respect to whatever might be achieved via this effort, it is probably good to be aware of the project's guidance on the use of the GrapheneOS logo and trademark.
de0u Of course. I don't plan on releasing an OS or anything that uses Graphene's code. I'm using Graphene for development because of its enhanced sandboxing capabilities and memory management abilities.
For the bootloader I'm not sure if this would qualify as an official or unofficial bootloader - I built it from unmodified source. It would be coming officially from either AOSP or Graphene OS, since it was bundled with my eng build. Right now I'm using the official one from the Graphene OS download section, which seems to be recognized as the "correct version." I don't know if this bootloader is equipped to handle an eng build.
If I end up with a fully working NetHunter for Pixel phones, I'll report here if appropriate (in off topic or in the third party software section.) I want to see if DLKM can be used for activating "monitor mode" without installing an entire precompiled kernel. I may also post in XDA forums if this would be more appropriate. Obviously this is meant for rooted devices, but I'll be following the least restrictive GPL licenses from Kali as far as open source goes. This is a personal project Im working on for fun.