Updating From 10.2 To 10.3 Rc1

Are there any probems, bugs with the updater in suse 10.3rc1?
I am planning an early upgrade of my 10.2 machine and was windering if anyone has gone throught the process of the same upgrade, and if they had any problems.

I'm guessing all the settings from the earlier install are kept durring an upgrade?

I'd suggest not to do it as will many others if you have a separate home this is a minor inconvenience. Just mount the old home making sure you don't format over.

If it does go wrong trying to work out where it has, is a lot harder than a fresh install. Some will suggest keeping a variety of additional folders than home depending on extras you've installed and users.

If your not concerned and are open to it going wrong then try but troubleshooting it afterwards maybe a lonely thing. But then you maybe lucky and wonder what all the noise was about as you sit there with a nice new distro.

Thanks for the reply.

I guess my concern is that I don't remember ALL the changes I've made to my current machine, and when I do the change over to 10.3 (if I was going to do a fresh install) I would lose out on some of the features...

I do make nightly system backups (automated, made by the Yast system backup tool) which only backus up the changes from the base install... Current system is 10.2.
Could I use that backup file to somehow 'restore' my changes to a 10.3 os (even though the backup was made in 10.2)?

I guess my concern is that I don't remember ALL the changes I've made to my current machine, and when I do the change over to 10.3 (if I was going to do a fresh install) I would lose out on some of the features...[/b]

That is the ENTIRE point of keeping the same /home partition (as advised by FeatherMonkey). Typically most of the user settings are stored on /home/username/.some-file-or-directory. Hence if you keep /home, and do a clean install, you will be greeted by your regular desktop, with emails, bookmarks, etc ... all the same as before.

There are exceptions to this (ie in cases where system apps store their configuration files in read only "system" areas), but typically before such an update, whether it be a clean install, or an update, one should ALWAYS backup such files, such that their settings can be easily restored (by a physical check/comparison).

Typically I do a CLEAN install with a reformat of /, but do not reformat my /home, which I keep "as is" and have remounted, (per FeatherMonkey's recommendation). I also keep backup copies of my /etc/X11/xorg.conf, /boot/grub/menu.lst, /etc/modprobe.d/sound, /etc/fstab (for fstab both electronic and paper), plus various other files (such as custom ddclient, custom cron files, etc ...).

On looking into your problem beyond the explanation as Oldcpu has said. I made the presumption you meant you didn't know what additional applications, you've added if this is the case...

Now I did sort of get close now I had a lot more difficulties than you should as I run 64bit. Now firstly my sed skills suck oranges. There's plenty of other people with better sed skills than myself.

rpm -qa | sed 's/-[0-9]/#/g' | cut -d"#" -f1 Now what this does is it will strip the versions numbers, if you pipe this to a file then when you've got a clean install repeat with the new install different file of course.

Use fgrep -v against the old file now here I'd look at piping the output through tr replacing newlines with " " one space. Now you could just collect the output with copy from stdout and use a command line tool like zypper to install the differences.

I repeat my sed skills suck you'll need to check that that actual sed command is bringing back the correct results and not missing anything. Perhaps 2 files one as rpm -qa one with the sed command will indicate if its missing anything. At least number of lines should be the same.

But I repeat this is theoretical never done, its a start in the right direction it may work as is. But with 64bit I have 32bit as part of the package name. Keeping numbers in the names like kdebase3 yast2 was tricky for my limited sed skills now the above does seem to keep them. So it may just work as is and it may just not.

I guess my concern is that I don't remember ALL the changes I've made to my current machine, and when I do the change over to 10.3 (if I was going to do a fresh install) I would lose out on some of the features...[/b]

Your concern about this is noted, ... but the "other side of the coin" is if these "changes" that you refer to include a lot of 3rd party applications, by not doing a clean install (but by only doing an "update") you could very quickly find yourself in dependency "h.e.l.l." with the various 3rd party apps from your older SUSE. Now a large quantity of dependency errors might not stop an experienced SUSE user, but it could give a newbie significant pause for thought and problems. .... ie a non-clean install could fail because of dependencies.

Your concern about this is noted, ... but the "other side of the coin" is if these "changes" that you refer to include a lot of 3rd party applications, by not doing a clean install (but by only doing an "update") you could very quickly find yourself in dependency "h.e.l.l." with the various 3rd party apps from your older SUSE. Now a large quantity of dependency errors might not stop an experienced SUSE user, but it could give a newbie significant pause for thought and problems. .... ie a non-clean install could fail because of dependencies.
[/b]

Good point.
I never thought of keeping a log of packages that I've installed (and setup) in the event of an upgrade.

I know I've installed and setup packages that quietly do their job behind the scenes that I've forgotten about. Just have to spend some time now looking through the output of feathermonkey's command, and record what I want to save and re-install.

That was why I suggested using 2 files from the different systems then using fgrep -vf with the old file against the new one.

I can't check this because the command strips out my -32bit packages. So I'll never have the same number of lines or I will but zypper wouldn't find something-bit package. It needs to be something-32bit this is where my sed skills let me down, I'm sure its possible though.

Once you have the 2 files on a clean install you'd run something like fgrep -vf new old | tr "\n" " " (The old and new maybe the other way around) this will stream the differences found from the files in stdout. Then highlight the lot copy paste after
zypper in
go for a walk and hopefully it will install the difference for you. But as said its theoretical it may even not find the odd file.

Well, I ran the command, and it gave me a huge list... I recognize maybe 1% of the packages and deliberately installed by me. Everything else must have been installed to satisfy dependencies.
I don't think this is how I want to go.

I'm currently writing out a list of what I want the new OS to do, how I'm going to accomplish that, and what info do I need to pull from the old server (mainly special settings I had to spend time to track down in the first place) to implement on the new one.

It's a good exercise (I think) as it gets me to think before doing, which can save me time in the long run.

I never thought of keeping a log of packages that I've installed (and setup) in the event of an upgrade. [/b]

In the case of rpms, you can also find out what you have installed (in chronological order) with:

rpm -qa --last

since that will scroll by the screen rather fast, you can pipe it to a text file (say "rpmlist.txt") with:

rpm -qa --last > rpmlist.txt

... and then open the text file with your favourite editor.