Spent an entire day just compiling a kernel with audio codecs for my cherrytrail laptop, first on my server for 9ish hours, then on my laptop, ended up deleting it all and starting over, because the final folder was 20+ gigs big (without modules) and the next instruction was to transfer all those files to what is a 32gb laptop, so I thought I fucked up, now searching more, it seems I just need the vmlinuz file once it compiled, I guess I'll compile it all again...

@Floydian haha thanks, though there's definitely much harder problems than this 😁

Easy way out (which I usually use):

Boot from stock distribution kernel which usually compiles everything and their entire bloodline in as a module, to support all configurations.

If it boots and supports your audio, you're golden. Arch is preferred for builds, Ubuntu is shit for this purpose.

Now get the stable kernel source, its GPG signature, unxz and GPG verify. Extract, cd to it and run the following "kinda magical" command: make localmodconfig.

Keep in mind that you should have all the devices that your new kernel config should be plugged in and have their drivers loaded. Otherwise you'll have to get used to kernel config tutorials in Gentoo Wiki (which btw aren't all that bad! They helped me a lot).

And when that's done, make nconfig and edit whatever that previous command generated (well, a .config but I'm talking about its configuration) to your liking. Often times on Arch I end up doing things like deleting suffix -ARCH as well as removing things like HAM radio support (which to this day I still don't know why every config keeps that enabled by default).

Further tweaks can be done, but that should give you a baseline. Once you're able to compile and boot off of that, you're golden. Now you can start Muntzing features away from the kernel and continue optimizing that way.

@Floydian It's sometimes hard to tell, especially with something so innocent 😅

@Condor I have generated a .config already with menuconfig, now I am compiling it on the server and will see what all I have to transfer out of those 20gigs, but as much as I could now gather its just the modules folder and vmlinuz, hopefully that should be it 😅

@Floydian Life is hard at times bro. Stay strong

@JoshBent well yeah modules, headers and vmlinuz (the kernel itself) is what you should retrieve and install. Don't forget to generate an initramfs / initrd for it as well. Kernels initially mount that as their temporary rootfs, then mount the actual rootfs (your system's /) to /new_root and then pivot_root to that.

Point is, you need that initial rootfs, be it initrd or initramfs - it doesn't matter. Distributions often tend to prefer one or the other as part of their design, but a kernel can't live without one of these (unless you've got no modules at all that are required to further boot up the real rootfs, but that's very advanced territory already since it involves manually tweaking the .config). In Arch it's generated by something like "mkinitcpio -k 4.17.5 -g /boot/initramfs-4.17.5.img" (based upon latest upstream kernel today) but on Ubuntu, I honestly don't know. Having seen that I had to install over 2GB of packages to the servers just to solve dependencies (at which dpkg, apt and Debian/Ubuntu really suck!) I ended up bailing out. I've got only 20GB on the servers and really didn't want to waste it on certified shitdesigns from Canonical; just to be able to compile a kernel.

@Floydian I just could not resist 🤣
@Condor I am actually running arch/antergos on my laptop and ubuntu on my server, so I am making it on the server that has better cpu and more ram and then transfer the result to my laptop, especialy because it needs 20 gigs after it is done, just for the some files I need, thanks for mentioning the initramfs thing, I actually read in the arch wiki section for kernel compiling something about it, will definitely check that out once I transferred the files, will also have to search how to point grub properly towards that stuff :)

@JoshBent kernel compilation for Arch based distro is something that I'd really leverage an Arch based system for as well.. Ubuntu does things *very* differently, and in many ways through means that I strongly disagree with. If you really want to use the server for the compilation, perhaps it'd be beneficial to configure a chroot running Arch Linux in it.

A chroot is essentially a fully fledged filesystem structure that is installed on top of your real one, in which / can be readdressed and still give valid locations for everything. So e.g. /bin/bash in your real rootfs could have a similar copy for another distribution in /mnt/bin/bash. Then you can change your root to /mnt, and approach your previous /mnt/bin/bash as if it were actually /bin/bash - its standard location. The only thing that is an issue with chroots is memory - you're using the memory from the host and can interact with it - this is why chroot can't replace VM's for stuff that requires isolation.

But chroot is great for running a Linux system that can but doesn't necessarily need to match your original one - this is how e.g. Linux Deploy works on Androids. And since it inherits both memory (as mentioned above) as well as the host kernel - it's a relatively safe environment to develop certain distro fuckery in, like inits and whatnot. Oh, regarding inits.. systemd as PID 1 /sbin/init is usually inherited as well.

But that's all way beyond the point.. I'm drunk and getting ahead of myself. Chroots are great for dicking around in different distributions from the comfort of your original one. Kernel, memory and init (if systemd) are inherited, which for distribution development but also kernel building for another one can be beneficial.

@Condor I appreciate all that input, knew already about chroot, but never really used it outside of rescuing a raspberry pi or server, might look into chrooting into arch to compile the kernel, but most likely I'll just take whatever it spits out in like 9ish hours again, wonder what could be different from just a make command though? not sure ubuntu or arch as a host would really matter?

@JoshBent Yeah, make commands would be the same but keep in mind that Ubuntu (with its parent being Debian) is notorious for keeping old versions of packages. The kernel needs to be compiled against a certain glibc and won't work on a newer version (due to linkers and stuff like that.. but I'm not very familiar with C so not sure if I'm qualified to comment on this)..

If your Ubuntu host runs the same version of glibc as your Arch host, it might work.. then you can 'make' on your server, then transfer the entire source directory to your Arch host and do the usual 'make modules_install' and 'make headers_install'. But I wouldn't trust it, especially in the long run. Ubuntu and Arch are vastly different, in paradigms, release scheme, update cycles, everything. Even BlackArch vs Arch can give conflicts sometimes in their updates, and those are both fast-paced and ran on the Arch philosophy.. but their release schedules are ever so slightly different. Imagine that but on distros with vastly different designs and you've got a recipe for disaster.

Chroot is something very interesting to look into, especially for development. If at all possible to deploy on your Ubuntu server, highly recommended!

@Condor hm, I see, I hope it won't cause any issues then, would be a pain having to recompile on an arch install, I could probably also just setup an arch VM on the server and do it there too (instead of chroot), I just thought it wouldn't matter 😅

@Condor I am kind of stuck, since after compiling the kernel, even freshly fetched and configured, it ends up being 20 gigs and all the instructions imply I would have to transfer all those to what is a 32gig laptop and then do modules_install etc. 😶

@poeske887 no idea what you mean