These days, you rarely have to build your own Linux kernel. You just take what your distribution ships, and it usually works just fine. However, [Andrei] became enamored with a friend’s cyberdeck and decided that he’d prefer to travel with a very small laptop. The problem is, it didn’t work well with a stock kernel. So, time to build the kernel again.
Of course, he tried to simply install Linux. The installer showed a blank screen. You might guess that you need to add ‘nomodeset’ to the kernel options. But the screen was still a bit wacky. [Andrei] likens troubleshooting problems like this to peeling an onion. There are many layers to peel back, and you are probably going to shed some tears.
He did turn to ChatGPT for some help, but found there were many hallucinations, so it was sometimes helpful and sometimes not. What follows is a detective story with many twists and turns.
He finally decided he needed a custom kernel and had to learn the steps. If you haven’t done it, it really isn’t that hard. If you are trying to get “close” to another existing kernel, you can read /proc/config.gz to get a list of how the person who built your kernel set it up (even if that someone was you).
The custom kernel worked. Sort of. The screen finally turned on, but it was rotated 90 degrees. Not too convenient. A few more options paid off. Along the way, he mentions a few common debugging procedures, like divide and conquer or testing kernels on a virtual machine before moving to real hardware.
The culprit turned out to be an errant video module. But… there was still no sound or touchpad. That caused even more detective work that uncovered some confusing documentation. At the end, he has a mostly working machine, although he didn’t have sleep mode, and the machine tends to run hot. He’s ok with that. We often find that we have similar problems with things like orientation sensors, although the situation is improving.
Of course, building the kernel is a far cry from writing new code for it. If you want to get your feet wet, maybe start with an old version. You can even find some automation scripts that help you get straight to debugging your code.
I always build my own kernel. For one I tune the compiler for my processor. Secondly, I build the modules my machine uses into the kernel directly to maximize performance. This leverages huge pages to minimize TLB misses.
I’ve only ever built kernels when I have to, so for embedded devices or because whichever distro I happened to be using at the time didn’t have support baked in for some bit of hardware, as the performance always seem good enough on the stock kernel.
So if you are up for a challenge I’d love to have a modern PC hardware example of built for device vs generic Debian I guess (to give the greatest chance of larger differences) as I suspect in the world of everything is microcode today it makes much less difference than it once did, but I’ve never stumbled across one, nor found the time to do it myself.
ah but have you tried … building your kernel … on youtube??
anyways i don’t build my kernel for those reasons. :) “performance” is a joke, and “maximizing” it even moreso. the performance difference was always pretty modest unless you were literally loading bzImage off of a floppy disk. and it’s pretty much disappeared today. i used to care a lot about getting a kernel under some arbitrary size but it’s just not relevant anymore.
i often do it as a matter of necessity for hardware support. i also don’t generally trust debian to manage the kernel (and the times i’ve decided to trust it, my fears seem to have been confirmed, but i’m a very hard-headed kind of guy). and also, last but definitely not least, i simply don’t like initrd. really, initrd is what i don’t want debian managing…if it’s gonna manage it, it better be flawless. if i have to think about it once, that’s one time too many.
The clue at 9:28 in the video of the native resolution being 800×1280 tells you its a portrait panel. Paying attention to small details like that can shortcut a ton of troubleshooting.
Is building/compiling everything (including the kernel) at install time with Gentoo still a thing? Been a long time since I played with it, but it seems like this would be a good use case.