@bitfuzzy Clonezilla looks good but its not apparently available for slackware ;however I have been looking into that scenario. Firstly i tried partimage and got a load of 2gig files.The last one i tried (so far) has been FSArchiver http://www.fsarchiver.org/

I went about it this way : booted up knoppix from laptop having slackware. installed fsarcher (it has overlay) mounted an external hard-drive then :
# fsarchiver -v savefs mnt/ofexternalHd/fileName.fsa
/dev/sda2

it was fast and went well.

Getting back to topic:

Now this does not really fit in with the concept of Gino D'Acampo to using slackware, but i guess i should really get another laptop, install the September current dvd iso.
Read up docs hope they are up to date and correct Then give a go at upgrade.


[edit t of course even if clonezilla was available i wouddn't be able to use it i don't think from the OS running on laptop( slackware) so i guess i could just get clonezilla onto a usb and boot that up ]

Absolutely! The tried and true methods always work. I'll use those commands too particularly when I'm installing Slackware packages like Chrome.

Slackpkg+ is a tried and true method that always works. Like any other method, it is only as good as its setup.

@mlangdn i think i saw an article on Alien Bobs blog about slackpkg+

I guess i am going to have to do quite a bit of reading

for personal use, not server use, this works for me, at least 3 partitions:

/dev/sda1 /
/dev/sda2 /home
/dev/sda3 swap

re-install everything on /dev/sda1 every-time you own a fresh iso, provided you don't have too many customization going on.
installing a fresh operating system without impacting your precious home directory.

Not really. There are a probably a lot of hidden directories and files in your $HOME directory, part of which you could want to keep but would be modified after installation when running the updated software. Better save them all before upgrading then after having used the system since some time after having upgraded make a diff saved vs new and check carefully the output before deciding what to do.

I usually also create sda4/sda5 (or whatever you want to name them) with ~20 GB of space each. This lets me keep sda1 with my previous config, install a new version on sda4 or sda5 and test it out. Worst case, if anything breaks, just reset the active boot partition back to sda1, and go back to what I had before...

Just to toss in my <insert preferred currency> 0.02;

Both of these questions are quite well answered in this thread already.
I would, however, like to add something about how I handle Q2).

As mentioned elsewhere (at the very least indirectly), at some point in time (aka release time), -current and -<next-version> will be the exact same file trees.
At that point your install (given you have all the latest updates at that point installed) will for all intents and purposes be the -<next-version> (read: -15.0 for this release cycle).
What your install will continue to be after that point in time depends on if you (as also mentioned elsewhere) continues to upgrade from the -current three or if you switch over to upgrade from the -<next-version> tree.

My personal take is; At release time, for all machines I want to become -<next-version> I would tend to do a full reinstall of the OS. That would include backing up all home directories, and of course things like /etc (in most cases just to be sure I don't forget about any tweaks I might have done).
I would typically not just keep home directories in place because the default dot files may have changed, and I like to start fresh.
Why reinstall the OS? A bit of the same as not directly reusing the home directories.
Getting rid of old crud that likely have accumulated.
It is *very* likely that on my -current install (depending on how old it is at the -<next-version> release date) will not be as up to date as a fresh install would be.
There *will* be - at least some - .new config files here and there in /etc that I have not updated. There will also likely be some removed software I have forgotten to remove, etc.
Also, it may be a good time to update/upgrade locally-compiled software (including, but certainly not limited to SBo packages).

It's a good point to start fresh. At least in my opinion.
There may, of course, be good reasons to not do it this particular way, but this is how I look at it.

--
KarlMag

/etc/slackpkg/blacklist on 14.2+ 64 bit

quote[
# Automated upgrade of kernel packages aren't a good idea (and you need to
# run "lilo" after upgrade). If you think the same, uncomment the lines
# below ]


would it not be better then to have as default /etc/slackpkg/blacklist :
kernel-generic
kernel-generic-smp
kernel-huge
kernel-huge-smp
kernel-modules
kernel-modules-smp
kernel-source


& then have in docs to hash entries above to upgrade kernel ?

The key word above is "Automated". Since I do any updates manually, after reading the Changelog, I know what's being updated and act accordingly.

Ditto!

Same here

I'll be starting fresh. Though I understand doing an in-place upgrade works REALLY well in Slack, if I never do a fresh install I'll always be thinking I'm not getting the genuine pure Slackware experience... That's just my OCD paranoia and complete trust in PV shining through though.
Karlmag's points are concrete/spot on.

I would like to continue this thread if thats ok , if not (tell me) and i may start a new one. So i would like to look at this from going from current September version and wanting to update it to current now.

If this was repeated say to the day or day before 15 is released then current == release15
and so this is why i think my post is not incongruous with thread title

So i have been reading https://mirrors.slackware.com/slackw.../README.initrd which is dated yesterday. I like the idea of manually installing bit by bit. To be fair its quite readable even for me !

So bare with me if you will
so i have my slackware 14+ using 4.19.75 kernel up and running.
I get:

installpkg kernel-generic-5.4.12-x86_64-1.txz
installpkg kernel-modules-5.4.12-x86_64-1.txz
installpkg mkinitrd-1.4.11-x86_64-14.txz

and install then follow instructions as per mini how to.

So after I should have a system running a a kernel-5.4.12 on my 64 bit pc but with some issues on packages
that i installed previously. I then remove old kernel.txz ?

I then since i just installed 5.4.12 I can blacklist kernel entries on /etc/slackpkg/slackpkg.conf (maybe i also think about setting up slackpkg+)


in principle is there anything wrong with this approach to upgrading system step by step

In the specific example you mentioned with the kernel-generic, kernel-modules, and mkinitrd, I don't foresee any problems (although, you'll probably want to also upgrade the kernel-firmware package and install kernel-source, if you need to compile any modules). The issue ends up being when you decide to upgrade something like python, but don't upgrade all the packages that rely on python's .so files. This could cause those programs to not open at all. So depending on what you upgrade, it could cause you problems with other applications. It would be quite a bit easier to just use slackpkg to upgrade the whole system at once.