[11:20] Hello, does the GitKernelBuild manual (https://wiki.ubuntu.com/KernelTeam/GitKernelBuild) also hold for ubuntu-focal? [11:25] Background: I want to build a custom mainline kernel based on https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.10.14/. I already cloned git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack und checked out the cod/mainline/v5.10.14 but I don't know whether I already can build this thing or whether there are special configs in git://kernel.ubuntu.com/ubuntu/ubuntu-focal.git I need to use === fling is now known as bedroller === bedroller is now known as bedcrawler [15:36] Hi channel [15:39] I'm trying to build the bionic kernel 4.15.0-132.136. I moved the nvme driver from module into built-in. The following are my changes: [15:39] [15:39] modified debian.master/config/amd64/config.common.amd64 [15:39] @@ -56,6 +56,7 @@ CONFIG_BFS_FS=m [15:39] CONFIG_BLK_DEV_3W_XXXX_RAID=m [15:39] CONFIG_BLK_DEV_CRYPTOLOOP=m [15:39] CONFIG_BLK_DEV_DAC960=m [15:39] +CONFIG_BLK_DEV_NVME=y [15:39] CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m [15:39] CONFIG_BLK_DEV_RSXX=m [15:39] CONFIG_BLK_DEV_SKD=m [15:39] [15:40] [15:40] modified debian.master/config/annotations [15:40] @@ -4748,7 +4748,7 @@ CONFIG_NVDIMM_PFN policy<{'amd64': 'y', 'ppc64el': [15:40] CONFIG_NVDIMM_DAX policy<{'amd64': 'y', 'ppc64el': 'y'}> [15:40] [15:40] # Menu: Device Drivers >> NVME Support [15:40] -CONFIG_BLK_DEV_NVME policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm', 's390x': 'm'}> [15:40] +CONFIG_BLK_DEV_NVME policy<{'amd64': 'y', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm', 's390x': 'm'}> [15:40] CONFIG_NVME_MULTIPATH policy<{'amd64': 'y', 'arm64': 'y', 'armhf': 'y', 'i386': 'y', 'ppc64el': 'y', 's390x': 'y'}> [15:40] CONFIG_NVME_RDMA policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm', 's390x': 'm'}> [15:40] CONFIG_NVME_FC policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'i386': 'm', 'ppc64el': 'm', 's390x': 'm'}> [15:40] modified debian.master/config/config.common.ubuntu [15:40] @@ -992,7 +992,7 @@ CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 [15:40] CONFIG_BLK_DEV_MD=y [15:40] CONFIG_BLK_DEV_NBD=m [15:40] CONFIG_BLK_DEV_NULL_BLK=m [15:40] -CONFIG_BLK_DEV_NVME=m [15:40] +CONFIG_BLK_DEV_NVME=y [15:40] CONFIG_BLK_DEV_PMEM=m [15:40] CONFIG_BLK_DEV_RAM=m [15:40] CONFIG_BLK_DEV_RAM_COUNT=16 [15:42] But I got build error on module-check, the error message is: [15:43] [15:43] II: Checking modules for generic... [15:43] reading new modules...read 5166 modules. [15:43] reading old modules... [15:43] MISS: nvme [15:43] MISS: nvme-core [15:43] read 5168 modules : new(0) missing(2) [15:43] EE: Missing modules (start begging for mercy) [15:43] debian/rules.d/4-checks.mk:9: recipe for target 'module-check-generic' failed [15:43] make: *** [module-check-generic] Error 1 [15:44] Please help! [15:45] Thanks in advance [15:46] nzt48, you need to remove these modules (nvme and nvme-core) from debian.master/abi//amd64/generic.modules (I'm assuming you're building amd64 -generic kernel), because now you're compiling them statically in the kernel [15:47] and theoretically you do apply the same change to the other architectures (in each generic.modules file) [15:47] s/you do/you need to/ [15:48] nzt48, ...and a little hint, use pastebin to post patches or big chunk of texts ;) [15:49] Thank you so much arighi, let me digest your message first :) [15:50] Also, sorry about pasting big chunk of texts here. This is the first time I use IRC. I'll check out the pastebin. [15:52] nzt48, np :) [15:53] So in my case, I should remove nvme and nvme-core from debian.master/abi/4.15.0-132.136/amd64/generic.modules right? [15:57] nzt48, correct [15:58] > Yen, I do build only for amd64. So do I have to apply the same change to other architectures as well? But what the use case is that one only need to build nvme into kernel for amd64, but not for any other architectures? [15:59] s/what the use case is/what if the use case is [16:20] Hi nzt48, of out curiosity - why do you need these to be compiled in? Something is not booting correctly? Or do you want to build a more streamlined kernel? [16:26] nzt48, if you changed the config only for amd64 then you only need to update the modules' file for that specific architecture (without touching the others) [16:29] Hi kwilczynski, previously we were building the trusty kernel 4.4.0-144.170~14.04.1, and the developer (who had left the team) said there was a problem that it didn't end up in the initramfs. Not sure if this issue is still in the bionic kernel, but I just thought it was probably better to replicate what he did. [16:35] nzt48: Not sure what the issue was, but it could have been resolved. :) There has been a lot of solid releases and fixes since Trusty. :) [16:35] nzt48: Is this built-in or out-of-tree driver? [16:35] nzt48: The reason why I am asking, is because seems like a lot of pain to have to make special provisions to make it compiled-in rather than a module, etc. [16:36] Not sure if you considered that it might work now, or had the time to test. [16:38] Ah. I looked above. This is just normal NVMe support that ships with the mainline. Hmm. [16:39] I have 20.04 running next to me with a number of NVMe drives in M.2 slots, and initramfs definitely works fine, as I am even booking from these, etc. [16:42] For the configuration changes (and any other "personal" changes that obviously applies only to the company), if we still want to follow the Ubuntu Kernel team's development cycle to record the changes in the changelog, and release the company specfic versions inside the company. the commmand "debian/scripts/misc/getabis MAINLINE-VERSION CURRENT-ABI.CURRENT-UPLOAD-NUMBER" will not work because the current company s [16:42] never been uploaded to Ubuntu. In such cases, would manually renaming the directory "debian.master/abi/MAINLINE-VERSION PREVIOUS-ABI.PREVIOUS-UPLOAD-NUMBER" to the "debian.master/abi/MAINLINE-VERSION CURRENT-ABI.CURRENT-UPLOAD-NUMBER" the only choice? [16:43] kwilczynski, this is a built-in driver provided by the kernel. [16:43] :) [16:46] kwilczynski, yep, no time to test. But I'll probably reverse it back to module build later after the stress is gone. :) [16:46] Ace. :) [16:46] If it works, then one thing less to maintain/customise. [16:46] Yep, definitely agreed!