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.
Okay. I am not advising you to do this, but, you can edit /etc/slackpkg/mirrors and comment out your present version of Slackware (put a # in front of your present mirror) and then uncomment a -current mirror of your choice (remove the # in front of the mirror). Save and exit.
Run lilo at the end of this. You will then be running Slackware-current after the reboot. You need to upgrade to Slackware-current if you're going to run a -current kernel. There are risks associated with this.
@hitest, I ended up following that exact procedure and it worked a charm!
@enorbet, what on earth makes you think I feel kernel building is "antiquated and useless"? I'm just trying to get a new system up and running with a minimum of muss and fuss and I don't want to go through the trouble of building a custom kernel if it's not absolutely necessary at this time. I've been using Slackware since 2.2.0.1 or perhaps earlier so yes I've done a fair amount of kernel building. Please forgive me for having an imperfect memory on the exact building commands and their sequence; it's been about a decade since the last time I built a kernel. The last time I tried to build a kernel it didn't work and I never put much effort into finding out why; obviously I did something wrong but since the out-of-the-box kernel worked just fine I didn't put a whole lot of effort into finding out what I was doing wrong. The previous dozen or so times I'd compiled kernels they worked fine.
Nobody compiling a kernel ever uses (and rarely ever used) "make config" and running "make clean" after it would destroy anything you did anyway by returning it to generic source
I see that you haven't run those commands in a while.
"make mrproper" is the command that nukes your configuration changes. Most people would run "make menuconfig" instead of "make config", but only because it's easier for humans to handle the menus versus the questions for each option.
@hitest, I ended up following that exact procedure and it worked a charm!
I'm glad it worked out for you.
I felt safe advocating the non-standard upgrade procedure as I had recently done it myself and knew that it was unlikely to hose your system.
However, if you were running an earlier version of Slackware it would make more sense to follow the recommended upgrade path.
I see that you haven't run those commands in a while.
"make mrproper" is the command that nukes your configuration changes. Most people would run "make menuconfig" instead of "make config", but only because it's easier for humans to handle the menus versus the questions for each option.
I'm well aware that "make mrproper" nukes any previous changes as does "make clean" which is why either comes BEFORE any manner of config. I have only ever used "make clean" on kernel source if I botched a kernel config. The major point was the sequence. The minor point was the choice of commands.
Sometimes making things easier is a bad tradeoff or at least one that must be considered carefully, however I see no advantage whatsoever to "make config" over "make menuconfig" and once I got over "posing 1337" I came to actually prefer "make xconfig".
Perhaps I somehow offended you to cause you to "point a finger" with the emboldened you but I honestly was trying to be polite but you are right.... it has been roughly 3 months since I last compiled something from source but my memory isn't that bad yet It was still accurate since "make clean" is only invoked if a config has errors and must be redone and never used on a trouble free build and in 14 years of using Linux I have never met one single person who compiles kernels with "make config". Then, come to think of it, I've never met Richard Stallman.... he might.
I'm well aware that "make mrproper" nukes any previous changes as does "make clean" which is why either comes BEFORE any manner of config. I have only ever used "make clean" on kernel source if I botched a kernel config. The major point was the sequence. The minor point was the choice of commands.
Sometimes making things easier is a bad tradeoff or at least one that must be considered carefully, however I see no advantage whatsoever to "make config" over "make menuconfig" and once I got over "posing 1337" I came to actually prefer "make xconfig".
Perhaps I somehow offended you to cause you to "point a finger" with the emboldened you but I honestly was trying to be polite but you are right.... it has been roughly 3 months since I last compiled something from source but my memory isn't that bad yet It was still accurate since "make clean" is only invoked if a config has errors and must be redone and never used on a trouble free build and in 14 years of using Linux I have never met one single person who compiles kernels with "make config". Then, come to think of it, I've never met Richard Stallman.... he might.
Maybe you should take my posting name. It seems to fit you better.
I haven't compiled a kernel in years. You can run "make clean" any damned time that you wish without worrying that it will remove the configuration that you have set via "make what-ever-the-eff-config" WHICH IS WHAT YOU BLOODY WROTE.
Quote:
[...] running "make clean" after it [E.B. "make config"] would destroy anything you did anyway by returning it to generic source.
You just end up compiling more stuff than perhaps you had to, but that is scarcely the "only" time that you can do so.
FWIW, I actually preferred "make xconfig", myself. Unless I was using ssh to recompile the kernel on a box with no monitor and did not want to *bleep* around with exporting an X display back to the machine upon which I was typing. Or didn't install the Nvidia blob for my desktop because (gasp) I hadn't recompiled my kernel yet.
@hitest, I ended up following that exact procedure and it worked a charm!
@enorbet, what on earth makes you think I feel kernel building is "antiquated and useless"? I'm just trying to get a new system up and running with a minimum of muss and fuss and I don't want to go through the trouble of building a custom kernel if it's not absolutely necessary at this time. <snip>
My apologies BobKay (and everyone caught in the splatter) apparently I misunderstood. It does seem that I made a mountain out of a molehill. It's probably just the state I'm in with allergies and antihistamines - hard to tell which is worse, the problem or "the cure".
If just for the kernel upgrade, I normally do commands as follow for my -current 64bit, but since you are at Slackware 14.1 you need to change the -current to 14.1(don't forget the . at the end is also part of the command):
next use pkgtool,select "install packages from the current directoty" to install the kernel-firmware, kernel-headers, kernel-huge, kernel-modules and kernel-source.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.