Bug 116339

That upgrade path should work.  YaST-Team, something for you.

Chris, please test with your team as well.

Please, attach YaST logs.

http://www.opensuse.org/Bug_Reporting_FAQ#YaST

Thanks

(adding YOU maintainer)

Created attachment 49581 [details]
Y2logs from upgrade 9.3 to 10.0 - reproduced

Created attachment 49582 [details]
y2log from 9.3 upgraded to 10.0 and rebooted - `running yast2 online_update`

`cat /etc/SuSE-release`
SUSE LINUX 10.0 (i586)
VERSION = 10.0

but online_update still reffers to 9.3 and also GRUB has label: "SUSE LINUX 9.3"

Packages are installed in their good (10.0's) versions.
for instance: yast2-2.12.26-2 -> 2.12 means SL 10.0

ma, mir: could you, please, have a look at it?

lslezak: Upgrading 9.3 to 10.0
GRUB still has "9.3" label instead of "10.0". Could you, please, confirm?

I think it is not a bootloader issue, but the one of update.

Christoph, did you use the "System Update" icon from the YaST2 control center
(during running 9.3) to update to 10.0? This cannot work since then you use the
old installer and the old YaST2 package manager which cannot know anything about
how to update to 10.0.

Please confirm.

So the question is why is there "System Update" icon? If it's useless for system
update it should be probably removed or there should be a clear desription what
the module does to not confuse the users.

Rudi, suse-release-oss.rpm should probably obsolete suse-release package. See
the initial description.

Excuse me, I'm currently not at home (until thursday), so I can't attach any
logs or something. I just added the 10.0 RC1 CDs as installation source and ran
System Upgrade vom Yast2 control-center (in running 9.3 system). Is this update
path not supported? At first, I wondered, if this would only update packages,
but leave system version at 9.3, but the updater printed something like "update
to 10.0", so I thought everything should be ok. When I'm back at home, I can try
updating by booting von 10.0 RC1 CD. Is the YOU-bug (still searching for 9.3
updates) related to the suse-release-package? If it is, would it help to let the
suse-release-oss-rpm obsoletes the old one?

Thanks for caring about this (my first) bug report and excusing my bad englih :).

AFAIK suse-release-oss.rpm vs. suse-release-package should not be related to the
YOU problem.

Christoph, thanks for the clear report which made it easy to spot the problem.
This update path is not supported, and the icon is misleading. It does only
update the packages, but since it runs the old YaST (from 9.3) it cannot know
all the additional things that need for a real update. 

You always have to use the YaST2 from the new release, and this can only run
within its environment, so there is really no way to update without booting from
the new CDs.

The problem is, since the first update went wrong, I don't see much other choice
for you than a re-install. Else you will have to live with strange glitches now
and then, because the update didn't really happen the way it should.

@Ladislav: he update algorithm has not been run at all. Thus, all the package
that got renamed will be missing, etc., etc. Basically, system upgrade does not
more than "rpm -Uhv"

*** Bug 116545 has been marked as a duplicate of this bug. ***

*** Bug 120605 has been marked as a duplicate of this bug. ***

Hello, 
 
Since I don't have an installation medium (and I'm not going to download a  
4.5GB DVD image over a modem line) what exactly is it that I need to change on  
my local system (running 10.0rc1), that would have been done by the upgrade  
had I booted from the installation DVD?  
  
I thought the whole point of "Installation sources" and "System upgrade" in  
YaST was to somehow duplicate what "apt-get dist-upgrade" does for  
Debian-based distributions. When I boot from an installation DVD, I cannot  
upgrade e.g. suser-* and packman repositories, those all get deleted and I  
have to reinstall them later, which is a bit of a PITA.  
  
Thank you for caring ;)  
  
Jens  
  

I'm sorry to disappoint you, but this problem is technically not possible, at
least given how our products currently are designed. The "system upgrade" icon
unfortunately is very misleading, we will discuss how to improve this.

The problem is that in the update process there are always some specials that
only the new installer (i.e., the one on the 10.0) knows about. But the new
installer needs the new system (libraries, kernel) to run. So, you always need
to boot the installation system. Do you have an idea how Debian solves this problem?

Anyway, you don't need to download 4GB. Just download the single CD (650 MB). It
contains the base system, and all other rpms can be fetched from our ftp site.
please see 
http://www.novell.com/products/suselinux/downloads/suse_linux/instructions_eval.html

> When I boot from an installation DVD, I cannot  
> upgrade e.g. suser-* and packman repositories, those all get deleted and I  
> have to reinstall them later, which is a bit of a PITA.  

Do you mean that the repositories itself are deleted, or the RPMs are uninstalled?

Oh. :(  
  
> The problem is that in the update process there are always some specials  
> that only the new installer (i.e., the one on the 10.0) knows about. But  
> the new installer needs the new system (libraries, kernel) to run. So,  
> you always need to boot the installation system. Do you have an idea how  
> Debian solves this problem?  
  
Yes. Debian maintainers take a lot of care to ensure that no "specials" exist.  
Every package is responsible for its own files and structure and ONLY for  
those files. Packages that replace each other take care to destroy any  
previous configuration, etc.  
There is no "central" management tool that takes care of system global  
settings because there are no "global" settings. Even fstab and /proc belonged  
to a .deb package the last time I checked.  
  
Here's a suggestion how to do this (layman suggestion, but just  
for fun:)  
  
- When doing the system upgrade, upgrade/replace all RPMs as needed 
- Additionally, install a RPM that contains the "system special" stuff and  
provides a "rc" script that runs on next reboot, when new kernel and libraries  
are active, and after running the "system special" stuff auto-"rpm -e"s  
itself.  
- Force the user to reboot after the upgrade (by not letting him close YaST by  
any other means than hitting the "Reboot" button). This is just to avoid  
dozens of bug reports that after an upgrade apps start to crash because of new 
libc6 :-). If the user knows how to use 'kill', he can bypass the forced 
reboot, but that would mean "I know what I'm doing". 
OS X does _exactly_ this after an update.  
  
Debian used to do something similar, there was a /sbin/postinstall.sh which  
was ran on first boot (after installation, not upgrade) and after running  
deleted itself. It's dirty, but maybe it helps. :)  
After dist-upgrades, Debian packages all contain their own post-install  
scripts that each do the "special" needed stuff for each package seperately.  
  
  
> Anyway, you don't need to download 4GB. Just download the single CD (650  
> MB). It contains the base system, and all other rpms can be fetched from  
  
Does the 60MB netboot (boot.iso) suffice as well? I have it here.  
  
> > When I boot from an installation DVD, I cannot  
> > upgrade e.g. suser-* and packman repositories, those all get deleted  
> > and I have to reinstall them later, which is a bit of a PITA.  
>  
> Do you mean that the repositories itself are deleted, or the RPMs are  
> uninstalled?  
  
Any RPMs that cause conflicts (eg. because they depend on the old libc) are  
uninstalled, and in almost all cases newer RPMs would have been available  
online.  
  
Debian allows the user to setup a network (PPP, PPPoE, or LAN) first thing  
after booting the CD, _before_ the actual installation. The user can then  
specify where to get the packages from, and also add package repositories that  
are available online.  
  
I would *very* *very* much like SuSE to do this as well. SuSE's installer is  
so much more flexible regarding partitioning, hardware configuration, etc etc  
that not having this feature almost hurts. ;-)  
  
Thanks!  
  
Jens  

Hello, 
 
which are those "special" actions that the new YaST must perform? 
Can I do these actions manually or perhaps extract them out of a script from 
the installer CD? 
 
I would like to help make "System update" do what it promises to do. Maybe 
those "specials" could be packaged in a way so that the old installer can 
download a set of instructions during upgrade and then perform them. 

Hmm, I don't even know where the source code is. Most important is to update the
products in /var/adm/YaST/ProdDB. Update the 9.3 references with 10.0, and
update the installation URL. After that, at least the online update will
continue to work. But don't blame me when something doesn't work because of
this. You're more supposed to reinstall, but I understand that's probably not a
welcome solution. 

Well, if this is not a box with important databases and web servers on it, and
if you know what you do, you're probably on the safe side. You might run into
problems with rpms that got renamed or split, or with configuration files.

(In reply to comment #25)
> I would like to help make "System update" do what it promises to do. Maybe 

That's the point: 
                  It should not be called "System update" !!!

                  Because it isn't, and will never be, a 'System update'. 

Don't get me wrong, I like the idea outlined in comment #24. But a system update
which is expected to work, must be allowed to boot. 

AFAIK one requirement for what someone called "System update" here, is not to
boot. That way it can't be much more than a freshen. But that's not, what the
button name promisses. 

Don't know why there's so much refusal to change the name of the button.

What would you like to change it to? What the "System update" currently does 
is "half-update", if anything. =;) 
 
And would a reboot after the upgrade of packages, with a "postinstall" kind of 
script that runs upon reboot, not be enough to perform a full upgrade? 
 
What is there that cannot be done out of a running system? I mean, this is not 
Windows, where libraries in use cannot be upgraded or modified. In the worst 
case, one should be required to "init 1" before doing the upgrade, which can 
be automated pretty well. But even this is not required in distributions like 
Gentoo or Debian, where full system-upgrades can even be performed without 
(long) downtime of all services, because all packages are replaced 
sequentially in a rc-stop--upgrade--(upgrade-config--)rc-start cycle, and 
reboots are only required when upgrading the kernel. Plus, the previous kernel 
is _always_ kept by default, so that one does not need to reboot at once 
because the modules of the previous kernel have been removed. 
 
There is no new hardware detection required (because one can assume that the 
hardware needed to run has already been detected by the previous version), 
there should not be any special modules to load (because the system runs 
already) and anything that the installer does after installation could also be 
done by a post-install script after reboot. In principle. 
 
Right? 
 
I'm sure this is no easy task, but I'm also pretty sure it's not impossible. 
 
Jens 

> I'm sure this is no easy task, but I'm also pretty sure it's not impossible. 

We are aware that this could be improved. But it's a matter of priorities. There
are still many other things to do for us. But we do accept patches for this ;-)

*** Bug 121835 has been marked as a duplicate of this bug. ***

*** Bug 121835 has been marked as a duplicate of this bug. ***