Simple question.
Can I upgrade directly from SW 9.1 to 10.1?
Thanks
George

The answer to your question is no. It will require a little work, so I wont say its simple.

Here is a link that will provide you with the information on upgrading your Slackware.

http://www.linux.com/howtos/Upgrade/index.shtml

Some things changed from 9.1 to 10.1, Pat provides a file in 10.1 to upgrade from 10.0, but I don't think it will work from 9.1 (you could try anyways).
Here is the file (it's included in 10.1 CD 1): http://ftp.scarlet.be/pub/slackware/....1/UPGRADE.TXT

gbonvehi
Thanks...I d/loaded the 4CD's for 10.1, and read the upgrade document, and yes it is entitled from 10.0 to 10.1...Hmmmmmmmmmmmm
What to do with all those 10.1 CD's!
George
P.S My feeling is that the has to be a way..but it is just a feeling...

Just to save some bandwidth next time, CD 3 and 4 contain sources of all apps in CD 1 and 2, they're not needed to install Slackware.

Guys - many thanks, but you know, I feel that there HAS to be a way (relatively simple) to go from 9.1 to 10.1. These are not majojr revisions.
Why do I say this? because it is true foe the laegest and most complex OS's (IBM's mainframe aka MVS, aka z/OS, aloso of its other "formal subsystems" (like its RDBMS's, etc permit you to skip a release), and even the dreaded WIN allows this (as far as I know).
Just my 2 bits......

Well, now that I think it there weren't too many changes that could break the system, it should work the update from 9.1 directly to 10.1 but I don't have a machine to test it, so it's all in your hands

Guillermom and friends
Pardon this cross-posting, but I would like to continue this thread. I have decided to upgrade from Slackware 9.1 to 10.0 (the endorse strategy), and am now in the position of wondering what - if anything - I must do having recently successfully installed XFRee86 4.5.0 (the most current) in accordance with X's own installation script (and not with any native Slackware packaging mechanism).

I'm just not skilled enough in the ins and outs of the vagaries of Linux software packaging to know how to do it best. If I knew how, I could uninstall what I have from X itself - but I have no procedure to do so: the X tarballs came with an interactive Xinstall.sh script (which was quite nice actually, called the XFRee86 4.5.0 installer), but not a corresponding uninstall. I don't think this is a great idea (for me to somehow remove X).

Alternatively I could install all the Slackware software EXCEPT the packages in the "X" directory (and hope I am not missing something that might be needed): this also means running the upgradepkg --new-install ...../*.tgz one by one, so to speak (rather than with the wildcard upgradepkg --install-new /root/slackware/*/*.tgz), and omitting the "X" directory, from that sequence.

Finally, I could forget all about it, worry less, and just install the lot (with the wildcard), and hope that all conflicts would be magically resolved! (As in: "What, me worry"?)

I would be grateful for any advice on this please

****Separately, I am intrigued by Patrick Volkerding's item 6 of his UPGRADE.TXT HOWTO file, when he refers to changes which "might" need to be made to config files, and the .new incoming config files, and the copying of existing files to *.bak. I am afraid I cannot make head or tail of his meaning. And his English is pretty good, and so is mine, and I am not a moron. In fact, I have been a Systems Pgmmer on and off, since 1980 on the largest computers in the world (Honeywell, IBM), and I just cant grasp what it is that the user must do - if anything - with his existing configuration files when moving from one release to the next. (I have already save a copy of my /etc directory and all its sub-directories.)
Thank You
George

Hi again...I read another HOWTO on upgrading S/Ware, and read this comment (similar to Patrick's):
"Merge the new configuration files with your old ones. The newly installed configuration files will have the file extension ".new" Most, if not
all, of the new configuration files will be located in your /etc directory. You can generate a list of these files
like so:
# find /etc -name \*.new
Fold any changes you made to the previous versions of the
configuration files into the new files, as necessary. Then
rename the new configuration file to the name of the old
configuration file (the same name, without the .new extension, conveniently.)'

What does it mean to "fold any changes you made to
the previous versions of the configuration files into the
new files, as necessary".
How does one know which files have changed over the lifetime of an installation?. And does one simply copy the old (.bak) over the new (.new) or identify the private customizations, and re-modify the .new's, by hand, one by one. This is clearly impossible. Is that what is being said? i.e. that the structure of the new .conf's is unchanged and we just copy the (customized) backups and overlay the .new's?
Maybe so! I just don't know.

This is quite new to me. For example, I recently upgraded my IBM DB2 UDB RDBMS from 8.1 which has vital configuration files for the DBManager (aka "instance"), and each of the databases themselves. Now a completely new feature - 'High Availability Disaster Recovery' (HADR)' was added to 8.2, and this caused several brand new HADR-related entries to be put in the DBM CONFIG file (see end end of posting). It would be completely wrong for me to copy the old over the new. The alternative would be to reconfigure the new from scratch, and there may have been dozens, even hundreds of careful changes, literally, made over years. Let me say this is not an OS .conf file, but a config file nonetheless, and the kind I have had experience with, so I can only go with my prior experience. In other words, the install "restructures" the config file (if required), while maintaining the current content, the current data.

Please bear with me as this is my first UNIX/LINUX-related system software (OS) upgrade. It is possible I am making this more complex than it really is, but this is the only thing I can't grasp about the upgrade procedure. Otherwise it seems poretty painless.

Here are some of the completely new features added, as mentioned above, while retaining all prior customizations made by the DBA over the years.
HADR database role = STANDARD
HADR local host name (HADR_LOCAL_HOST) =
HADR local service name (HADR_LOCAL_SVC) =
HADR remote host name (HADR_REMOTE_HOST) =
HADR remote service name (HADR_REMOTE_SVC) =
HADR instance name of remote server (HADR_REMOTE_INST) =
HADR timeout value (HADR_TIMEOUT) = 120
HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
George

For those hardy souls who stay absolutely current, what is folks general experience with S/Ware 10.1, in terms of general robustness (Reliability, Availability and Stability/Serviceability), and major perceived improvements over 9.1?

If warranted, my goal would be to bypass 10.0. The UPGRADE.TXT notes seem identical from 9.1 to 10.0, and then from 10.0 to 10.1...that is my t

And separately, are most people using XFRee86 or Xorg windowing system? It's my understanding that SW may have moved over to Xorg, and I recently upgraded my own X to the current 4.5.0 XFree86, without even realizing there was a licensing dispute and that various distros - (presumably including S/Ware) were going with Xorg. So guess I have introduced a packaging incompatibility in my X windowing system....
Thanks
George

On the subject of upgrading (from SWare 9.1), Patrick V's UPGRADE.TXT step 5 says to "make sure your system will boot".
My question is simple (I think). I don't see any reference - anywhere - to recompilation of the kernel (and/or modules: of course I realize we are installing compiled code).
Is this NOT required when upgrading?
Aren't we bringing in a new copy of the kernel (say, bare.i), when upgrading? In which case wouldn't it have to be reconfigured to contain the same parms and modules as the one we currently have in place?
Or am I wrong, am I completely missing something very basic here?

Two additional (separate) questions: do people see much aggravation migrating directly to 10.1 (and bypassing 10.0)? The instructions for going from 9.1 to 10.0, and then from 10.0 to 10.1 are poretty much identical.

And finally, Are most people using x.org for their X system, as opposed to XFRee86? Does it make much difference? I believe that SW uses x.org (note #6 talks about changing xorg.conf to reflect the new name of the Keyboard driver (to "kbd"). )
Thanks
George

Last question first, as far as I can see there's no difference in use between xfree and xorg.

With regards to upgrading rather that doing a clean install, as long as everythings backed up and home is on a seperate partition you've got nothing to loose by trying the upgrade. I'm sure other people will disagree though.

priller, thanks for the quick reply. - I have backed up /etc directory, and all-sub trees: and am not in a position to do a clean install: this is a working system with costly 3rd party products configured over a long time (IBM DB2 UDB RDBMS...).
I'm just surprised that there is no reference to re-compiling kernel.
I have to assume it is simply not required (whcih makes life a little easier, of course).
Thanks
George

TBH if you aint in a position to do a clean install I'd be wary of upgrading at all. Just my opinion though.

priller - If a clean install will not undo what I currently have in place (other products, various configuration files and customizations, etc,) then I would happily do it. My guess is that it would (be disruptive). So I guess this gets down to the question : How does a clean install substantially differ from an upgrade?
Thanks
George