SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,008
Rep:
Interesting, I have 5.18.3 installed, compiled with gcc 12.1.0
/lib/modules/5.18.3 takes 53M
whole /lib/modules takes 212M (with installed 5.17.13, 5.18.1, 5.18.2 and 5.18.3)
I guess the question is how much space is taken by modules installed by default 5.18.3?
I doubt that as much 4.3GB
There are some obvious conclusions I think.
This actually is pretty funny.
Interesting, I have 5.18.3 installed, compiled with gcc 12.1.0
/lib/modules/5.18.3 takes 53M
whole /lib/modules takes 212M (with installed 5.17.13, 5.18.1, 5.18.2 and 5.18.3)
I guess the question is how much space is taken by modules installed by default 5.18.3?
I doubt that as much 4.3GB
Then try yourself!
Did you know what our BDFL did? He did this:
Code:
#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_NONE is not set
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
# CONFIG_DEBUG_INFO_DWARF4 is not set
# CONFIG_DEBUG_INFO_DWARF5 is not set
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_INFO_COMPRESSED is not set
# CONFIG_DEBUG_INFO_SPLIT is not set
# CONFIG_DEBUG_INFO_BTF is not set
CONFIG_PAHOLE_HAS_SPLIT_BTF=y
# CONFIG_GDB_SCRIPTS is not set
CONFIG_FRAME_WARN=0
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_READABLE_ASM is not set
# CONFIG_HEADERS_INSTALL is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
# CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B is not set
CONFIG_STACK_VALIDATION=y
# CONFIG_VMLINUX_MAP is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# end of Compile-time checks and compiler options
This means that the kernel and its modules are built with debug data, when the default generic config is used "as is" .
So, instead of around 300MB you will get around 4.6GB of space occupied by the modules containing the debug info, unless you strip them.
And this happens with the installed modules, the source tree after compilation eats over 15GB. Compiled object files, things like this.
Quote:
Originally Posted by Aeterna
There are some obvious conclusions I think.
This actually is pretty funny.
True!
I for one, I've laugh with tears when my system with 34GB free space started to show warnings about low space, and finally I realized that building a kernel with a stock generic config eaten over 20GB at whole.
BTW, to get the "traditional" modules, which occupies around 300MB and contains no debug data, you will need this:
Code:
#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO_NONE=y
# CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT is not set
# CONFIG_DEBUG_INFO_DWARF4 is not set
# CONFIG_DEBUG_INFO_DWARF5 is not set
CONFIG_FRAME_WARN=0
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_READABLE_ASM is not set
# CONFIG_HEADERS_INSTALL is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
# CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B is not set
CONFIG_STACK_VALIDATION=y
# CONFIG_VMLINUX_MAP is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# end of Compile-time checks and compiler options
It's NOT my invention, but the "traditional" config section on stock Slackware kernels, until the latest one.
Last edited by LuckyCyborg; 06-12-2022 at 04:55 PM.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,008
Rep:
Quote:
This means that the kernel and its modules are built with debug data, when the default generic config is used "as is" .
So, instead of around 300MB you will get around 4.6GB of space occupied by the modules containing the debug info, unless you strip this.
And this happens with the installed modules, the source tree after compilation eats over 15GB. Compiled object files, things like this.
Not mine. I always check for the changes in config file. That is way my /lib/modules/5.18.3
is only 53M
I guess enabling debugging as CONFIG_DEBUG_INFO was a mistake? But if you build custom kernel just be more careful. In this case just build a new kernel with a proper config.
Not mine. I always check for the changes in config file. That is way my /lib/modules/5.18.3
is only 53M
I guess enabling debugging as CONFIG_DEBUG_INFO was a mistake? But if you build custom kernel just be more careful. In this case just build a new kernel with a proper config.
Look, I'm totally NON interested to tinker with shiny custom kernels made with shiny custom configs which generates 50MB modules.
I've arrived to build some custom kernels in the last time, because I tinker with some out-of-tree drivers for USB WiFi dongles. That's WHY and for ONLY reason I needed and/or wanted on Slackware 15.0 a newer kernel. And I wanted a stock configured kernel.
I for one, when I need a newer (or older) kernel for a stable release, I will just grab the latest (or older) generic config from -current and do a local build.
This time, hilarity ensued because our BDFL meantime decided to build the kernel(s) with debug info and to strip the packages in the SlackBuild.
And no, I'm convinced that he did NOT enabled CONFIG_DEBUG_INFO by mistake.
Heck, the kernel configs was one of the things which worked out of box since immemorial times...
BUT, looks like that he found a way to complicate even their usage.
Last edited by LuckyCyborg; 06-12-2022 at 05:28 PM.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,008
Rep:
Quote:
Originally Posted by LuckyCyborg
Look, I'm totally NON interested to tinker with shiny custom kernels made with shiny custom configs which generates 50MB modules.
I've arrived to build some custom kernels in the last time, because I tinker with some out-of-tree drivers for USB WiFi dongles. That's WHY and for ONLY reason I needed and/or wanted on Slackware 15.0 a newer kernel. And I wanted a stock configured kernel.
I for one, when I need a newer (or older) kernel for a stable release, I will just grab the latest (or older) generic config from -current and do a local build.
This time, hilarity ensued because our BDFL meantime decided to build the kernel(s) with debug info and to strip the packages in the SlackBuild.
And no, I'm convinced that he did NOT enabled CONFIG_DEBUG_INFO by mistake.
Heck, the kernel configs was one of the things which worked out of box since immemorial times...
BUT, looks like that he found a way to complicate even their usage.
If you are not interested in tinkering with configs, then use one that arrived with a previous kernel that worked for you.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,103
Original Poster
Rep:
Year 2022, Round 35.
Another batch of updates has been scheduled for release on Wednesday, 15 June 2022, at approximately 09:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Tuesday (depending on your time zone).
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,103
Original Poster
Rep:
Kernel updates 5.18.4,5.17.15 [EOL],5.15.47,5.10.122 and 5.4.198 are now available at, https://www.kernel.org/
The 5.17.15 kernel has been marked as, End Of Life. It is a little early in the cycle and it wasn't announced in the change log, so maybe it is an error? We'll see.
Here we go, https://lkml.iu.edu/hypermail/linux/...6.1/10076.html
Quote:
Linux 5.17.15
From: Greg Kroah-Hartman
Date: Tue Jun 14 2022 - 12:58:06 EST
---------------------------------------
NOTE: This is the LAST 5.17.y kernel release. This kernel branch is now
end-of-life. Please move to 5.18.y at this point in time, no more new
updates will happen on this kernel branch at all.
---------------------------------------
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
