I'm building the 5.19-rc kernel, and one glaring problem is that the kernel-modules package has blown up from about 300M in 5.18.x to over 4.5G in 5.19-rc. Is it just me or is everybody else having this problem? Is there a parameter that needs to be added to stop this explosion? Thanks.

Please have a look at https://www.linuxquestions.org/quest....php?p=6360302

1 members found this post helpful.

Thanks very much! Dropped it from 4.6G to about 300M. I hope the kernel devs are looking at this.

It's not their fault.

In fact, our BDFL decided to build the kernel with debug info enabled, then to strip this debug data. So, grabbing the generic .config from -current to reuse in your custom kernels will end with over 16GB of compiling files and, as you seen, with over 4.5 GB of modules with debug info.

Do not ask me why he decided to build with this debug info enabled. I guess, to help the kernel programmers to build debug kernels under Slackware.

However, I for one, I doubt that there are kernel programmers who does not know how to build debug kernels and also I strongly doubt that any of them uses Slackware.

So, this "feature" seems basically a way to torment the unsuspecting Slackers who reuse his configs...

Specially when the Gurus continue to recommend a root partition of 25GB, building a custom kernel became a way to broke your system, by filling your root partition with useless crap.

2 members found this post helpful.

A full Slackware64-15.0 plus about 600 packages weighs 12G in a single btrfs volume with zstd compression. Honest: this do not leave room for snapshots and I recommend rather a size of 50G, also considering that you better do not fill a btrfs volume at more than 80% so it can breath normally. This is also the recommendation from OpenSUSE if you want to store snapshots in the same volume.

3 members found this post helpful.

I prefer the correct way

why build debug , making machine a more large builds and resources consumition if we have a config kernel for this ?

https://www.linuxquestions.org/quest...ml#post6361738

Thats all , enable this and all build as ever , no need time x2 , more memory , more space ...for later make a simple strip :=)

2 members found this post helpful.

It might be related to CONFIG_DEBUG_INFO_BTF, which is needed to run BPF CO-RE applications. We've been looking into that, but not fully decided what to do with it yet.

1 members found this post helpful.

With all respect, if those BPF CO-RE applications needs a debug enabled kernel and its modules with a whooping 4.5GB installed size, permit me to say that something is very very very wrong with them. And who needs that? For what they are good for? It's some academic experiment?

How about to focus your precious and limited time on updating Mesa? It's already long in teeth.

An updated Mesa will be thousands of thousands times more useful than those morbid overweight BPF CO-RE applications.

And in the end, what stops you to use separate debug configs, grabbed by the kernel SlackBuild when it's literally instructed to do this by the people who want this?

2 members found this post helpful.

In fact, unless we do the config change you already said, we will end with 16x larger builds...

1 members found this post helpful.

Finally , from todays changelog

5 members found this post helpful.

I'm very glad that the common sense finally won!

1 members found this post helpful.

This ^
Just don't compile kernel if sooo difficult and all will work.
I would say, pity

Well, if something worked well in Slackware since last 20 years, was the users reusing of stock configs to build their own kernels. We had been proud that's so simple to build kernels in Slackware compared with Ubuntu or Fedora.

Unfortunately, at least temporary some geniuses found a way to transform even this in Rocket Sciences.

Pity? So, you are the one behind this <beep> idea to ship those debug kernel packages disguised as stock ones?

Pity is that someone had been brought up this idea of CO-RE applications over the default kernel transforming it in a debug kernel...

Pity is that seems that there was people who was locked out of their systems after a tentative of reusing the stock config from Slackware.

Pity is that you people dared to complicate even the unique feature which worked well in Slackware in the last 20 years: reusing the stock kernel configs.

Do not understand me wrong, I have nothing against debug packages. I will not complain even Slackware will ship the whole 4.5GB crap compressed in a 2GB package of kernel modules. For CO-RE love. It's OK, as I know well how to blacklist packages which I do not need.

Anyway, I seen nothing else but a silentio stampa in this forum regarding those CO-RE applications. Nobody bothered to tell to the people here for what they, those CO-RE applications are good. Or bad.

You even wondered if those CO-RE applications are acceptable from people's philosophical, political, religious and whatever else POV?

In fact, where was discussed about and presented the usefulness of those CO-RE applications? Directly on IRC with The Boss?

What's next? To casually update the -current, then to find out that we run systemd as init system? No explanation given thought, because it was decided on IRC?

3 members found this post helpful.

@Aeterna

You are wong , if loose some time to investigate , you probably understand better the real question here.

The change on config , affect time and size , but after all , the slackbuild make a nasty "strip" for modules ...

Then the question is

Why?

Why loose time building and resources for make a strip later ?

If a simply change on config can make things simply as ever...

You have percentage of "DEBUG" users ? ...probably 1% ?¿ I miss something ??

Make force build of debug for general usage is NEVER a good idea.

For debug (developers) , can simply change the config to enable , and investigate with debug , but regular users no need this bloat.

And YES I know the package provided is not size changed, but again the question is

Why loose time and resources to build a BIG DEBUG KERNEL ...to strip later , when can build stripped directly and save space , time , memory ..etc etc ?¿?¿

why , lover why ... =)

3 members found this post helpful.

I still think that this is funny.
I doubt that I am the only one who did not have this kind of problems when compiling custom kernel.
I consider wasted time, only if I would be building exactly the same kernel as the same kernel as default. Yes, this is real waste of time. In such case just stay with the default. Otherwise customize and no problems should arise.
If you do compile kernel routinely, this change would never be a problem just run diff on configs. No time wasted.
If someone is to build the kernel for the first time, then obviously should learn how to.

@LuckyCyborg - of course the defender of poor and oppressed.. but only if you are affected,n'est-ce pas? otherwise you always have snide remarks for anyone looking for help.

I don't know what caused this change in the config but I think that the outcome is hilarious.

1 members found this post helpful.