Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.slackware > #35776 > unrolled thread

Updating Slackware

Back to article view | Back to alt.os.linux.slackware

Contents

  Updating Slackware The Real Bev <bashley101@gmail.com> - 2026-09-08 10:56 -0700
    Re: Updating Slackware "Rinaldi J. Montessi" <rinaldij@alien.free> - 2026-09-08 13:40 -0500
      Re: Updating Slackware The Real Bev <bashley101@gmail.com> - 2026-09-08 12:04 -0700
        Re: Updating Slackware "Rinaldi J. Montessi" <rinaldij@alien.free> - 2026-09-08 19:21 -0500
          Re: Updating Slackware The Real Bev <bashley101@gmail.com> - 2026-09-08 19:07 -0700
            Re: Updating Slackware Rich <rich@example.invalid> - 2026-09-09 02:58 +0000
              Re: Updating Slackware The Real Bev <bashley101@gmail.com> - 2026-09-09 22:51 -0700
                Re: Updating Slackware "Rinaldi J. Montessi" <rinaldij@alien.free> - 2026-09-10 07:15 -0500
        Re: Updating Slackware Marco Moock <mm@dorfdsl.de> - 2026-09-09 08:28 +0200
        Re: Updating Slackware Eric Pozharski <apple.universe@posteo.net> - 2026-09-09 09:03 +0000
        Re: Updating Slackware kaukasoina3dore73js4@sci.fi (Petri Kaukasoina) - 2026-09-09 10:19 +0000
      Re: Updating Slackware Jim Diamond <zsd@jdvb.ca> - 2026-09-12 10:16 -0300
        Re: Updating Slackware Marco Moock <mm@dorfdsl.de> - 2026-09-12 15:53 +0200
          Re: Updating Slackware Jim Diamond <zsd@jdvb.ca> - 2026-09-12 14:42 -0300
            Re: Updating Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-09-13 14:11 +0000
              Re: Updating Slackware Rich <rich@example.invalid> - 2026-09-13 14:56 +0000
                Re: Updating Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-09-14 22:40 +0000
              Re: Updating Slackware Jim Diamond <zsd@jdvb.ca> - 2026-09-13 12:29 -0300
                Re: Updating Slackware Rich <rich@example.invalid> - 2026-09-14 15:20 +0000
                Re: Updating Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-09-14 22:52 +0000
                  Re: Updating Slackware "Rinaldi J. Montessi" <rinaldij@alien.free> - 2026-09-14 18:42 -0500
                    Re: Updating Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-09-15 00:51 +0000
                      Re: Updating Slackware "Rinaldi J. Montessi" <rinaldij@alien.free> - 2026-09-14 21:15 -0500
                Re: Updating Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-09-14 23:30 +0000
                  Re: Updating Slackware jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-09-14 21:57 -0400
                    Re: Updating Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-09-16 16:48 +0000
                  Re: Updating Slackware Jim Diamond <zsd@jdvb.ca> - 2026-09-27 21:20 -0300
                    Re: Updating Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-09-28 16:46 +0000
                      Re: Updating Slackware Jim Diamond <zsd@jdvb.ca> - 2026-10-02 15:25 -0300
                        Re: Updating Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-10-02 20:35 +0000
                          Re: Updating Slackware jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-10-03 11:20 -0400
                            Re: Updating Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-10-03 19:27 +0000
        Re: Updating Slackware "Rinaldi J. Montessi" <rinaldij@alien.free> - 2026-09-12 10:31 -0500
          Re: Updating Slackware Jim Diamond <zsd@jdvb.ca> - 2026-09-12 14:38 -0300
            Re: Updating Slackware "Rinaldi J. Montessi" <rinaldij@alien.free> - 2026-09-12 19:05 -0500
    Re: Updating Slackware Joseph Rosevear <Mail@JoesLife.org> - 2026-09-09 09:29 +0000
      Re: Updating Slackware Joseph Rosevear <Mail@JoesLife.org> - 2026-09-09 09:42 +0000
        Re: Updating Slackware Joseph Rosevear <Mail@JoesLife.org> - 2026-09-09 10:31 +0000

Page 1 of 2  [1] 2  Next page →

#35776 — Updating Slackware

If I have just updated slack 15.0 can I then change my config file to 
'current' without disruption?

-- 
Cheers, Bev
    "It's too bad stupidity isn't painful." - A. S. LaVey

[toc] | [next] | [standalone]

#35777

On 9/8/26 12:56 PM, The Real Bev wrote:
> If I have just updated slack 15.0 can I then change my config file to
> 'current' without disruption?

Which config, Bev?

I ran 15.0 until about two months ago when I had to replace my video 
card.  New one works better with the 7.x series kernels so I was forced 
to go to Slackware-current.

No problems with the switch except current IS a moving target.  When 16 
gets released I'm going to freeze it there and do security/required 
updates only.

Rinaldi
-- 
Cogito, ergo dubito

[toc] | [prev] | [next] | [standalone]

#35778

On 9/8/26 11:40, Rinaldi J. Montessi wrote:
> On 9/8/26 12:56 PM, The Real Bev wrote:
>> If I have just updated slack 15.0 can I then change my config file to
>> 'current' without disruption?
> 
> Which config, Bev?

/etc/slackpkg/mirrors

Just change from <whatever> to Slackware64-current

This is his machine, not mine.  I'm permanently stuck at 14.2 unless I 
upgrade my hardware.  Not likely, but something might start leaking 
smoke.  Never can tell...
> I ran 15.0 until about two months ago when I had to replace my video
> card.  New one works better with the 7.x series kernels so I was forced
> to go to Slackware-current.
> 
> No problems with the switch except current IS a moving target.  When 16
> gets released I'm going to freeze it there and do security/required
> updates only.

-- 
Cheers, Bev (Registered Linux User 85683)
   Some people have told me they don't think a fat penguin really
   embodies the grace of Linux, which just tells me they have never seen
   an angry penguin charging at them in excess of 100mph.  They'd be a
   lot more careful about what they say if they had.   -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#35779

On 9/8/26 2:04 PM, The Real Bev wrote:
> On 9/8/26 11:40, Rinaldi J. Montessi wrote:
>> On 9/8/26 12:56 PM, The Real Bev wrote:
>>> If I have just updated slack 15.0 can I then change my config file to
>>> 'current' without disruption?
>>
>> Which config, Bev?
> 
> /etc/slackpkg/mirrors

I keep my own mirror so I use:

#----------------------------------------------------------------
# Local Directory
#----------------------------------------------------------------
# file://path/to/some/directory/
file://usr/src/spkg/CURRENT/
#----------------------------------------------------------------

and then:

rsync -aAXPvh --delete-after --delete-excluded \
--exclude={EFI,isolinux,source,kdei,usb-and-pxe-installers} \
rsync://plug-mirror.rcac.purdue.edu/slackware/slackware64-current/  \
/usr/src/spkg/CURRENT/

Blacklist shouldn't change.

Make sure the destination exists and season to taste.

I like the repository on hand for quick repairs if I screw something up. 
  Internet has been known to go down ;-)

Rinaldi
-- 
Cogito, ergo dubito

[toc] | [prev] | [next] | [standalone]

#35780

On 9/8/26 17:21, Rinaldi J. Montessi wrote:
> On 9/8/26 2:04 PM, The Real Bev wrote:
>> On 9/8/26 11:40, Rinaldi J. Montessi wrote:
>>> On 9/8/26 12:56 PM, The Real Bev wrote:
>>>> If I have just updated slack 15.0 can I then change my config file to
>>>> 'current' without disruption?
>>>
>>> Which config, Bev?
>> 
>> /etc/slackpkg/mirrors
> 
> I keep my own mirror so I use:
> 
> #----------------------------------------------------------------
> # Local Directory
> #----------------------------------------------------------------
> # file://path/to/some/directory/
> file://usr/src/spkg/CURRENT/
> #----------------------------------------------------------------
> 
> and then:
> 
> rsync -aAXPvh --delete-after --delete-excluded \
> --exclude={EFI,isolinux,source,kdei,usb-and-pxe-installers} \
> rsync://plug-mirror.rcac.purdue.edu/slackware/slackware64-current/  \
> /usr/src/spkg/CURRENT/
> 
> Blacklist shouldn't change.
> 
> Make sure the destination exists and season to taste.
> 
> I like the repository on hand for quick repairs if I screw something up.
>    Internet has been known to go down ;-)

Disk space is cheap!

He'd been using the actual name of the version and did periodic updates 
to the specific release.  He's wondering if switching the entry to 
'curent' would somehow disrupt things when he updates or do anything 
else unpleasant.

-- 
Cheers, Bev
     "Tip: Place your houseplants in front of the television during
     the next presidential debate and watch how leafy they get."
                                                 -- Scott Adams

[toc] | [prev] | [next] | [standalone]

#35781

The Real Bev <bashley101@gmail.com> wrote:
> He'd been using the actual name of the version and did periodic 
> updates to the specific release.  He's wondering if switching the 
> entry to 'curent' would somehow disrupt things when he updates or do 
> anything else unpleasant.

It is likely if this were tried that the various upgradings of packages 
would not be in the correct order (the upgrade.txt file on a Slackware 
iso has a specific order in which to upgrade) and the result could very 
well be a system that no longer works (or boots).

[toc] | [prev] | [next] | [standalone]

#35788

On 9/8/26 19:58, Rich wrote:
> The Real Bev <bashley101@gmail.com> wrote:
>> He'd been using the actual name of the version and did periodic 
>> updates to the specific release.  He's wondering if switching the 
>> entry to 'curent' would somehow disrupt things when he updates or do 
>> anything else unpleasant.
> 
> It is likely if this were tried that the various upgradings of packages
> would not be in the correct order (the upgrade.txt file on a Slackware
> iso has a specific order in which to upgrade) and the result could very
> well be a system that no longer works (or boots).

Hadn't thought the order would make a difference...

-- 
Cheers, Bev
    Hmph.  I used to have snow tires.  Never again.  They melted in the
    spring.  I won't even start going on about my wood stove.
                                                         -- websurf1

[toc] | [prev] | [next] | [standalone]

#35789

On 9/10/26 12:51 AM, The Real Bev wrote:
> On 9/8/26 19:58, Rich wrote:
>> The Real Bev <bashley101@gmail.com> wrote:
>>> He'd been using the actual name of the version and did periodic
>>> updates to the specific release.  He's wondering if switching the
>>> entry to 'curent' would somehow disrupt things when he updates or do
>>> anything else unpleasant.
>>
>> It is likely if this were tried that the various upgradings of packages
>> would not be in the correct order (the upgrade.txt file on a Slackware
>> iso has a specific order in which to upgrade) and the result could very
>> well be a system that no longer works (or boots).
> 
> Hadn't thought the order would make a difference...

In my experience slackpkg takes care of that.

However you access the repository, (switching to 
slackware/slackware64-current/ should be adequate) make sure to run 
"slackpkg clean-system" after slackpkg upgrade-all to remove any 
artifacts.  This would require upgrading any third party packages you 
have installed, but they would likely be broken by the system upgrade 
anyhow.  Library version bumps , etc.

Rinaldi
-- 
Cogito, ergo dubito

[toc] | [prev] | [next] | [standalone]

#35782

Am 08.09.26 um 21:04 schrieb The Real Bev:
>>
> 
> /etc/slackpkg/mirrors
> 
> Just change from <whatever> to Slackware64-current

I did it that way.
I recommend creating a full image of you disk with a live system, so you 
can revert to the old state.

Be aware that you definitely need to update the kernel and the older one 
will most likely not work anymore, so be prepared that you need to 
generate initrd and the boot loader config.


-- 
Gruß
Marco

Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de

[toc] | [prev] | [next] | [standalone]

#35785

with <117pm87$bijo$2@dont-email.me> The Real Bev wrote:
> On 9/8/26 11:40, Rinaldi J. Montessi wrote:
>> On 9/8/26 12:56 PM, The Real Bev wrote:

>>> If I have just updated slack 15.0 can I then change my config file
>>> to 'current' without disruption?
>> Which config, Bev?
> /etc/slackpkg/mirrors
> Just change from <whatever> to Slackware64-current

*If* I understand your context correctly, then -- yes, it will be as
disruptive as _upgrade_ (in contrary with _reinstall_) from old proper
to just released proper.  Also, haven't you forgot about SBo?

You probably haven't noticed, but *all* current has been rebuilt for
reasons I ignored,  but there are reasons.  Now compress multiple
reasons for partial and whole rebuilds.  Hopefully, you've got the
picture.

*CUT* [  9 lines   2 levels deep]

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [next] | [standalone]

#35786

The Real Bev  <bashley101@gmail.com> wrote:
>On 9/8/26 11:40, Rinaldi J. Montessi wrote:
>> On 9/8/26 12:56 PM, The Real Bev wrote:
>>> If I have just updated slack 15.0 can I then change my config file to
>>> 'current' without disruption?
>> 
>> Which config, Bev?
>
>/etc/slackpkg/mirrors

It won't work. The order is important. This works:

# < change mirror to current in /etc/slackpkg/mirrors >
slackpkg update
slackpkg upgrade slackpkg
slackpkg upgrade aaa_glibc-solibs gnupg
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-system
# < handle the .new files >
# < if grub then reinstall grub >
# < take care of initrd, boot loader >
reboot

[toc] | [prev] | [next] | [standalone]

#35790

On 2026-09-08 at 15:40 ADT, Rinaldi J. Montessi <rinaldij@alien.free> wrote:
> On 9/8/26 12:56 PM, The Real Bev wrote:
>> If I have just updated slack 15.0 can I then change my config file to
>> 'current' without disruption?

> Which config, Bev?

> I ran 15.0 until about two months ago when I had to replace my video 
> card.  New one works better with the 7.x series kernels so I was forced 
> to go to Slackware-current.

Just out of curiosity, why were you forced to go to Slackware-current?

I am using 6.18.37 with Slackware64-15.0 and haven't yet tried a 7.x
kernel.  Will they not compile (or run) with 15.0?

Thanks.

                                Jim

[toc] | [prev] | [next] | [standalone]

#35791

Am 12.09.26 um 15:16 schrieb Jim Diamond:
> I am using 6.18.37 with Slackware64-15.0 and haven't yet tried a 7.x
> kernel.  Will they not compile (or run) with 15.0?

They are not in the repo of 15.

-- 
Gruß
Marco

Spam bitte an abfalleimer2001@stinkedores.dorfdsl.de

[toc] | [prev] | [next] | [standalone]

#35794

On 2026-09-12 at 10:53 ADT, Marco Moock <mm@dorfdsl.de> wrote:
> Am 12.09.26 um 15:16 schrieb Jim Diamond:
>> I am using 6.18.37 with Slackware64-15.0 and haven't yet tried a 7.x
>> kernel.  Will they not compile (or run) with 15.0?

> They are not in the repo of 15.

Compiling a kernel is (in my experience) a fairly easy thing (if not
somewhat tedious).  So I was sort of curious about why Rinaldi didn't just
do that.

                                Jim

[toc] | [prev] | [next] | [standalone]

#35797

On 2026-09-12, Jim Diamond wrote:

> Compiling a kernel is (in my experience) a fairly easy thing (if
> not somewhat tedious).  ...

It got to a point, quite some time ago, at least in my own experience,
where it became very time-consuming to go through all of the new
configuration options on any kernel release, to learn what they do
and decide whether you need or want it in your custom kernel for a
particular system.  At which point, of course, you start just using
the default configuration with "make defconfig" or "make alldefconfig".
Once you're there, why not just use the pre-packaged kernel?

-- 
----------------------------------------------------------------------
Sylvain Robitaille                                syl@therockgarden.ca
----------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#35798

Sylvain Robitaille <syl@therockgarden.ca> wrote:
> On 2026-09-12, Jim Diamond wrote:
> 
>> Compiling a kernel is (in my experience) a fairly easy thing (if
>> not somewhat tedious).  ...
> 
> It got to a point, quite some time ago, at least in my own 
> experience, where it became very time-consuming to go through all of 
> the new configuration options on any kernel release, to learn what 
> they do and decide whether you need or want it in your custom kernel 
> for a particular system.  At which point, of course, you start just 
> using the default configuration with "make defconfig" or "make 
> alldefconfig".  Once you're there, why not just use the pre-packaged 
> kernel?

If one wants a newer kernel than what is prepackaged for some reason 
[1], compiling it is the faster method of obtaining it vs. waiting for 
the pre-packaged one to eventually reach that newer version milestone.

[1] Most often for one of the reasons of 1) a driver for a device that 
does not exist yet in the prepackaged version, or 2) a driver for a 
feature (filesystem or kernel) that does not exist yet in the 
prepackaged version.

[toc] | [prev] | [next] | [standalone]

#35805

On 2026-09-13, Rich wrote:

> If one wants a newer kernel than what is prepackaged for some reason
> [1], compiling it is the faster method of obtaining it vs. waiting for
> the pre-packaged one to eventually reach that newer version milestone.

I've been in that situation (sort of; when -current switched to 6.18.x
kernels, the (third-party) device driver for my RAID controller failed
to compile on the newer kernels.  For a few months, I was updating 6.12.x
kernels, using Slackware64-current's kernel SlackBuild script to ensure
that the configuration matched what *would* have been in a prepackaged
kernel.  It wasn't perfect, but it was *as though* I was still using a
prepackeged kernel.  I've since created a patch for the RAID device
driver, (mentioned elsewhere in this newsgroup if you're curious).


> [1] Most often for one of the reasons of 1) a driver for a device
> that does not exist yet in the prepackaged version, or 2) a driver
> for a feature (filesystem or kernel) that does not exist yet in
> the prepackaged version.

Fair enough, though I'd guess that's mostly a historical concern.
I'm sure that it can still happen, of course, but it seems to me it's
likely rather exceptional when it does.  I'm sure that my experience
might border on the exceptional in the other direction, though.
Most of my computer gear, save for perhaps the SSDs in my laptops is
well more than a few years old, and (with a couple of exceptions that
need vendor-supplied drivers, compiled outside of the kernel itself,
such as the RAID controller mentioned above, and an Nvidia graphics
card) very well supported with the pre-packaged kernels.

-- 
----------------------------------------------------------------------
Sylvain Robitaille                                syl@therockgarden.ca
----------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#35799

On 2026-09-13 at 11:11 ADT, Sylvain Robitaille <syl@therockgarden.ca> wrote:
> On 2026-09-12, Jim Diamond wrote:

>> Compiling a kernel is (in my experience) a fairly easy thing (if
>> not somewhat tedious).  ...

> It got to a point, quite some time ago, at least in my own experience,
> where it became very time-consuming to go through all of the new
> configuration options on any kernel release, to learn what they do
> and decide whether you need or want it in your custom kernel for a
> particular system.  At which point, of course, you start just using
> the default configuration with "make defconfig" or "make alldefconfig".

You are right that it is time-consuming to go through all the new options.
Particularly if you are making a jump of many versions.

Having said that, I've found "make oldconfig" (after copying your current
.config into the source dir) to be fairly fast, especially if you take the
default choice for all the new ones.  I've never had a problem with doing
that, but no doubt someone, somewhere has had issues from that.


> Once you're there, why not just use the pre-packaged kernel?

Well, because of this...

If I recall correctly, the OP went from 15.0 to -current to get a 7.x
kernel.  While it is good that many people out there are actively keeping
up with -current and using/testing it, the reality is that -current is not
stable like 15.0 is, and any given update might break something (DAMHIKT).
So if the OP wanted a stable system, compiling the kernel (even using the
.config from -current, thus avoiding all those questions) is more likely to
give him a stable system.  (But maybe that's not an issue for him.)

That's all... I just wondered if there was some reason why 7.x was somehow
incompatible with 15.0 or hard to compile on 15.0.

Cheers.
                                Jim

[toc] | [prev] | [next] | [standalone]

#35804

Jim Diamond <zsd@jdvb.ca> wrote:
> That's all...  I just wondered if there was some reason why 7.x was 
> somehow incompatible with 15.0 or hard to compile on 15.0.

Given the kernel (well Linus's) desire to "not break userspace" it is 
most often the case that the newer kernel's /work/ just fine (as in, 
they boot, and the system operates much as it did before the swap).

Where the issue often arises is that to actually make use of new kernel 
features (note, "feature", not "device driver") often requires a new 
glibc that knows how to make the proper syscalls for the new features.

So while you very likely can compile, and run, the absolute latest 7.x 
on Slack 15.0, it is also likely that some of the 'latest and greatest' 
new kernel features are not usable because Slack 15's glibc does not 
yet know how to make use of them.

[toc] | [prev] | [next] | [standalone]

#35806

On 2026-09-13, Jim Diamond wrote:

> Having said that, I've found "make oldconfig" (after copying
> your current .config into the source dir) to be fairly fast,
> especially if you take the default choice for all the new ones.
> I've never had a problem with doing that, but no doubt someone,
> somewhere has had issues from that.

... or, if you don't actually need any functionality beyond the
defaults, you could use the kernel SlackBuild script from your favourite
Slackware version (or perhaps the version with the prepackaged kernel
closest to the kernel version you want to use), and build your custom
kernel as an actual Slackware package.  Makes maintenance and eventual
migration back to prepackaged kernels very simple.

> If I recall correctly, the OP went from 15.0 to -current to get
> a 7.x kernel.  While it is good that many people out there are
> actively keeping up with -current and using/testing it, the reality
> is that -current is not stable like 15.0 is, and any given update
> might break something (DAMHIKT).

Right, though as has been mentioned elsewhere, there's a reasonable
possibility that the newer i(prepackaged) kernel would, in fact,
have just worked for the OP on Slackware-15.0.  I'd be interested
to know if that was tried and uncovered any reasons that resulted in
them being "forced" (their wording, iirc) into -current.

> That's all... I just wondered if there was some reason why 7.x was
> somehow incompatible with 15.0 or hard to compile on 15.0.

I share that curiosity, though I admit that it isn't strong enough
to have tried it myself.

-- 
----------------------------------------------------------------------
Sylvain Robitaille                                syl@therockgarden.ca
----------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.os.linux.slackware

csiph-web