Package Base Details: linux-git

Git Clone URL: https://aur.archlinux.org/linux-git.git (read-only, click to copy)
Keywords: kernel linux
Submitter: jonathanio
Maintainer: jonathanio
Last Packager: jonathanio
Votes: 7
Popularity: 0.015714
First Submitted: 2019-12-22 10:10
Last Updated: 2020-11-04 21:11

Pinned Comments

jonathanio commented on 2019-12-22 10:14

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.

This package will automatically update it's version

Note: This is a -git package and the version will automatically update to the latest mainline 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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

jonathanio commented on 2020-10-30 20:46

@iamazat Thank you for taking the time to look at this. I did try a reversion of the 5.10rc changes but as you've shown, it was the syncing of the 5.9 changes which caused it. I was wondering at the time about looking to see if there are changes to PKGBUILD at the time which would be worth migrating as well, but wanted to take it one step at a time! Looks like I should have just gone all out!

I've copied the INSTALL_MOD_STRIP setting to the build step, and a diff comparison also shows a step to run strip on vmlinuz, so I've ported that across too.

I have Jenkins building the updated package now, and if that works I'll sync the additional changes and add support for linux-git-docs package it seems.

Thank you greatly for your help and hopefully this will fix it.

iamazat commented on 2020-10-30 19:50

Just for reference for anyone using this package - it looks like a configuration change between 5.9 and 5.10 is resulting in a significant increase in the size of the modules being created: The vmlinuz is still fine for me at about 9MB but the overall package is close to 1GB.

So to summarize (and update my previous comment):

  • CONFIG_DEBUG_INFO had been enabled in 1
  • no INSTALL_MOD_STRIP like in upstream 2

So after adding INSTALL_MOD_STRIP installed is 80.40 MiB, modules stripped (and initrd fits my 200MB boot parition) but vmlinux 700MB and I'm totally fine with this (since CONFIG_DEBUG_INFO enabled, and this will improve debugging capabilities)

iamazat commented on 2020-10-30 19:23

Hi!

There are few issues with the config:

  • .config:126:warning: unexpected data: CONFG_CGROUP_SCHED=y

  • and CONFIG_DEBUG_INFO_BTF=y, in 1 you enabled it with the comment that w/o it the kernel size increased, looks like the problem is in that CONFIG_DEBUG_INFO had been enabled 2.

jonathanio commented on 2020-10-27 09:36

Just for reference for anyone using this package - it looks like a configuration change between 5.9 and 5.10 is resulting in a significant increase in the size of the modules being created: The vmlinuz is still fine for me at about 9MB but the overall package is close to 1GB.

I thought I fixed it with a revert in the last commit, but there is still an issue so I'll continue looking into this over the next few days.

jonathanio commented on 2020-09-18 07:20

Admittadly, I normally run mine though a Jenkins job every week on a Monday morning, after the next -rc release it out, so it just runs make oldconfig and selects the defaults for the next release.

However, in previous versions that has not always worked. IIRC both 5.6 and 5.7 releases failed to build due to an issue at the configuration stage which required updated defaults from the previous version, and hence a custom config file for the build.

Are you asked for to select the options for all the new entries during build time? If so, it might be worth swapping to run make oldconfig and perform the migration automatically.

realkstrawn93 commented on 2020-09-17 21:42

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.

jonathanio commented on 2020-08-29 19:18

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

mxfm commented on 2020-08-29 19:14

@jonathanio Thanks, the issue is resolved :)

jonathanio commented on 2020-08-29 19:13

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

jonathanio commented on 2020-08-29 19:10

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?