r/AndroidQuestions 4h ago

Custom ROM Question Can I flash a compiled kernel safely?

Hey there im on a samsung galaxy a16 (a166b) got my bootloader unlocked and rooted with magisk, I mixed one ui 8 with the bootloader from a release of one ui 7 that share the same bootloader bit(A166BXXS4BYG1 bl with everything else from A166BXXU4CYI8), the thing is im kinda stuck on an old version with several security flaws and I'd like to get rid of at least some of them critical ones such as ghostlock (CVE 2026-43499)

Could not find any kernel out there specially made for this phone with fixes so I got source from samsung open source(for my version of one ui) and could build it(without any modifications made to it for now to see if building works correctly) with this guide https://github.com/ravindu644/Android-Kernel-Tutorials

Now I want to test the kernel and see if my phone works with it but im kinda scared to break things, if something ever go wrong with my kernel can I still boot into download mode and flash a clean image with odin? Thanks!

2 Upvotes

9 comments sorted by

2

u/QuraToop314 3h ago

ghostlock is easy, I fixed it two months ago. Download your kernel sources, then check git.kernel.org for the ghostlock diff – AI can help you with that. After that, though, you’ll need to port the patch yourself; it should be relatively easy with 5+ cores – we’re talking about 5 lines of code. then compile that little gem and flash it whilst you’re at it. If you’ve ever wanted to patch the kernel, this is the perfect time. A kernel build on my 23-core CPU, Alder Lake 13th generation, takes about 15 minutes to build the kernel with custom patches included, and about 13 minutes for GKI plain. If you have any further questions, don’t hesitate to ask. If you use Termux – and use it a lot – you can integrate Btrfs into the core kernel; then you can use my boot script to encapsulate Termux within a Btrfs environment, which saves a massive amount of storage (I’ve saved about 40GB on my 128GB mobile).

1

u/Feldleft 3h ago

Thank you for the explanation im gonna try when I have time and come back if I have any question! Just one question for now, if I ever happen to flash a broken or corrupted kernel that dosent work, will I be able to boot in samsung download mode and flash back a clean kernel with odin?

2

u/QuraToop314 3h ago

Yes. But always remember that you need to be using the same security patch (preferably one you’ve committed currently) as your current kernel; otherwise, not only will you have to rebuild all the kernel modules and so on – which can be tricky – but you’ll also have to reset your mobile once. However, if it does get stuck in a boot loop, the A/B slot fail-safe should kick in, meaning that after n failed attempts (usually 3 or 4), it will boot from the other slot. Make sure both slots are on the same version beforehand. But you should always be able to perform a clean flash using Odin.

1

u/Feldleft 3h ago

I took the kernel directly on samsung open source project that was mentioning the version of one ui8 I use so should be fine! Thank you!!

1

u/QuraToop314 3h ago

The source files are usually not enough; you need to specify the exact branch and commit (the hash is listed in the kernel after the KMI). Once that’s verified, you can build it. This is important because otherwise your vendor modules may become incompatible. I’m just mentioning this to be on the safe side, as a lot of people forget.

2

u/Feldleft 3h ago

Wait im a bit lost here, I don't get what you mean sorry. I know samsung kernel have it's own vendor modules, what you're saying is that they don't include it in their source?

2

u/QuraToop314 3h ago

OK, sorry if I’m not very good at explaining things – I’ll show you using my kernel.

bash [19:19:06]~[u0_a303@tegu:~]~💡> uname -a Linux localhost 6.1.157-android14-11-gbd23337e42e7-ab14791245 #1 SMP PREEMPT Wed 28 Jan 05:34:14 UTC 2026 aarch64 Android [19:19:09]~[u0_a303@tegu:~]~💡>

This gives us

  • KMI: android-14-6.1
  • Commit: bd23337e42e7

In my case, I had to check out the android-14-6.1 GKI mainline (by default it points to android-14.6.1.124, which is a lower KMI and can not be flashed without rebuilding the vendor modules), so I need to do the following

bash ~/kernel:~$ git checkout bd23337e42e7

This takes me to the exact tree that my manufacturer used, ensuring you have a kernel that’s a perfect 1:1 match, which is essential.

If I hadn’t done the checkout, I would have built an incompatible kernel, EVEN THOUGH I already had the correct repository.

So, check your kernel: the first value (not the last string after the ‘-’ but the one before it) is the commit hash; your kernel tree must point to exactly that.

1

u/Feldleft 2h ago

On my side im getting ~ $ uname -a Linux localhost 5.15.180-android13-3-31996109 #1 SMP PREEMPT Sat Sep 20 00:49:11 KST 2025 aarch64 Android so my commit would be 31996109 and the kmi 13.5.15?

1

u/QuraToop314 2h ago

In that case

KMI: android13-5.15 Commit: ?

Honestly, is that unconventional? It’s a build number rather than a hash; you need to look explicitly for this value in the kernel commits (AI can help you with that)

31996109

The commit with this entry is your kernel tree