Compiling your own kernel

It's worth it for me because I find that sort of thing to be fun.

You might get faster boot times and smaller kernel/initrd size, as well as not having to store 100's of useless modules.
Especially if you have EFI-capable firmware, you can enable EFI stub loading and remove GRUB, LILO etc. from your system.

looks like most of you in this thread have not yet installed gentoo.
you should install gentoo.

lmfao

Less attack surface.

Maybe.
It was when I installed gentoo that I first realized how much useless shit is included in the average "default" kernel. SELinux, whether you're using it or not. AGP support for fuck's sake. I haven't had an AGP card in over a decade. Dozens of Ethernet controllers. Drivers for devices, filesystems, and protocols I've never even heard of. "Enterprise" shit. Macintosh drivers. FireWire. I got rid of all of the shit I didn't need and added a few things that I did, like user namespaces for firejail.

Is there much of a point to it? Well, if you compile all of those extra things as modules, but don't actually load them, they take up some disk space, but don't affect performance. They're not loaded into memory. If you compile them into the kernel instead of as modules, then I guess they are sitting there in kernel memory, doing nothing except taking up space. I don't know whether it would have a big impact. I just like the idea of not having a bunch of extra, unneeded garbage hanging around in my kernel binary or in /lib/modules.

Is there a script that scans for all connected hardware and then generates kernel with modules needed to operate only that hardware?
Sorry, I'm a noob.

So, the modules are like having a hybrid kernel? Does offloading them really lower the attack surface?

There may be one (not that I know of) but here's a good way of figuring out which modules to compile: run lspci -k on the livecd. It will tell you what drivers for your wifi, graphics, SATA/PATA, ethernet, sound card etc. to use.
There can not be a script to completely automate the selection of modules because some modules are drivers for removable USB devices, and you need to select these yourself because they can't be detected (because they're not plugged in). If you have weird or non-PC hardware like SDIO wifi adapters, you'll have to look those up yourself because SDIO buses cannot be scanned easily like PCI.
If you enable removable module support, yes. If your system will be hotplugging many devices such as USB, you can remove modules which you aren't using at the moment. But I can't think of a standard situation in which this functionality would be very useful. I usually compile my kernel without module support, because it's simpler, smaller, faster and more secure, along with not needing an initrd.
This approach is only suitable for kernels which will only be used on a single system, but it is in my opinion better than a modular kernel if you are not going to be hotplugging hardware or switching on/off network functionality etc.

Maybe, but I'm not aware of one. When I'm configuring a kernel for unfamiliar hardware, I'll boot up a LInux live distro with lspci and lsmod. lspci will give you a good idea of what hardware you have on your system, and lsmod will list the kernel modules that have been loaded. Assuming everything is working in the live distro, that will give you clues as to what modules you'll need.

Not really. Linus considers "hybrid kernel" more of a marketing term than a technical term. Whether he's right about that or not, Linux kernel modules are loaded into kernel space and operate as part of the kernel. The don't operate in user space and communicate with the kernel by IPC. So "modular monolithic" is probably more accurate.

Not sure what you mean by that.

Not the other user, but maybe you answer these questions too.
1) what is the significance of System.map file? Do you always need to put a new one in /boot where the new kernel is?
2) what is the chance of messing up your kernel source directory when recompiling? is there anything risky? will "make clean" remove something important? Is it a good idea to keep a backup of the kernel source directory from before you ever touched anything there?

It's for debugging. You don't really need it unless you're a kernel programmer (basically it translates a hex memory address into a function name), and I delete it always because I don't need it and it's rather large.
"make clean" isn't dangerous. It only removes the compiler output. However, "make mrproper" can be somewhat dangerous because it also removes your configuration file so you have to start from scratch. If you've spent a long time configuring the kernel, back up the $KERNEL_SOURCES/.config file to avoid having to do it again in case of a fuckup.

make clean will recompile everything from scratch next time you compile. if you just need to add something that you didn't stick in the first time, you can add it with make menuconfig, and then just run make, and it'll only compile the shit you added, not the entire kernel again.

i don't know how smart make really is though, so I usually just run make clean everytime.

Yes because if you enable the trimming of kernel symbols/functions you literally remove uneccessary functions from the kernel except for exactly what you need. Less functions/symbols = less attack surface. But if anything can make kernel calls its preety much over already because they would have root or something like that.

I run a really minimal system. My kernel compiles in less than a minute on my shitty laptop.

How is that possible? I have a fairly shitty laptop from 2012 and I've spent hours autistically flipping kernel options to find out what I can get away with. My kernel compiles in around 5 minutes. What can I switch off?

The OpenBSD devs recommend against it, but I still compile a custom kernel. It's nice.

Or SCSI disk support since it's required for a lot of SATA shit. I've lost count of how many people I've helped with compiling Linux who've been undone by this. I mean it makes sense to uncheck it (who uses pure SCSI disks anymore on desktops?) but it can be a bit confusing.

I use a custom minimal kernel with support for only the things I want. My friend (we're both gentoomen and always assist eachother in configuring some kewl new thing we found) claims the responsiveness of my system is amazing.

When is 16bit legacy support coming back to mainstream kernels?

Probably never, user.

Joke's on you, when I originally installed Gentoo, all the "standard" kernels past 3.13 froze during boot. Actually, that was the reason why I installed Gentoo in the first place. Configuring one's kernel is a standard practice so people were willing to help, instead of the useless "if the official package doen't work for you, you must be doing something wrong" crap.

I'd have just fixed the engine.

Just install Arch GNU/Linux

Attached: Screenshot from 2018-04-28 15-39-33.png (1680x1050, 61.57K)

Stupid me, I should've just ripped the dgpu out of my laptop, instead of configuring the drivers to work properly. Why didn't I think of that?

Attached: it was just bloat anyway.webm (427x240, 1.53M)

No. I mean switching to Gentoo instead of just compiling the kernel.

Shit was pissing me off anyway.

Maybe for system admins and engineers that have to have performance and security tweaks for hundreds of identical systems. Or you need a feature that is not stable or running some kind of odd hardware.

Customized a kernel for xen vga pass-through in debian. Took a few tries but I finally got some solid info from a centos admin on executing "the debian way" properly. So after install actually showed some noticeable improvement in gaymen and general responsiveness of the system before pass through.
Another time I needed to enable NUMA support for my centos labrig and it showed some improvement. Pretty simple as long as you follow the RH documentation.
So yeah just find a decent guide for the relevant distro, make a lvm snapshot then go for it.

lol stupid ricer faggot enjoy x crashing any time you update

Don't do that. The best opsec is to download the security patches, patch your sources, and recompile. This way you can be certain that the software installed are compatible without additional garbage.

...

Hurd

Never understood this argument. If someone can either physically access your computer to load dodgy modules or otherwise load them with a root exploit you've got bigger problems than a few useless mods.

enjoy your 0.02% performance boost that won't matter because you fried your CPU to death faggot

It's not about performance. It's about maintaining a system of comptaible software.

Did you not read that part?

No, and what if you mess it up? Stick with the official OS like OSX or Windows 10. Don't go mucking around with this stuff you aren't authorized for.

If you got adequate cooling the CPU outlast everything else in your computer.

Before compiling your own kernel, make sure to compile your own open source firmware and BIOS shit.

Attached: childpepe.png (604x516, 88.41K)

this but also
Curious what goes into a kernel? Yes

tried linux-ck for awhile and tried trimming the kernel down as much as possible for my neet use case. menuconfig is awesome and so are the kernel module comments

was alot of fun, but all in all i learned the default is perfectly fine for general use, they designed it that way.

nconfig is the new hotness.

I've been an Arch GNU/Linux user for about 6 years now and I've never experienced any problems due to pacman -Syu. X also never crashed.
Also I don't do ricing.

or xconfig, gconfig and qconfig if you you're an xorgfag, gnomefag or kdefag respectively.

...

meme tragic

clifags never cease to amaze me with their reckless autism.

lol because you don't understand what the kernel is

Try again. This time with actual arguments.

We can't all be unemployed basement-dwellers whose mothers deliver them tendies every 2 hours for sustenance. Bless you, NEETanon. Keep the way of make config! The rest of us wagie losers will use ncurses or X-based configuration interfaces.