The last version of the linux-git package was disowned and deleted. I've restored it taken ownership, as I do make use of this package.

Note: This is a -git package and the version will automatically update to the latest commit when it is run, having pulled down the branch from the repository. It will normally only be updated between major versions in order to include any updated configuration for new modules and features or settings changes.

Why does the PKGBUILD supply its own kernel configuration file instead of running “zcat /proc/config.gz > config” on the system that it’s being installed to? The kernel configuration tries to re-run from scratch whenever I try to install this package due to so many mismatches. Would be a much better solution to simply use the configuration from an already running kernel to build this, given that Arch itself supports that.

@mxfm No problem. Glad it's fixed :)

@jonathanio Thanks, the issue is resolved :)

For reference, these are the recent commits I've built successfully.

#225 24-Aug-2020 04:46 linux-git ​5.9rc2.r0.gd012a7190fc1-1
#2​24 17-Aug-2020 04:46 linux-git ​5.9rc1.r0.g9123e3a74ec7-1
#2​23 10-Aug-2020 04:46 linux-git ​5.8.r11991.gfc80c51fd4b2-1
#2​22 03-Aug-2020 04:46 linux-git ​5.8.r0.gbcf876870b95-1
#2​21 27-Jul-2020 04:46 linux-git ​5.8rc7.r0.g92ed30191993-1

I have a Jenkins job on my build server that builds the kernel every Monday morning in the early hours. This includes a full wipe of the build workspace beforehand so it's a fresh build. There are no current issues with the build for me right now.

I don't use dracut, so like @gardotd426 suggests, it seems that darcut is probably the issue as it's the only difference (that we're aware of) between the three of us.

Have you tried building it without dracut and from a clean workspace?

@gardotd426 I knew the kernel is not broken for the reasons outlined by you. My suspect was that something is changed in kernel build process which required changes in PKGBUILD, so this would affect only Arch.

Regarding dracut. I can assure, that dracut is fully fine in my setup, which is quite complicated (full disk encryption). I even have created custom scripts to facilitate my minor needs. I would recommend to any advanced Arch user to use dracut because it is at least as flexible as mkinitcpio.

Regarding the problem. It turns out, that depmod and modinfo (which were called by dracut) were complaining on garbage '/usr/lib/modules' previous kernel version installation which no longer existed (trashed by power failure). After clearing this not tracked by pacman gargabe I was able to compile package. Thanks for quick response!

@mxfm um, the "git repo" is literally the actual main Linux kernel repo. There's nothing wrong with it, if there were, the whole world would know. It would also mean that no other 5.9-rc1 kernels could be built using that source, which isn't true (I'm running one right now).

It's very likely a Dracut issue. Dracut on Arch is nowhere near ready for prime time on Arch Linux. An Arch dev reported not being able to use their keyboard and mouse when testing Dracut, etc.

But it's definitely not the git repo. If it's not the PKGBUILD, then it's your setup or dracut.

Approximately since 5.9.1.rc1 I cannot build correct package of linux-git. I use config file from mainline 'linux' package from core repo (I only modified two kernel options related to default localhost name and version config). After building the package, I cannot build initramfs image with dracut - it fails to include kernel modules with message like 'depmod: ERROR: failed to load symbols from /var/tmp/dracut.nBQFd0/initramfs/lib/modules/5.9.0-rc1-1-git/kernel/drivers/pinctrl/cirrus/pi nctrl-lochnagar.ko.xz: Exec format error'

Can someone confirm that he can build package from this script? Perhaps something has been broken in git repo?

I just did a complete rebuild for testing purposes with -j12 enabled. The build time came down from ~2 hours to 20 minutes while the laptop is still responsive. Wow! Thank you for this suggestion. This is more than I ever expected. I'll stick with this setting definitely ;)

@gardotd426 - Well in my case the build files stay near the source code, and are present even after reboots and /tmp is cleared.

And if you use "makepkg -e" it does perform an incremental build (assuming config was already done on the previous build).

@Harey - You should definitely go with a higher count, atleast "make -j8" if not "make -j12"