If I have just updated slack 15.0 can I then change my config file to 'current' without disruption?
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.
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
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 ;-)
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.
/etc/slackpkg/mirrors
Just change from <whatever> to Slackware64-current
If I have just updated slack 15.0 can I then change my config file to 'current' without disruption?
On Tue, 8 Sep 2026 10:56:04 -0700, The Real Bev wrote:
If I have just updated slack 15.0 can I then change my config file to
'current' without disruption?
I get my updates from: https://mirrors.slackware.com/slackware/slackware64-15.0/
And I run a bash (#!/bin/sh) script as an ordinary user to do updates.
The script runs "slackpkg update gpg", then slackpkg update,
install-new,
upgrade-all and clean-system.
It works for me!
-Joe
On 9/8/26 11:40, Rinaldi J. Montessi wrote:
On 9/8/26 12:56 PM, The Real Bev wrote:
/etc/slackpkg/mirrorsIf I have just updated slack 15.0 can I then change my config fileWhich config, Bev?
to 'current' without disruption?
Just change from <whatever> to Slackware64-current
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
Oops. I don't know if it matters, but *actually* my notes say run the
script as *root*. I'll go try it now and report back.
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).
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...
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.
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?
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.xMy reading tells me that the i915 and xe modules are significantly
kernel. Will they not compile (or run) with 15.0?
On 9/12/26 8:16 AM, Jim Diamond wrote:
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?
VGA compatible controller: Intel Corporation DG2 [Arc A580] (rev 08)
Resizable BAR (Base Address Register) is a PCI Express feature that lets your CPU access your video card's entire memory pool at once instead of
in small 256MB pieces.
I am using 6.18.37 with Slackware64-15.0 and haven't yet tried a 7.xMy reading tells me that the i915 and xe modules are significantly
kernel. Will they not compile (or run) with 15.0?
improved in the 7.x kernels for the Arc A580.
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.
My reading tells me that the i915 and xe modules are significantlyGood to hear about these improvements. But I'm still curious...
improved in the 7.x kernels for the Arc A580.
Is it that you didn't want to compile your own kernel on 15.0, or was there something preventing you from doing so?
Compiling a kernel is (in my experience) a fairly easy thing (if
not somewhat tedious). ...
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?
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?
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.
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.
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.
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).
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.
... 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.
I had to buy a new video card and chose an Intel AsRock A580. ...
Problem stemmed from dmesg indicating that the card would be happier
with Resizable BAR enabled. Since I was a lilo hold out booting in
legacy mode and my BIOS required UEFI for ReBAR, I basically had to
scrap 15.0 with the 5.15.209 kernel.
In summary, the testing/packages/linux offerings work flawlessly.
Perhaps it's as much the video card quirks, my inexperience (I've only
been doing slackware for 25 years), and bad advice.
Oddly enough, just today, while performing package updates
on my workstation, I ran into a problem during the update to aaa_glibc-solibs-2.44-x86_64-5, where the system became unusable
(except for any process already running) while upgradepkg was running
the doinst.sh script. It seems that /lib64/ld-linux-x86-64.so.2 got
removed, following which any attempt to execute any new programs
(including those needed to complete the doinst.sh script and the
update to that package) was failing.
On 2026-09-14, Rinaldi J. Montessi wrote:
I had to buy a new video card and chose an Intel AsRock A580. ...
Ah yes; I do recall you mentioned that already.
Problem stemmed from dmesg indicating that the card would be happier
with Resizable BAR enabled. Since I was a lilo hold out booting in
legacy mode and my BIOS required UEFI for ReBAR, I basically had to
scrap 15.0 with the 5.15.209 kernel.
Ok, so if I'm understanding correctly, needing both a newer kernel and a switch to uefi meant you were going to be reinstalling anyway?
I appreciate your clarifying that.
Perhaps it's as much the video card quirks, my inexperience (I've only
been doing slackware for 25 years), and bad advice.
Inexperience? I'm only about 6 years ahead of you, and if I think
back to 6 years ago, I doubt that I could claim "inexperience".
Bad advice on the other hand ... ;-)
Thanks for following up ...Rinaldi
Do you mean this? https://www.linuxquestions.org/questions/slackware-14/missing-%24-before-%7Blibrary%7D-in-new-glibc%27s-doinst-sh-script-4175766980/
It's fixed now but the mirrors didn't get the update yet, ...
Nothing like a good old glibc borked update. XD
(rather tangential to the discussion, I suppose, so I'm replying a second time to the same message ...)
On 2026-09-13, Jim Diamond wrote:
... the reality is that -current is not stable like 15.0 is, and
any given update might break something (DAMHIKT).
I would word it as "not intended, nor guaranteed to be stable ...", but
in practice, after nearly a year of running -current on my workstation,
and at least six months with it on a couple of other systems that get
daily use, and performing periodic (not daily, nor even weekly, mind
you) package updates, I find that in practice, Slackware64-current,
is *quite* stable and reliable.
The caveat, of course, remaining that there is no guarantee of that, and
I certainly wouldn't use -current on production systems at work.
Oddly enough, just today, while performing package updates
on my workstation, I ran into a problem during the update to aaa_glibc-solibs-2.44-x86_64-5, where the system became unusable
(except for any process already running) while upgradepkg was running
the doinst.sh script. It seems that /lib64/ld-linux-x86-64.so.2 got
removed, following which any attempt to execute any new programs
(including those needed to complete the doinst.sh script and the
update to that package) was failing.
After some (manual) troubleshooting, I was able to confirm that the
system was otherwise ok, and that this was not the disaster that it
appeared to be, and I managed to move the contents of /lib64/incoming
into /lib64 (as the doinst.sh script would have done had the library
loader not disappeared),
and from there I was able to restart my package updates. (well, I
finished manually running the commands from doinst.sh, then restarted the rest of my pending updates.)
I was going to report this to Patrick, of course, but upon careful examination of doinst.sh (and the diff against the previous version),
I don't see how this problem could have happened, so I wouldn't know
what to report. Was there perhaps some lingering artifact on just this
one system that caused this? If so, that's obviously for me to fix,
not Patrick. In any case, my updates are continuing now, without issue.
All of that to say that despite -current being a development branch with
no promise of stability, in practice it usually works just as well as the stable branch. When things do go wrong, the key is to not do anything drastic. The problem is very likely simpler to solve than it might seem.
After some (manual) troubleshooting, I was able to confirm that the
system was otherwise ok, and that this was not the disaster that it
appeared to be, and I managed to move the contents of /lib64/incoming
into /lib64 (as the doinst.sh script would have done had the library
loader not disappeared),
Did you have a statically linked mv or cp lying around, or did you do something trickier?
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 121:06:35 |
| Calls: | 1,194 |
| Files: | 1,352 |
| Messages: | 290,204 |