It's not about entitlement. It's about knowing what you're doing. You're entitled to do your own dental work too, eh?
If you're using Patrick's config with no changes, why not just use his binary??

I'm not running -current, but not because of minor things like this. It is because I barely have the time to maintain my stable install, I certainly don't have the time to maintain a -current install.

The question remains, why enable the debug just to strip it away as soon as the package is built? Why not leave debug disabled (like in pretty much every Slackware package) and let users enable debugging if they want? This would prevent consuming a massive amount of harddrive space for literally no benefit.

It has nothing to do with the potential pitfalls of running -current and everything to do with enabling something that takes extra space only to strip the benefit of enabling it in the first place.

Just because someone doesn't like a particular setting or feature doesn't mean they shouldn't be running -current or Slackware.

Come on! You should know better than this. If someone is on -current, feel free to use his binary (and I imagine a lot do, so they wouldn't know of this issue). If someone is running something that isn't -current (like my 14.2 box -- see my lack of time on why I haven't updated to 15.0 yet), it is never a good idea to install a package built on a different version of Slackware.

I've frequently grabbed configs from -current to use on my stable releases of Slackware. I'm currently running a slightly modified version of his 5.10.x config on my 14.2 install. I am aware of this issue now (thanks to others on the forum), so I can disable the feature if I decide to install a newer kernel (doubtful, they aren't LTS and I'll likely not upgrade beyond 5.10.x until I install 15.0).

3 members found this post helpful.

The clue is in the word "debug". I'll say it again: This is a configuration file from the development tree of an operating system.

Perhaps there was an issue or something specific which demanded this treatment temporarily. Who knows?

What I do know is that using such a file requires caution.
It's not about disliking settings or features. People should not use -current in production. Period.

It's not analogous to Debian testing. Breakage happens. Experiments happen.
Right, so my point is valid. The hint is in your use of the words "slightly modified."

Grabbing any configuration file from -current and blindly using it on a different version of Slackware is not a good idea.

And the question is "to debug what?" considering that all that whooping 4.5GB of debug information from the kernel modules built this way was NEVER shipped in a package?

In my ignorant opinion, this story it's so meaningless that it has a single meaning: that at The Court of King (from IRC) managed to infiltrate a malicious person and s/he tried to provoke damage. And this person apparently succeeded on his plans considering that there was people even locked out of their boxes by trying to build a kernel.

Honestly, I will not be surprised if there was somehow the hand of the merry guys from University of Minnesota, already famous to become fully banned from the Linux kernel development and all the patches pushed by this particular university being all reverted - because their patches being "obviously submitted in bad-faith with the intent to cause problems.".

https://www.pcgamer.com/linux-kernel...-research-ban/

After this great "success" , they need a new subject on "social engineering on open-source" for their new research papers, right? Apparently this is what they have as research subject - the social engineering to cheat the opensource projects.

Anyway, fortunately this debug (mis)feature was reverted already several kernel packages ago.

2 members found this post helpful.

-current might be a development version, but it is not common to have debugging symbols in programs. The symbols are stripped before installing, so again, it is a massive waste of space on the build system and if someone doesn't realize it and builds it themselves without stripping, a massive waste in /lib/modules/.

What I do know is that using such a file requires caution.

What does this have to do with production? I can be annoyed with that if I'm using it in a VM or even just a test bed system.

It's an experiment that has not hypothesis and no way for -current users to test since the symbols are stripped before installing via the SlackBuild. Again, why not default to debugging off (like pretty much every other program) and let those that want it enabled, do it themselves. Slackware has always been known for sane defaults, and this seems to go against that (at least without an explanation -- maybe there is a good reason for it).

So, you expect someone to go through the 10K+ options to find an option that they wouldn't even know to look for? Pat has always had sane defaults for kernel configs and they're usually good candidates to use untouched or slight modifications. This is the first time in my memory of using Slackware (which I've done for around 2 decades) that Pat has deviated from what I would consider sane defaults. Yes, it is in -current, but -current still tends to be thoughtful development of Slackware and this seems to go against that.

=======================

However, this is all moot. I didn't realize it until now, but Pat reverted the change 1.5 weeks ago and debug is now disabled as of the 7 JUL kernel update to 5.18.10.

4 members found this post helpful.

Fair point. You can be as annoyed as you like.
You don't have to go line-by-line if you use "make menuconfig." I'd question what you're doing if you're not prepared to at least look through the chosen options. There is help at your fingertips for the options you don't understand.
So -current served it's purpose and rooted out a problem. That's a good result.

I hope that the people who were negatively impacted by this have learned something from the experience.

1 members found this post helpful.

Wait... you're proposing that someone should go through all the kernel menuconfig options to see if Pat made sane defaults on every single option? Or to hold onto old configs and compare it to new configs, even across new kernel versions (this was introduced when -current switched to 5.18) and then research all those changes to see if they make sense? Eric's unofficial git repo can help with this, but do you really expect someone to go through all this just to see if any of those options are going to take an exponentially higher amount of space when compiling? How ridiculous!

I've been building my own kernels since the 2.4 era. I know my way around menuconfig and how to research options, but do you actually realize how much time it would take to go through all the menus in menuconfig to check all the selections Pat has made? There are over 10,000 lines in the kernel config. Most of those will have their own individual setting in menuconfig.

Or Pat realized it was pointless to include debugging when building kernel modules only to strip it away when packaging...

What exactly is the lesson to be learned here? Make sure you have 50GB free to start a kernel build just on the off chance that debugging was enabled for the first time I can remember (been using Slackware around 20 years and been building kernels pretty much that entire time) or should we dig through an entire kernel config to make sure some random option hasn't been enabled that massively increases the size of the build tree and resulting module files? What other theoretical changes should we be on the lookout for to ensure we aren't bitten?

-current is a testbed for the next Slackware. Yes, people are to expect breakage, but that doesn't mean that we can't complain about it and suggest that the decision was wrong. -current is to test for the next stable release and it benefits from feedback from the community. We shouldn't just sit back and take every single change just because "iT's -cURreNt". If a decision is made that doesn't make sense, it is the role of the users of -current to call it out and see if we can find out the reason or get it changed. Due to the nature of development, we may never find out if there was a good reason behind the change and we may never get that change actually implemented, but feedback from the community is VITAL to the proper development of -current.

Many older regulars on this forum will know that Darth Vader and I got in a lot of... discussions on the development of -current. Even though I disagreed with a lot of what they were trying to get implemented, I still appreciated the passion by Darth and their desire to push Slackware into something they considered better. Telling people they shouldn't run -current if they get annoyed or frustrated by what seems to be bad decisions is antithetical to the purpose of -current. We want vocal users, even if all their requests don't make it into the next stable release. Those vocal users are what pushes Pat and Slackware. We want passionate users who are willing to call out BS when they see it. You can even see Pat appreciating it with callouts in the ChangeLog for the friendly reminders from those users.

6 members found this post helpful.

Wow bass. I think you've read way too much into what I wrote, my friend. I think you & I are on the same page for the most part.
Well, yes. The kernel is a critical part of your operating system. Why would you not check it?
It was 2.2 for me. My approach to building kernels was to cut them back as far as possible, generally by doing things like removing support for hardware I didn't have and features that I didn't need. I recall having a fully functional system with a kernel under 400Kb.
Yes. Back in the day I remember spending 2 or 3 weekends getting my 2.6.0 config right, and that was with years of experience from compiling 2.2 and 2.4 kernels. If you're not willing to invest the time to learn how to do it properly, then why do it at all?

That's why I wrote earlier that compiling a kernel is a non-trivial exercise these days. I'd certainly not be recommending it to friends who don't have sufficient knowledge to revive their machine should they run out of space on the partition they're using... unless, of course, they're ready and willing to learn what it takes.

Despite what I've said above about -current, if my hardware was new enough to not be supported by the 5.15 kernel in Slackware 15.0, in all honesty I'd probably just run -current on it, including the binary kernel compiled by Patrick. I'm not in that position, so its 15.0 on everything for me.

The last kernel I compiled myself was somewhere around version 3.2 I think. Life is too short. I've got a family to raise and work to do.
Or perhaps he made a mistake? Patrick is human you know. Part of the reason we like Slackware is that there are near-immediate positive outcomes from incidents such as this.
And this is the part where you lost it.

When I said that I hoped you had learned something, what I meant was that I hoped you had learned to check these:

That's all.

But since you raised it, one thing which I'm curious about is why people are compiling kernels in their root partition... If I was compiling a kernel, I'd be doing it in my user account (and as a user... not root).
Probably not a bad thing to do.

2 members found this post helpful.

Hi all
I believe the argue is with no end and that both sides here have good sights.

Just for rkelsen :
Even if I'm far less competent, I recall the rise of 2.6 kernel and it's bunch of improvements. From then till now, I thought the Slackware way was to compile kernel and run slackbuilds as root (even if it could be outside the root partition it was not obvious why till now). Can't check for now why I have that in mind though...

Edit : that was not so hard to find...
https://docs.slackware.com/howtos:sl...kernelbuilding
This advice from Alien Bob has never failed me. Even if it's quite old these days.

I was just put off by your logic that if someone doesn't like what happened, they shouldn't be running -current.

It has always been non-trivial to grab a pre-made config from Pat and use it to build your own kernel. I've been doing that for years. It is why my 14.2 system is running a 5.10.x kernel instead of the 4.4.x kernel it came with. Now, about the only change I make is switching the processor type away from generic and build ext4 into the kernel.

Exactly! Time is precious, so why spend time building your own config when Pat has done it wonderfully for the last several decades unless you want the exercise to build your own? Sometimes you want/need a newer kernel than what is offered in the Slackware version you're running, so you might as well use Pat's config if you don't want to spend the time to go through the entire kernel yourself.

And who would've thought to check that before the 5.18 kernel? Pat didn't have a history of enabling debugging mode, so why would that be something you'd specifically check for? Next time some new change is made that causes issues, are you going to say we should learn from it and now look at those options in addition to ensuring debugging wasn't enabled again?

I unpack all my kernels in /usr/src and then compile as root. It is definitely one of those "it's the way I've always done it" things, but even though GKH doesn't recommend that, I don't want a kernel sitting in my user's directory that nobody else has access to. In my mind, it makes sense to have kernels available in a system-wide directory, and I just stick with /usr/src since that's where the stock kernel sits.

I have it on my bare metal installs, but not on my VMs. I'm not willing to chew up all that space on the off chance debugging was enabled in the config and I missed it (with 4 VMs, that'd be 200GB gone on the off chance debugging is enabled again and I build a kernel on them). I'd rather deal with the repercussions of a filled partition.

My ISP customer support said they never heard of Linux and rattled off
unsupported Windows versions --- Vista & 7 as the only supported OS
along with 8-11, not even Mac pc.
This is Comcast here in the US. ISP must follow greed right?

To add insult to injury, our BDFL said NOTHING in the ChangeLog about the incoming storage bomb. Nothing, nada, niente.
That's all he said, excluding an obscure notice in a SlackBuild.

I for one, I believe that he should have said at least a warning that the used kernel config thoughtfully fills over 16GB of storage space IF someone reuse it.

With all respect, I believe that's a grave problem of communication. Of lack of communication.

Meanwhile, be gentle to look what recommendations do our resident Gurus regarding the root partition for Slackware 15.0
And so they did also in the past. In the last 12 years at least I heard this again and again.

Did you imagine how many people followed those recommendations? Did you imagine how many people have root partitions around 25GB ?

What's even stranger is seems like that the "inner cycle" was aware about those debug kernels disguised as normal packages. Not only our BDFL, BUT neither Ponce, neither the other people like him from the "inner cycle" does not bothered about what happens when people tries those magic debug configs in 25GB root partitions?

1 members found this post helpful.

Dear LC,

I understand your pov but your tone sounds a bit dramatic to me (I might not understand well english subtilities as I am not native English-speaking).

A good practice IIRC is to diff kernel config files to be aware of changes. That hasn't been necessary for years as there were no big changes, only sane defaults. "Nemo auditur propriam suam turpitudinem allegans" ?

A good path to improve Slackware is indeed it's communication. Nothing new here. Sorry you've been hited this time.

3 members found this post helpful.

Hi Tonus!

Your post has prompted me to post my thoughts about, "the Slackware way."

Essentially, there is no, "Slackware way." There is Slackware. There is you. There is nothing in between. The way you choose to use Slackware is entirely up to you. It doesn't stand in your way. Part of the reason I dislike Debian & RedHat (and almost all of the derivatives thereof) is that you have to do things their way, or you can quickly and easily end up with a broken system. The "right" way to do something in Slackware is the way which yields the result you want, using methods of your choice.

Someone on the mailing list for a local LUG once said to me, "If you ask ten Slackware users how to do something, you'll receive eleven different answers." Threads like this one, with *cough* veteran users sharing differences of opinion are proof that those words are still true.

In the case of compiling kernels, on one hand we have the advice of senior kernel developers like Greg K-H who say, "Never compile a kernel as root!" And on the other hand, senior Slackers like Alien Bob who tell you the opposite. Neither is less correct. Both yield the same result. It's a matter for your perspective to determine how you do it.

Ever since the early days, my own 'modus operandi' is to try and minimise the amount of time spent logged in as root. I would always copy the kernel tree into my user account, configure and compile it as a user, and then "su" to root to install it. If that configuration worked, then I'd move the source tree to /usr/src. I still prefer to operate this way... doing only the bare minimum as root. With Slackbuild scripts, I modify them slightly by commenting out the "chown" and "makepkg" commands, and this usually enables them to run as a user. Of course, then I have to log in as root to finish the job (makepkg, etc.).

With that said, these days I like to keep things as stock as possible. This is easier than it used to be because nowadays a standard Slackware installation has a ton of capability right out of the box... Many of my required use cases are met without having to add or change things. Heavy customisation can be a rod for your own back.
I didn't think my argument was as strong as that... And I did actually say that you can be as annoyed as you like!

Part of the rationale for my comments is that there seems to be an uptick in the number of people running -current for no reason other than bragging rights. Maybe it's my own twisted perception of things, but I can picture the Slackware-current users sitting at the back of a classroom with the Kali users belittling everyone else with their smug sense of superiority. It's all good, as long as they submit bug reports...
I guess we won't see eye-to-eye on that. But anyhow, as you said the problem is fixed now. You can continue doing this, with the added benefit of knowing what to look for to ensure that it doesn't happen again.
I tend to not use my VMs for compiling stuff. Most of them are headless & lean, single purpose machines. I don't know how accurate the clock speeds in esxi are, but it tells me that my Slackware servers idle at 6MHz (after hours with no-one logged in), and that's using Patrick's binary kernels. Most of them are running Slackware 15.0 with 5.15.38, but I still have one which I haven't gotten around to upgrading yet. It's running a pre-15.0 version of -current with 5.4.34 and its showing an uptime of 611 days. I'm loathe to take it down but I'll have to at some point soon, I guess...

Here was your initial reply:

Based on that, if you don't like 10s of GBs of space unnecessarily chewed up or you didn't plan to spend another bit to deal with the fallout of an improperly installed kernel due to lack of space, then someone shouldn't run -current.

What I'm now guessing you meant was that if you aren't able to deal with unexpected issues like these (including repair or recovery), you shouldn't run -current. That I would agree with. Anything that goes wrong is -current could impact someone negatively, but that doesn't mean they aren't capable of dealing with it. If they can't deal with it or the impending downtime, then they probably shouldn't run -current.

Part of the issue with -current is Pat generally does a really good job at not breaking things or doing other things that could cause breakage (besides upgrading system libraries that might break 3rd-party programs), so when 15.0's development took really long and people started running -current for better hardware support, they may have forgotten it is a development version of Slackware and potentially prone to breakage beyond just your 3rd-party apps, even if it is exceedingly rare.

Annoyed is a negative response

1 members found this post helpful.