Need download of OpenSUSE 12.1

I need a download of the ISO of 12.1 but every time I download it from official OpenSuse servers and burn it and try to install it - it shows up as 12.2. I know it is an older version - the only reason I need it is to install it on a machine so I can test upgrade scenarios before I try it on my production server. Anyone know where I can actually get a 12.1 install?

Thank you.

It’s unsupported
http://ftp5.gwdg.de/pub/linux/suse/opensuse/distribution/12.1/iso/

I know it is too old to be supported but shouldn’t I, at my own peril, be able to get it? I have a DVD of it (somewhere)…I guess my next question would be would you feel comfortable going from 12.1 to 13.1? It is just a standard install (well as standard as any I guess could me) with phpmyadmin, mysql, samba. We did not go out and get any special repositories. This was the first one that we had in my organization and we contracted with an outside vendor to help. Now we have that one, and two production 12.2 servers and one production 13.1. I still am somewhat a greenhorn…

Oh yes (and caf4926 gave you the link), but we like to warn because people do have the strangest ideas about using pre-historical versions.

Then why do you ask for it?

First try a live version.

I would recommend a new install. Of course while keeping the personal data of the users (and other application data). Which of course easiest done when you have a separate home partition. Nevertheless, you should make a good backup. And a backup of /etc so you can compare old configs with those on your new system.

On 2014-01-16 15:36, jpeteet wrote:
>
> I know it is too old to be supported but shouldn’t I, at my own peril,
> be able to get it? I have a DVD of it (somewhere)…I guess my next
> question would be would you feel comfortable going from 12.1 to 13.1? It
> is just a standard install (well as standard as any I guess could me)
> with phpmyadmin, mysql, samba. We did not go out and get any special
> repositories. This was the first one that we had in my organization and
> we contracted with an outside vendor to help. Now we have that one, and
> two production 12.2 servers and one production 13.1. I still am somewhat
> a greenhorn…

If you are testing upgrades, remember that a “zypper dup” of such a
distance is not supported. A DVD boot, choose upgrade, I believe it is.

I just did a 11.4 -> 13.1 upgrade recently.

Online upgrade
method

Offline upgrade
method

Chapter 16. Upgrading the System and System Changes
Chapter 16. Upgrading the System and System Changes
openSUSE 12.3 Release Notes
openSUSE 13.1 Release Notes


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

A new install is likely out of the question due to using the same machine after the upgrade that I currently am using. I only have one spare machine and it is not same spec as current production system - which will make my attempt to ‘test upgrade’ moot anyway.

I appreciate all your help and suggestions.

I do not quite understand this. I assumed the existing hardware. My suggestion is to not try the Upgrade feature on one of the first screens of the install DVD. I assume your jump is to big for it to garantee much.

So if it is too big - would I need to do an intermediate upgrade from 12.1 to 12.2, test everything, then try to bump up to 13.1?
Thank you for taking to time to educate me.

You forgot 12.3 as intermediate step.

But I do not understand your hesitation to install 13.1 directly (of course keeping all user/application.database data). It is realy not much more then “upgrading” (what ever that means). All software must be installed anew. Everything you installed in 12.1 will have newer versions in 13.1.

I allways install anew. Even if it is the next openSUSE version. It is the chance to clean up things. Many do an upgrade when it is only one version difference, either online, or using the DVD image. But I would never try these methods going from 12.1 to 131.

You may of course think different, but you seem to have some fear for an installation and I do not understand why.

On 2014-01-16 20:36, jpeteet wrote:
>
> So if it is too big - would I need to do an intermediate upgrade from
> 12.1 to 12.2, test everything, then try to bump up to 13.1?
> Thank you for taking to time to educate me.

Using “zypper dup” I would certainly go one version at a time.

Using the DVD method, I would risk one step only, but making a full
backup just in case.

I posted a link to the known documentation on another post.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

On 2014-01-16 20:56, hcvv wrote:
>
> You forgot 12.3 as intermediate step.
>
> But I do not understand your hesitation to install 13.1 directly (of
> course keeping all user/application.database data). It is realy not much
> more then “upgrading” (what ever that means). All software must be
> installed anew. Everything you installed in 12.1 will have newer
> versions in 13.1.

It is very different on servers.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Why?

Serving what?

On 2014-01-16 21:46, hcvv wrote:
>
> robin_listas;2616646 Wrote:
>>
>>
>> It is very different on servers.

> Why?

Because the configuration of servers is not stored under /home, so it is
no preserved. Neither is the data. You have to install the same package
list, then you have to know what configuration files to carry over. If
you are not the original designer of the server, things are more
complicated.

With a proper upgrade procedure most of that is migrated automatically.
There will be problems, of course, but you don’t have to redo absolutely
everything.

> Serving what?

Whatever. I don’t know what the OP has.
Maybe ftp, http, nfs, smtp, smb, imap, databases, named…

The OP said it was a production server, and he is trying to experiment
upgrade procedures on another machine.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Then what of what I said earlier and that you quoted is not applicable to a “server”

> But I do not understand your hesitation to install 13.1 directly (of
> course keeping all user/application.database data). It is realy not much
> more then “upgrading” (what ever that means). All software must be
> installed anew. Everything you installed in 12.1 will have newer
> versions in 13.1.

You say that for a "“server” it is different. What of the above is different?
Going from 12.1 to 13.1 all installed sofware would have new versions. Is that different from a server?
Keeping user/application/database data during such an installation is IMHO a nessecity for a “server” as well as for “desktop” as for a “laptop”, etc. Even if you think that the home part of those data is neglegible for a server in your opinion (which it is mostly not when you do proper management), it still holds true.
And also IMHO the effort difference between an upgrade method and a new installiation will be the same for a “server” as for another type of system.

Where is it difference?

On 2014-01-16 23:06, hcvv wrote:

> Where is it difference?

The difference is that for an upgrade you keep all your system data
and user data and configuration files intact. Everything. As each
package is upgraded, if its designer have done it properly, the old
configuration files can be parsed and migrated. If not, the rpm either
leaves the old config files in use, or leaves the new ones with the old
renamed. It is just a question of getting the list of those config files
(there is a file that lists them all) and apply the needed changes.

The result is that most services work from the first boot. No need to
copy files from the backup of the previous install and redo - provided
you know what files to touch.

It is less work to do an upgrade.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

So the only difference is configuration files.

But my assumption is that automatic upgrading configuration files of an application may be done correct when you upgrade one version of an application. But the application version jump in this case will probably be as large as that of openSUSE. And application maintainers do not tend to support all those jumps accumulative.

I would not take the chance. In any case, as a system manager you would have notes/backups on how you organised the system (I backup /etc on all systems, to be able to consult them after an update/upgrade/new install). You also have to check if any newer version of application/database software has new/depricated functionality to begin with. In that whole process the keeping of old configuration files on the system can even be more of a burden. And it leads to old rubish in the system.

But you can manage your systems in your way. I only advised the OP based on my experiences.

On 2014-01-17 10:26, hcvv wrote:
>
> So the only difference is configuration files.

And that you automatically get the same list of packages, or their
replacements, when they are system services.

> But my assumption is that automatic upgrading configuration files of an
> application may be done correct when you upgrade one version of an
> application. But the application version jump in this case will probably
> be as large as that of openSUSE. And application maintainers do not tend
> to support all those jumps accumulative.

Some do.

I have been upgrading my system continuously since 1998, and it works.

When they don’t, you have to compare the old and the new files, and
choose what to port from the old to the new config. Granted, this is the
same as for a new installation, with a backup of the old /etc. But, the
upgrade procedure automatically generates a list of what files you have
to check.

My trick is to use “meld”, from KDE. It is an editor that opens two
files side by side, comparing them. With a single click you can copy
entire paragraphs from one file to the other, in any direction, or erase
blocks… very nice utility to migrate plain text configs.

> I would not take the chance. In any case, as a system manager you would
> have notes/backups on how you organised the system (I backup /etc on all
> systems, to be able to consult them after an update/upgrade/new
> install).

AHH! But that is a crucial step that many people don’t do. And those
that do are often not that strict as to be completely reliable. If you
miss a service not installed, a configuration file different from default…

Of course, you can run an rpm query to find out what config files differ
from the default configs, previous to install the new system.

> You also have to check if any newer version of
> application/database software has new/depricated functionality to begin
> with. In that whole process the keeping of old configuration files on
> the system can even be more of a burden. And it leads to old rubish in
> the system.

Well, that is the same case as many do: simply copy over the config
files from the old backup, without thinking.

The process is the same for a new install replacing an old one, as for
an upgrade in place: you have to review all configs. The advantage is
that it is working earlier, as you continue the review. Or, you can do
the review previous to the upgrade to save time.

Another strategy is to install a new server side by side the old one,
replicating all services one by one. When done, switch over. If it
fails, the old one is still available…

> But you can manage your systems in your way. I only advised the OP based
> on my experiences.

Same as I do :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

I appreciate all of your inputs. And your conversations have given me several new things to think about. My main trepidation with just doing a fresh install is that this is a production server and when I start that procedure there is really no fall back. Ok I know a known, good backup is the ultimate fallback. But at that point I am stuck either trying to bang out the new/fresh install or dump that and reinstall the old OS and copy all the related configs/settings from the backup. The pain point for me is where to draw the line between the two.

Of course all that is assuming worst-case-scenario…Where there is the chance that the upgrade will work - or at least mostly work upon in-place upgrade. I hope that makes sense…

Again - I appreciate your input.
John

I can only repeat that I do not see your concern that installing fresh would be more dangerous then upgrading of any kind. A broken upgrade would most certainly leave you at a point were you do not know what is overwritten which a newer version and what not. It would make you to recover from your backup in the same way as with a broken install.

But in the end, it is up to you to decid

Very good point - and likely the best reasoning for just doing a fresh install.