Bugzilla – Bug 116339
suse-release-oss not installed
Last modified: 2005-10-11 07:04:15 UTC
After upgrading from 9.3 to 10.0 RC1 via Yast's system-upgrade (not booted from RC1-cd), suse-release.rpm was not upgraded to suse-release-oss.rpm (because of the other name?). /etc/SuSE-release still contains the Information for 9.3. Related problem: Even after installing suse-release-oss.rpm manually, YOU shows "installed version: 9.3", so updating the installes 10.0 RC1 system is impossible.
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. ***