Custom Linux kernel not working.

[Gat Pelsinger]

So because of some of my previous problems, I thought to try and compile my own kernel and see if that fixed the problem I had. I already tried multiple times but I end up getting some kind of error after frying my CPU for 2 hours. This time I thought to use the stock settings that are given after compiling the menuconfig. Magically, it compiled way faster this time. I did get an error regarding the "make install_modules" command I had given, but that is probably because I did not keep any modules to compile? Regardless, it said that my bzImage was ready.

 

First of all, I had a doubt because the image was inside the x86 folder, not the x86_64 (well there was a symlink only, and without any other files). Is that normal?

 

I then copied the image and updated grub, but when I selected my custom kernel, it only outputted the loading text and then the cursor kept blinking (perhaps not even blinking and froze, I don't remember). I waited a while but the boot process didn't advance. I can hear my fans going out so either it was actually doing something, or just stuck in a meaningless loop?

 

I am booting through Arch with the custom kernel's version being 6.8.1. Got it from - https://www.kernel.org/. I ran "sudo make menuconfig -j8" (8 threads is all I have), just saved the default config, and ran "make -j8 && sudo make install_modules -j8". Just realizing why I didn't run the make command as sudo, but well, it did compile.

 

Was I really supposed to go and include all my drivers and other components, or am I missing something?

[wasab]

You dont need to do sudo make unless you need to moved binary into some root restricted directory, which is common for /bin or /opt that many make install script moves the compiled binary to. It all depends on what commands the make file is running. You can open it up and read it. 

 

https://github.com/xiangsgao/Academics/blob/main/CSE_376_Advanced_UNIX_Porgramming/job-submission-system/Makefile

 

This is a simple make file script I created for a school project. You can see here, if I run make, it will just run server and client commands plus chmod on the two compiled executables which if you look underneath, they just run gcc to compile two binaries I am telling it to. 

 

I can also run make clean which if you read underneath, it is just running a rm command to delete the compiled binaries. 

 

Make install would probably run a mv command to move the compiled binary to somewhere in your enviorment path which likely need root access which is why you usually run make install with sudo. 

 

Btw, if you grab and compile from source from that link, it is not a custom kernel, it is about as vanilla as it gets. There can be many reasons why your computer won't boot. First off, have you move the kernel to the /boot dir?

[Gat Pelsinger]

13 minutes ago, wasab said:

First off, have you move the kernel to the /boot dir?

Followed exactly what this guy told (of course, excluding all the Kernel configuration)- 

So yes, I did move it.

[10leej]

The kernel probably didn't work because a needed driver module is disable in makemenuconfig.

[Gat Pelsinger]

5 minutes ago, 10leej said:

The kernel probably ly didn't work because a needed module is disable in makemenuconfig

yeah I thought so. I would have to go and enable stuff in the config I guess.

[wasab]

2 hours ago, Gat Pelsinger said:

yeah I thought so. I would have to go and enable stuff in the config I guess.

note that newest kernel may not work perfectly or even boot. i once used a repo for downloading/installing the newest kernel on ubuntu. the newest one unsurprisingly wouldnt boot and i had to go into recovery mode to revert the kernel back. 

[Ralphred]

5 hours ago, Gat Pelsinger said:

but when I selected my custom kernel, it only outputted the loading text and then the cursor kept blinking (perhaps not even blinking and froze, I don't remember). I waited a while but the boot process didn't advance.

Sounds like the GPU driver was missing.

5 hours ago, Gat Pelsinger said:

make -j8

This is the only time you have to use -jX, it isn't really going to be of any benefit other times.

 

The easiest thing to do regarding making sure all the drivers you need are included is taking the module names in use from Kernel driver in use: [name] from lspci -k output. You can then use / to search for these names when in menuconfig - the result will direct you to the option you need to turn on.

During rebuild, unless something in your tool chain has changed, or some error, you only need to re-run make -j8 and install the kernel and modules; it will automatically not rebuild the stuff it doesn't have too because of your config changes, and subsequent builds after adding a single module/driver are much quicker.

 

Other kernel building tips:

• Enable "CONFIG_IKCONFIG" - it's useful to be able to copy a "working" .config on the fly.
• Always run grub-mkconfig -o grub.cfg-[kernel name] BEFORE running grub-mkconfig -o grub.cfg, this will give you backups of known working grub.cfg's later down the line.
• Unless some specific thing has been added to the kernel that you want, make oldconfig (after copying the .config from /proc/config.gz to the new src tree) will nearly always suffice for a "new kernel" when one comes along.
• When you copy bzimage, add a meaningful identifier; grub will still find it and you'll get to have "redundancy" options if you mess something up.
• Backup your .config files to /usr/src/config-x.y.z-[name], that way you can keep your "work" and still delete old kernel source trees.

[Ralphred]

27 minutes ago, wasab said:

the newest one unsurprisingly wouldnt boot and i had to go into recovery mode to revert the kernel back

This is usually due to distro patches being applied to the vanilla source and some test cases falling through the net. I've never had vanilla sources fail when the issue wasn't somewhere outside of the kernel itself (normally PCI devices changing bus addresses between major versions or modular/static kernel configs invalidating other system config files).

[Gat Pelsinger]

9 hours ago, wasab said:

note that newest kernel may not work perfectly or even boot. i once used a repo for downloading/installing the newest kernel on ubuntu. the newest one unsurprisingly wouldnt boot and i had to go into recovery mode to revert the kernel back. 

I am using 6.8.1, the same Arch uses my default.

[Gat Pelsinger]

@Ralphred

 

I was wrong, I am using the 6.8.2 kernel, not the 6.8.1 that Arch uses be default. Is that still okay?

 

Anyways, if I ran the "lspci -k" command, I get all this - 

 

Spoiler

00:00.0 Host bridge: Intel Corporation Comet Lake-U v1 4c Host Bridge/DRAM Controller (rev 0c)
    Subsystem: Hewlett-Packard Company Comet Lake-U v1 4c Host Bridge/DRAM Controller
    Kernel driver in use: skl_uncore
00:02.0 VGA compatible controller: Intel Corporation CometLake-U GT2 [UHD Graphics] (rev 02)
    Subsystem: Hewlett-Packard Company CometLake-U GT2 [UHD Graphics]
    Kernel driver in use: i915
    Kernel modules: i915
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 0c)
    Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem
    Kernel driver in use: proc_thermal
    Kernel modules: processor_thermal_device_pci_legacy
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
    Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Comet Lake Thermal Subsytem
    Subsystem: Hewlett-Packard Company Comet Lake Thermal Subsytem
    Kernel driver in use: intel_pch_thermal
    Kernel modules: intel_pch_thermal
00:14.0 USB controller: Intel Corporation Comet Lake PCH-LP USB 3.1 xHCI Host Controller
    Subsystem: Hewlett-Packard Company Comet Lake PCH-LP USB 3.1 xHCI Host Controller
    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci
00:14.2 RAM memory: Intel Corporation Comet Lake PCH-LP Shared SRAM
    Subsystem: Hewlett-Packard Company Comet Lake PCH-LP Shared SRAM
00:15.0 Serial bus controller: Intel Corporation Serial IO I2C Host Controller
    Subsystem: Hewlett-Packard Company Serial IO I2C Host Controller
    Kernel driver in use: intel-lpss
    Kernel modules: intel_lpss_pci
00:15.1 Serial bus controller: Intel Corporation Comet Lake Serial IO I2C Host Controller
    Subsystem: Hewlett-Packard Company Comet Lake Serial IO I2C Host Controller
    Kernel driver in use: intel-lpss
    Kernel modules: intel_lpss_pci
00:16.0 Communication controller: Intel Corporation Comet Lake Management Engine Interface
    Subsystem: Hewlett-Packard Company Comet Lake Management Engine Interface
    Kernel driver in use: mei_me
    Kernel modules: mei_me
00:17.0 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode]
    Subsystem: Hewlett-Packard Company 82801 Mobile SATA Controller [RAID mode]
    Kernel driver in use: ahci
00:1d.0 PCI bridge: Intel Corporation Comet Lake PCI Express Root Port #9 (rev f0)
    Subsystem: Hewlett-Packard Company Comet Lake PCI Express Root Port
    Kernel driver in use: pcieport
00:1d.1 PCI bridge: Intel Corporation Comet Lake PCI Express Root Port #10 (rev f0)
    Subsystem: Hewlett-Packard Company Comet Lake PCI Express Root Port
    Kernel driver in use: pcieport
00:1d.4 PCI bridge: Intel Corporation Comet Lake PCI Express Root Port #13 (rev f0)
    Subsystem: Hewlett-Packard Company Comet Lake PCI Express Root Port
    Kernel driver in use: pcieport
00:1f.0 ISA bridge: Intel Corporation Comet Lake PCH-LP LPC Premium Controller/eSPI Controller
    Subsystem: Hewlett-Packard Company Comet Lake PCH-LP LPC Premium Controller/eSPI Controller
00:1f.3 Audio device: Intel Corporation Comet Lake PCH-LP cAVS
    Subsystem: Hewlett-Packard Company Comet Lake PCH-LP cAVS
    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel, snd_soc_skl, snd_sof_pci_intel_cnl
00:1f.4 SMBus: Intel Corporation Comet Lake PCH-LP SMBus Host Controller
    Subsystem: Hewlett-Packard Company Comet Lake PCH-LP SMBus Host Controller
    Kernel driver in use: i801_smbus
    Kernel modules: i2c_i801
00:1f.5 Serial bus controller: Intel Corporation Comet Lake SPI (flash) Controller
    Subsystem: Hewlett-Packard Company Comet Lake SPI (flash) Controller
    Kernel driver in use: intel-spi
    Kernel modules: spi_intel_pci
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
    DeviceName: Hanksville Gbe Lan Connection
    Subsystem: Hewlett-Packard Company RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
    Kernel driver in use: r8169
    Kernel modules: r8169
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723DE 802.11b/g/n PCIe Adapter
    DeviceName: WLAN
    Subsystem: Hewlett-Packard Company RTL8723DE 802.11b/g/n PCIe Adapter
    Kernel driver in use: rtw_8723de
    Kernel modules: rtw88_8723de
03:00.0 Non-Volatile memory controller: Intel Corporation SSD 660P Series (rev 03)
    Subsystem: Intel Corporation SSD 660P Series

 

I could not find some items like the "skl_uncore" which is listed as the first driver in use. And for some, there are multiple drivers or stuff in package for example for the i915 driver. Do I install all of them?

[Ralphred]

47 minutes ago, Gat Pelsinger said:

Do I install all of them?

Yes, if you think something may be superfluous configure it as a module, then you can check to see if that module was loaded after booting later and go from there.

47 minutes ago, Gat Pelsinger said:

And for some, there are multiple drivers

Yeah, once you open the configuration tree you'll often find that the "module in use" is a sub-option of the "driver" that you have to enable to get to that option anyway.

The only exception I've seen to this is when using vfio drivers, or the "sub-option" is in a different branch of config tree, like a disk controller driver being in one section and the sata driver being elsewhere (this is just an example, don't go looking for it  )

47 minutes ago, Gat Pelsinger said:

I could not find some items like the "skl_uncore" which is listed as the first driver in use.

Yeah; what we are relying on when searching is the normal practice of "the module will be called [some name]" in it's docs or [CONFIG_SYMBOL] being similar to it's name.

Quite a lot of stuff is enabled/disabled implicitly: If you pick a generic sounding option and hit ? you'll get a rundown on that option, along with things it will automatically turn on (normally dependants) or things that will automatically disable it (needs to be mutually exclusive with).

 

If you get your file systems supported, and make sure your GPU driver is "y" and not "m" you're in a starting position to not be guessing about the rest as long as you turn off any "quiet" options on your kernel command line (so you can see any hangs/errors as the kernel initiates).

 

Anything you *need* (excepting proprietary nvidia drivers) that is set as "y" instead of "m" will cut down on the amount of work udev has to do at boot time as long as you copy the requisite parts from modprobe.d/some_module.conf onto the kernel command line and include any firmware in the kernel - but you/we can revisit this once you get your custom kernel working at all.

 

The default for Gentoo (for about 20 years) was to configure your own kernel, with this in mind I'd suggest you read https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Alternative:_Manual_configuration it's not a huge doc and will cover things I'll forget, just ignore things that are specific to that guide (like chroot, gentoo options etc) and it'll give you a good gist.

 

EDIT: 

47 minutes ago, Gat Pelsinger said:

Is that still okay?

Yeah, it's so OK I actually forgot to respond

 

It's worth noting that "generic" kernels supplied with distro's nowadays need a lot of support, in the way or initrd and udev, so they can dynamically load all the drivers they need at boot time for any conceivable hardware combination. You are rejecting this paradigm to have your kernel only include what is needed and include it by default - none of my custom kernels even have module loading support, it's not needed in my case, and reading your lspci, not needed in yours unless you expect to be plugging in "foreign" USB devices as the laptop travels around- but again a topic to revisit when you have it "working".