suseRegister error

I just completed an upgrade from SuSE 11.0 - Yes - I know it is unsupported. After adding nomodeset to the command line in /boot/grub/menu.lst, 99 percent of my system is working. The one thing that is not working is bind - it is failing to start with the following error:

initializing DST: openssl error

After following the instructions here - http://forums.opensuse.org/forums/english/get-technical-help-here/network-internet/468834-named-running-under-chroot-not-working-mmap-returns-eaccess.html and trying to do an online update to grab the patch to apparmor, it appears that I need to do something further to get the online update working.

However, when I run online update, I get the following error:
suseRegister-1.2-123.1.noarch requires sysconfig, but this requirement cannot be provided
uninstallable providers: sysconfig-0.75.4-2.5.1.i586[repo-update]
sysconfig-0.75.4-2.5.1.x86_64[repo-update]

According to the error, I have the following three choices:

  1. do not install patch:openSUSE-2012-74-1.noarch
  2. break suseRegister by ignoring some of its dependencies
  3. or deinstallation of a number of items that sound to me like I’d basically be unistalling YaST and other important stuff

What is the proper action to take in this case?

Thanks.

I saved the full error file, and I am including the text below.

YaST2 conflicts list - generated 2012-02-21 01:21:58

suseRegister-1.2-123.1.noarch requires sysconfig, but this requirement cannot be provided
uninstallable providers: sysconfig-0.75.4-2.5.1.i586[repo-update]
sysconfig-0.75.4-2.5.1.x86_64[repo-update]
] do not install patch:openSUSE-2012-74-1.noarch

 ] break suseRegister by ignoring some of its dependencies

 ] Following actions will be done:

deinstallation of suseRegister-1.2-123.1.noarch
deinstallation of sysconfig-0.75.4-2.2.2.x86_64
deinstallation of yast2-network-2.21.8-2.1.1.x86_64
deinstallation of yast2-support-2.16.1-6.1.noarch
deinstallation of yast2-2.21.24-2.1.2.x86_64
deinstallation of rpcbind-0.2.0_git201007131952-17.1.2.x86_64
deinstallation of dhcpcd-3.2.3-47.70.1.2.x86_64
deinstallation of avahi-0.6.30-10.1.3.x86_64
deinstallation of syslog-service-1.4.1-750.747.2.noarch
deinstallation of dhcp-client-4.2.2-6.1.2.x86_64
deinstallation of dhcp-server-4.2.2-6.1.2.x86_64
deinstallation of yast2-samba-server-2.21.4-2.1.1.noarch
deinstallation of yast2-kerberos-client-2.21.4-2.1.1.noarch
deinstallation of yast2-vm-2.21.4-1.1.1.x86_64
deinstallation of yast2-users-2.21.9-1.2.x86_64
deinstallation of yast2-update-2.21.1-2.1.1.x86_64
deinstallation of yast2-tune-2.21.3-2.1.2.x86_64
deinstallation of yast2-storage-2.21.14-1.1.1.x86_64
deinstallation of yast2-sound-2.21.3-2.1.2.x86_64
deinstallation of yast2-slp-2.21.0-2.1.2.x86_64
deinstallation of yast2-scanner-2.20.1-6.1.2.x86_64
deinstallation of yast2-printer-2.21.0-2.1.2.x86_64
deinstallation of yast2-packager-2.21.22-1.1.1.x86_64
deinstallation of yast2-nis-client-2.21.4-1.2.x86_64
deinstallation of yast2-mouse-2.21.0-2.1.1.x86_64
deinstallation of yast2-ldap-2.21.1-3.1.2.x86_64
deinstallation of yast2-country-2.21.5-2.1.1.x86_64
deinstallation of yast2-control-center-2.21.7-2.1.2.x86_64
deinstallation of yast2-bootloader-2.21.2-1.2.x86_64
deinstallation of yast2-tv-2.21.4-2.1.2.noarch
deinstallation of yast2-sysconfig-2.21.2-2.1.2.noarch
deinstallation of yast2-sudo-2.21.1-2.1.1.noarch
deinstallation of yast2-security-2.21.6-2.1.1.noarch
deinstallation of yast2-samba-client-2.21.5-2.1.1.noarch
deinstallation of yast2-runlevel-2.21.3-2.1.1.noarch
deinstallation of yast2-restore-2.21.2-2.1.1.noarch
deinstallation of yast2-pam-2.21.0-2.1.1.noarch
deinstallation of yast2-online-update-configuration-2.21.1-2.1.1.noarch
deinstallation of yast2-online-update-2.21.4-2.1.1.noarch
deinstallation of yast2-nfs-client-2.21.1-2.1.1.noarch
deinstallation of yast2-metapackage-handler-0.8.14-2.1.1.noarch
deinstallation of yast2-iscsi-client-2.21.9-1.1.1.noarch
deinstallation of yast2-irda-2.21.1-2.1.1.noarch
deinstallation of yast2-installation-2.21.28-125.1.noarch
deinstallation of yast2-inetd-2.21.1-2.1.1.noarch
deinstallation of yast2-firewall-2.21.1-2.1.1.noarch
deinstallation of yast2-dns-server-2.21.3-2.1.2.noarch
deinstallation of yast2-dhcp-server-2.21.2-2.1.2.noarch
deinstallation of yast2-apparmor-2.21.5-2.1.2.noarch
deinstallation of yast2-add-on-2.21.6-1.1.noarch
deinstallation of autoyast2-installation-2.21.4-2.1.2.noarch
deinstallation of pcsc-lite-1.7.4-4.1.3.x86_64
deinstallation of libopensc2-0.11.4-37.6.x86_64
deinstallation of syslog-ng-3.3.1-7.6.2.x86_64
deinstallation of smartmontools-5.42-1.2.2.x86_64
deinstallation of cups-1.5.0-2.1.3.x86_64
deinstallation of audit-2.1.1-15.1.2.x86_64
deinstallation of ypbind-1.33-3.1.3.x86_64
deinstallation of mkinitrd-2.7.0-39.3.1.x86_64
deinstallation of nss-mdns-0.10-52.1.2.x86_64
deinstallation of libksuseinstall1-4.7.2-5.2.2.x86_64
deinstallation of yast2-online-update-frontend-2.21.4-2.1.1.noarch
deinstallation of yast2-control-center-qt-2.21.7-2.1.2.x86_64
deinstallation of cron-4.2-31.1.3.x86_64
deinstallation of gutenprint-5.2.7-13.1.2.x86_64
deinstallation of cifs-utils-4.9-7.1.3.x86_64
deinstallation of bootsplash-3.3-174.1.2.x86_64
deinstallation of bootsplash-branding-openSUSE-12.1-15.3.9.noarch
deinstallation of nss-mdns-32bit-0.10-52.1.2.x86_64
deinstallation of libkde4-4.7.2-5.2.2.x86_64
deinstallation of kdebase4-runtime-4.7.2-3.4.2.x86_64
deinstallation of kaffeine-1.2.2-12.1.2.x86_64
deinstallation of suspend-1.0-10.1.2.x86_64
deinstallation of splashy-branding-openSUSE-0.3.13-29.1.2.x86_64
deinstallation of samba-client-3.6.1-34.3.1.x86_64
deinstallation of ksplashx-branding-openSUSE-12.1-15.3.9.noarch
deinstallation of plasmoid-folderview-4.7.2-4.2.2.x86_64
deinstallation of libkonq5-4.7.2-4.2.2.x86_64
deinstallation of libkdepim4-4.7.2-3.2.2.x86_64
deinstallation of korganizer-4.7.2-3.2.2.x86_64
deinstallation of kontact-4.7.2-3.2.2.x86_64
deinstallation of konqueror-plugins-4.7.2-4.2.2.x86_64
deinstallation of konqueror-4.7.2-4.2.2.x86_64
deinstallation of knotes-4.7.2-3.2.2.x86_64
deinstallation of kmail-4.7.2-3.2.2.x86_64
deinstallation of kfind-4.7.2-4.2.2.x86_64
deinstallation of keditbookmarks-4.7.2-4.2.2.x86_64
deinstallation of kdialog-4.7.2-4.2.2.x86_64
deinstallation of kdepim4-wizards-4.7.2-3.2.2.x86_64
deinstallation of kdepim4-4.7.2-3.2.2.x86_64
deinstallation of kdebase4-nsplugin-4.7.2-4.2.2.x86_64
deinstallation of kdebase4-libkonq-4.7.2-4.2.2.x86_64
deinstallation of kaddressbook-4.7.2-3.2.2.x86_64
deinstallation of akregator-4.7.2-3.2.2.x86_64
deinstallation of python-kde4-4.7.2-2.1.2.x86_64
deinstallation of polkit-kde-kcmmodules-1-0.98.1+git20110929-1.2.x86_64
deinstallation of plasmoid-quickaccess-0.8.1-16.1.2.x86_64
deinstallation of plasma-addons-marble-4.7.2-2.3.2.x86_64
deinstallation of plasma-addons-lancelot-4.7.2-2.3.2.x86_64
deinstallation of plasma-addons-akonadi-4.7.2-2.3.2.x86_64
deinstallation of plasma-addons-4.7.2-2.3.2.x86_64
deinstallation of marble-4.7.2-2.1.2.x86_64
deinstallation of libktorrent3-1.1.2-4.1.2.x86_64
deinstallation of libktexteditor-4.7.2-2.1.2.x86_64
deinstallation of libksane0-4.7.2-2.1.2.x86_64
deinstallation of libkipi8-4.7.2-2.1.2.x86_64
deinstallation of libkgeomap1-2.2.0-4.1.2.x86_64
deinstallation of libkexiv2-10-4.7.2-2.1.2.x86_64
deinstallation of libkeduvocdocument4-4.7.2-2.1.2.x86_64
deinstallation of libkdepimlibs4-4.7.2-2.2.2.x86_64
deinstallation of libkdegames4-4.7.2-3.1.2.x86_64
deinstallation of libkdcraw20-4.7.2-2.1.2.x86_64
deinstallation of libkcompactdisc4-4.7.2-2.1.2.x86_64
deinstallation of libkcddb4-4.7.2-2.1.2.x86_64
deinstallation of libakonadi4-4.7.2-2.2.2.x86_64
deinstallation of kwrite-4.7.2-2.1.2.x86_64
deinstallation of kwin-4.7.2-6.4.1.x86_64
deinstallation of kwalletmanager-4.7.2-2.1.2.x86_64
deinstallation of ktorrent-4.1.2-2.1.2.x86_64
deinstallation of ksudoku-4.7.2-3.1.2.x86_64
deinstallation of ksshaskpass-0.5.3-7.1.2.x86_64
deinstallation of ksnapshot-4.7.2-2.1.2.x86_64
deinstallation of kscd-4.7.2-2.1.2.x86_64
deinstallation of krfb-4.7.2-2.1.2.x86_64
deinstallation of kreversi-4.7.2-3.1.2.x86_64
deinstallation of krdc-4.7.2-2.1.2.x86_64
deinstallation of kpat-4.7.2-3.1.2.x86_64
deinstallation of kopete-4.7.2-2.1.2.x86_64
deinstallation of kmix-4.7.2-2.1.2.x86_64
deinstallation of kmines-4.7.2-3.1.2.x86_64
deinstallation of kmahjongg-4.7.2-3.1.2.x86_64
deinstallation of kipi-plugins-geolocation-2.2.0-2.1.2.x86_64
deinstallation of kipi-plugins-acquireimage-2.2.0-2.1.2.x86_64
deinstallation of kipi-plugins-2.2.0-2.1.2.x86_64
deinstallation of kio_sysinfo-12.1-55.52.1.x86_64
deinstallation of kio_kamera-4.7.2-2.1.2.x86_64
deinstallation of kio_audiocd-4.7.2-2.1.2.x86_64
deinstallation of kgpg-4.7.2-2.1.2.x86_64
deinstallation of kget-4.7.2-2.1.2.x86_64
deinstallation of kgamma-4.7.2-2.1.2.x86_64
deinstallation of kdnssd-4.7.2-2.1.2.x86_64
deinstallation of kdm-4.7.2-6.4.1.x86_64
deinstallation of kdepimlibs4-4.7.2-2.2.2.x86_64
deinstallation of kdepim4-runtime-4.7.2-3.2.2.x86_64
deinstallation of kdenetwork4-filesharing-4.7.2-2.1.2.x86_64
deinstallation of kdelibs4-core-4.7.2-5.2.2.x86_64
deinstallation of kdelibs4-4.7.2-5.2.2.x86_64
deinstallation of kdebase4-workspace-liboxygenstyle-4.7.2-6.4.1.x86_64
deinstallation of kdebase4-workspace-branding-openSUSE-12.1-55.52.1.x86_64
deinstallation of kdebase4-workspace-4.7.2-6.4.1.x86_64
deinstallation of kdebase4-openSUSE-12.1-55.52.1.x86_64
deinstallation of kdeartwork4-screensaver-4.7.2-2.1.2.x86_64
deinstallation of kde4-kgreeter-plugins-4.7.2-6.4.1.x86_64
deinstallation of kcolorchooser-4.7.2-2.1.2.x86_64
deinstallation of kcalc-4.7.2-2.1.2.x86_64
deinstallation of k3b-2.0.2-18.1.2.x86_64
deinstallation of gwenview-4.7.2-2.1.2.x86_64
deinstallation of compiz-kde4-0.9.5.92.1-2.1.2.x86_64
deinstallation of ark-4.7.2-2.1.2.x86_64
deinstallation of kdebase4-runtime-branding-openSUSE-12.1-55.52.1.x86_64
deinstallation of wpa_supplicant-0.7.3-10.1.2.x86_64
deinstallation of mcelog-1.0pre3.6e4e2a000124-8.1.2.x86_64
deinstallation of ntp-4.2.6p3-16.14.2.x86_64
deinstallation of xinetd-2.3.14-155.1.2.x86_64
deinstallation of samba-3.6.1-34.3.1.x86_64
deinstallation of konversation-lang-1.3.1-11.1.2.noarch
deinstallation of digikam-lang-2.2.0-3.1.2.noarch
deinstallation of python-kdebase4-4.7.2-6.4.1.x86_64
deinstallation of marble-data-4.7.2-2.1.2.noarch
deinstallation of libkdeedu4-data-4.7.2-2.1.2.noarch
deinstallation of kdegames4-carddecks-default-4.7.2-3.1.2.noarch
deinstallation of kipi-plugins-lang-2.2.0-2.1.2.noarch
deinstallation of kio_sysinfo-branding-openSUSE-12.1-55.52.1.x86_64
deinstallation of kdelibs4-branding-openSUSE-12.1-15.3.9.noarch
deinstallation of kdebase4-session-4.7.2-13.1.1.noarch
deinstallation of tightvnc-1.3.10-5.1.3.x86_64
deinstallation of xkeyboard-config-2.2.1-4.1.3.noarch
deinstallation of xorg-x11-Xvnc-7.6_1.10.4-36.2.1.x86_64
deinstallation of xorg-x11-server-7.6_1.10.4-36.2.1.x86_64
deinstallation of kdegames4-carddecks-other-4.7.2-3.1.2.noarch
deinstallation of xorg-x11-driver-input-7.6-41.38.2.x86_64
deinstallation of xorg-x11-driver-video-unichrome-20110523-3.1.2.x86_64
deinstallation of xorg-x11-driver-video-radeonhd-1.3.0_20100512_80ba041-5.1.2.x86_64
deinstallation of xorg-x11-driver-video-nouveau-0.0.16_20110720_b806e3f-2.1.2.x86_64
deinstallation of xorg-x11-driver-video-intel-legacy-2.9.1-13.1.2.x86_64
deinstallation of xorg-x11-driver-video-7.6-80.1.2.x86_64

YaST2 conflicts list END

On my 12.1 system suseRegister is not installed

If you updated from 11 > 12.1 in one step, consider yourself a living example of a miracle !

On 02/21/2012 07:46 AM, wiyosaya wrote:
> What is the proper action to take in this case?

not sure what you got going on there…i have to wonder what path you
took to get from “SuSE 11.0” (of which there is no such: there is an
openSUSE 11.0 long past end of life and a still supported SUSE Linux
Enterprise Server/Desktop (SLES/SLED) 11–and i wonder which you had and
more importantly what you ‘upgraded’ to…so, why not share with us by
returning the output of

cat /etc/SuSE-release

but, like caf i also do not have a suseRegister on my 11.4, so it has
been gone a while now…and neither YaST Online Update nor YaST Software
Management should find it and try to update it…

i’m pretty sure you have a giant balled up mess…and, to recover will
need do a fresh install…


DD
What does DistroWatch write about YOU?: http://tinyurl.com/SUSEonDW

On 2012-02-21 07:46, wiyosaya wrote:
>
> I just completed an upgrade from SuSE 11.0 - Yes - I know it is
> unsupported.

Using what procedure?
And to what target version?

> After adding nomodeset to the command line in
> /boot/grub/menu.lst, 99 percent of my system is working. The one thing
> that is not working is bind - it is failing to start with the following
> error:

Did you review yet the rpmorig and rpmnew files?

> initializing DST: openssl error
>
> After following the instructions here - http://tinyurl.com/6uuw7xj and
> trying to do an online update to grab the patch to apparmor, it appears
> that I need to do something further to get the online update working.
>
> However, when I run online update, I get the following error:
> suseRegister-1.2-123.1.noarch requires sysconfig, but this requirement
> cannot be provided
> uninstallable providers: sysconfig-0.75.4-2.5.1.i586[repo-update]
> sysconfig-0.75.4-2.5.1.x86_64[repo-update]

suseRegister? The package exists, But I don’t have it installed. And it is
version 1.4-10.1 for version 11.4, so I have to doubt what kind of (broken)
upgrade you did.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

Thanks for your reply. Cool avatar! :wink:

I guess I must be a miracle then, or maybe the project programmers just don’t know how good they are ;). Yes, I upgraded in one step from 11 -> 12.1.

It sounds like a possible approach is to go to the package manager and uninstall suseRegister, based on the fact that all who responded are not running it, and then try the online update.

Comparing the list of packages that would be uninstalled with what is in the 12.1 distribution, they are all on the list of 12.1 packages. So, thinking out loud here, they are all needed. Perhaps then, just getting rid of suseRegister will take care of the inability to install the latest updates? What do you think? It’s hard to say, I’m sure.

(Perhaps there are more packages like this that are incompatible with previous versions - and will give more problems, however, I’ll tend to those if they popup.)

So, why did I go from 11 to 12.1 even though it is not supported?

  1. Samba server reinstall
  2. Name server reinstall
  3. Network reinstall
  4. Custom IP Tables firewall script.

Not immediately seeing another path, those items would take a long time to reinstall - unless it would simply be a matter of copying the old config files to the new installation; however, in the past when evaluating this approach, it has generally been discouraged as some parameters in the config files may be problematic for the newer packages.

The other reason is that after initially having problems going from 11 -> 12.1 (of course, not having read the release notes on the site about the nomodeset switch ;)), I attempted incremental updates from 11 to 11.2, which froze when trying to analyze the existing system, and since that did not work, I tried to upgrade 11 to 11.4, and that also froze when trying to analyze the system. The 11 ->12.1 upgrade was the only upgrade that “mostly” worked, interestingly enough.

As a last resort, I’ll do the fresh install. I think, though, that may take much more time to do than the upgrade, and time is a limited resource for me these days.

On 02/21/2012 03:46 PM, wiyosaya wrote:
> (Perhaps there are more packages like this that are incompatible with
> previous versions - and will give more problems, however, I’ll tend to
> those if they popup.)

that is one of the ‘dangers’ of an upgrade…my understanding of the
way the upgrade script works is it looks at what is installed (in the
old system) and if there is a newer package in the version you ask for,
the newer overwrites the older…makes sense…

but, what if there is a file/application/config that has no counterpart
in the system being moved to? i know for sure that some of those get
left in the new system…theoretically they probably won’t do anything
but take up space…but we KNOW (apparently we know) that if
suseRegister is left then it mucks up the works…

the question then becomes: what is is laying around in the corners…and
when might the become a problem…no one knows…


DD http://tinyurl.com/DD-Caveat
What does DistroWatch write about YOU?: http://tinyurl.com/SUSEonDW

Thanks for the reply. Guessing from the pre-upgrade package list, what it looks like the upgrade process does is as follows:

  1. Looks at what is installed
  2. Determines whether the package has an upgrade path, and if so, upgrades
  3. If the package has no upgrade path yet has a newer version, uninstalls the existing package and installes the new one

That’s my guess anyway.

Perhaps - not that I know what actually happens as the upgrade script may already do something like this - a better path would be this:

  1. If the package is installed in the version to be upgraded and it exists in the new version, do the above steps
  2. If the package is not in the new version, flag it for uninstallation, and let the user review the differences - noting that leaving them may or may not cause problems
  3. If the user does nothing, uninstall the package, otherwise, keep it.

While some users might not like this, it may resolve problems like this for people like me who venture into forbidden areas. lol!

What I will do is keep a list of any other “problematic” packages like this that pop up, and post them to this thread as a bread-crumb trail for other people like me who, foolheartedly, venture into forbidden territory. lol!

While I was up a bit too late last night to think of looking at the package list for 12.1 (which would have told me that the YaST components it wanted to remove were important), uninstalling the offending package sounds like the way to go, and hopefully, I’ll be able to determine whether any other packages are absolutely necessary.

Upgrading from 10.something - my last release, to 11.0 went almost seamlessly, so I decided to give the 11 -> 12.1 upgrade a try (and thus I was rather surprised - though not having read the respective release notes - that 11 -> 11.2 or 11 -> 11.4 did not work smoothly). It seemed as if the worst that could happen in the 11 -> 12.1 process was that it would take as long to fix anything as it would to re-configure the custom stuff I did. Besides, I have a great disk imaging tool - Image For Linux - that gives me an easy path back to 11.0 if all else fails. The particular machine that this is on is an important machine in my home network - gateway, router, nameserver, etc., and until just this past weekend, I did not have anything I could substitute for it if it needed to be down for an extended (days) period.

Thanks again.

On 02/21/2012 09:06 PM, wiyosaya wrote:
> If the user does nothing, uninstall the package, otherwise, keep
> it.

hmmmm…what if it uninstalled your db of priceless info?


DD
What does DistroWatch write about YOU?: http://tinyurl.com/SUSEonDW

On 2012-02-21 15:46, wiyosaya wrote:
>
> caf4926;2442135 Wrote:
>> On my 12.1 system suseRegister is not installed
>>
>> If you updated from 11 > 12.1 in one step, consider yourself a living
>> example of a miracle !
> Thanks for your reply. Cool avatar! :wink:

You still have not answered my questions.

Using what procedure?

Did you review yet the rpmorig and rpmnew files?

I can help you further, but not unless you answer.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

You have a point, and leaving things installed does circumvent a crowd of angry SuSE users. :slight_smile:

I upgraded by downloading the .iso file and burning a DVD. In thinking about this more, I may have preferred that the upgrade process present me with the package summary without my having to explicitly press a button to see it. There could always be a “proceed with upgrade” button on such a summary for people who would rather not review the package manifest. Even so, that might not have helped. See below…

I appreciate your willingness to help. You have already provided all the help I needed as I solved the problem. lol!

I uninstalled suseRegister through the software manager, and on uninstalling suseRegister, the real problem behind the list of files above was revealed with the following message:

“nothing provides tunctl which is required by sysconfig”

I cancelled out of that as it still wanted to uninstall the packages listed above, and I checked the 12.1 package list. Sure enough, tunctl was there. I then refreshed the online and CD repositories, and searched for the tunctl package, and the software manager did not find it.

So I searched and found the latest SuSE tunctl rpm on this page. I then downloaded it with Firefox, and the download box gave me an option to open it with the software manager - which I did. Very nice touch there. I installed it, and the errors went away. I was then able to do the online update, and now Bind starts without error and my home network is back to normal. It seems like my calculated risk payed off as my 11.0 -> 12.1 upgrade is now up and running with not all that much effort on my part. I do, however, consider myself a “capable” user. I consider myself a relative Linux novice, but I have quite a few years of Windows c/c++/c# experience that likely give me an edge over less knowledgeable users, and that Linux knowledge was enough to solve this problem given everyone’s input from this thread.

One comment about that message: “nothing” was confusing to me. If it said something like “no installed module provides tunctl” that would be extremely clear to me.

One final question. When I searched for suseRegister in the Software Manager, the installed version appeared in red. What does that red color indicate? There were a couple other inconsequential packages with a red installed version, too. I figure that it means that the package is installed, but it is no longer part of the default configuration or distribution? The reason I am asking is that if that is the case, then I may manually “clean up” the leftover 11.0 packages.

Thanks again to everyone who responded.

The red packages mean either:

  1. They are installed but no longer exist in any of the enabled repositories.

  2. They are installed but the available package is older than the one installed

If you view by the versions tab in software manager, it should become clear to you. A package that fits option 1 will show only the installed package with no other choices.

For option 2 you should see a combination of radio buttons and package version that can be toggled as required.

Makes perfect sense. Thank you!

To someone who obviously has some in good measure, so it should.
:smiley:

On 02/22/2012 04:06 AM, wiyosaya wrote:
> I consider myself
> a relative Linux novice, but I have quite a few years of Windows
> c/c++/c# experience that likely give me an edge over less knowledgeable
> users, and that Linux knowledge was enough to solve this problem given
> everyone’s input from this thread.

believe it or not, sometimes a broad and long Windows background is an
overall minus–unless willing to listen and pay attention to the
differences…

for example, about once a month we get a new guy in who will NOT rest
until he has ‘fixed’ his memory leak (when all is well)…


DD
What does DistroWatch write about YOU?: http://tinyurl.com/SUSEonDW

On 2012-02-22 04:06, wiyosaya wrote:

> I upgraded by downloading the .iso file and burning a DVD.

So, you have done an “offline upgrade”. That was one of my questions. There
is another one. :slight_smile:

> In thinking
> about this more, I may have preferred that the upgrade process present
> me with the package summary without my having to explicitly press a
> button to see it. There could always be a “proceed with upgrade” button
> on such a summary for people who would rather not review the package
> manifest. Even so, that might not have helped. See below…

It is better to review the manifest.

> robin_listas;2442359 Wrote:

>> Did you review yet the rpmorig and rpmnew files?

My guess is “no”.

>> I can help you further, but not unless you answer.
> I appreciate your willingness to help. You have already provided all
> the help I needed as I solved the problem. lol!

Then go ahead and read the documentation for that type of upgrade. I wrote
it, in fact. O:-)

<http://en.opensuse.org/SDB:Offline_upgrade>

You need to pay attention to the steps to do after the upgrade: those red
packages are a reason.

> One final question. When I searched for suseRegister in the Software
> Manager, the installed version appeared in red. What does that red color
> indicate?

Go to the version tab. You will also see a version in parenthesis (above).
If there is one, you have to update that package. If there is none, you
have to add a repo that contains it or consider removal.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

So, you have done an “offline upgrade”. That was one of my questions. There
is another one. :slight_smile:

> In thinking
> about this more, I may have preferred that the upgrade process present
> me with the package summary without my having to explicitly press a
> button to see it. There could always be a “proceed with upgrade” button
> on such a summary for people who would rather not review the package
> manifest. Even so, that might not have helped. See below…

It is better to review the manifest.

That is what I am implying. IMHO, might it be better to place the information cited directly in the eyes of the user performing the upgrade, rather than leave it up to the user to have to take an action to see that information? That way, it is clearly presented to the user as important information. Then if the user dismisses it, it is their responsibility if things did not work.

IMHO, not presenting the information is a sign to the upgrade user that “all is well” and there are no other things to consider. What I suggest is a slightly different way of thinking. Linux attracts a wide range of users, and some of those users are not that technically astute. Presenting something like this to the user sends, IMHO, a message to that user that the information is important; without that information being brought to the attention of the user, the user may get a sense that “all is well” and not bother to look. Case in point - me.

> robin_listas;2442359 Wrote:

>> Did you review yet the rpmorig and rpmnew files?

My guess is “no”.

Good guess! Being someone who does not have a wide-ranging knowledge of Linux, I did not know those files exist, and much less, where to find them. It would be wonderful if you would enlighten me on where to find them - then again, am I beyond the point where reviewing the information would make a difference?

I was also taken aback by the initial comments of a potentially botched system and having to do a reinstall. IMHO, in the Windows world too often reinstallation is presented as the only choice, and part of the time, it does not solve any problems. IMHO, a reinstall should only be suggested as a last resort. What looked like a mess in my case seems like a situation where a few tweaks resolved most of the issues.

Please do not take these comments as my beating up on you. My intent is to help the process. Often I have found that people in the open-source community do not take the time to respond to questions, or are indignant about doing so. Your offer of your valuable time is much appreciated, and I intend to follow the subsequent steps outlined in your “Offline Upgrade” procedure.

I see Linux as being so very close to the “commercial quality” of Windows - though I know that some would say that Windows has no commercial quality at all. The finer details can, as I see it, make all the difference in the world. I think Linux can become something that is generally as easy to install and use as Windows, but at this point, I think it still takes some technical skills to use and maintain it - and I see that as a hindrance to wider acceptance of Linux.

>> I can help you further, but not unless you answer.
> I appreciate your willingness to help. You have already provided all
> the help I needed as I solved the problem. lol!

Then go ahead and read the documentation for that type of upgrade. I wrote
it, in fact. O:-)

<http://en.opensuse.org/SDB:Offline_upgrade>

You need to pay attention to the steps to do after the upgrade: those red
packages are a reason.

Thank you. I intend to follow those steps. The link had a smilie in it, and was therefore unusable, however, I managed to find it using the search. SDB:Offline upgrade - openSUSE - I’m disabling smilies in this post so smilies will not interfere with the link.

> One final question. When I searched for suseRegister in the Software
> Manager, the installed version appeared in red. What does that red color
> indicate?

Go to the version tab. You will also see a version in parenthesis (above).
If there is one, you have to update that package. If there is none, you
have to add a repo that contains it or consider removal.

How do I find the appropriate repos?

Thanks again for your help.

To me, Linux is a completely different animal than windows. In some respects, it has become more Windows like from the user perspective, but what lies underneath is the heart of any OS.

Most of the time, I’m willing to listen - even if it is something that I don’t want to hear. :wink:

Thanks again for your help.

On 2012-02-22 17:26, wiyosaya wrote:

> That is what I am implying. IMHO, might it be better to place the
> information cited directly in the eyes of the user performing the
> upgrade, rather than leave it up to the user to have to take an action
> to see that information? That way, it is clearly presented to the user
> as important information. Then if the user dismisses it, it is their
> responsibility if things did not work.

The thing is, an upgrade in Linux needs some expertise. You have to know
things.

>> robin_listas;2442359 Wrote:
>
>>> Did you review yet the rpmorig and rpmnew files?
>>
>> My guess is “no”.
>
> Good guess! Being someone who does not have a wide-ranging knowledge of
> Linux, I did not know those files exist, and much less, where to find
> them. It would be wonderful if you would enlighten me on where to find
> them - then again, am I beyond the point where reviewing the information
> would make a difference?

The link I gave explains it :slight_smile:

> I see that as a hindrance to wider acceptance of Linux.

Mind you, I do not say that Windows is the worst thing in creation, or
things of that sort :wink: - in fact, I say Windows is good, it works for
many. Its simply that I prefer Linux as better for my needs. Stable, safe,
cheaper, many things.

But we don’t put the kind of money Microsoft puts into testing things, or
designing for ease of use. We don’t have it. Things are simply a best
effort under the circumstances.

>> <http://en.opensuse.org/SDB:Offline_upgrade>
>>
>> You need to pay attention to the steps to do after the upgrade: those
>> red packages are a reason.
>
> Thank you. I intend to follow those steps. The link had a smilie in it,
> and was therefore unusable, however, I managed to find it using the
> search. ‘SDB:Offline upgrade - openSUSE’
> (http://en.opensuse.org/SDB:Offline_upgrade) - I’m disabling smilies in
> this post so smilies will not interfere with the link.

I did not put that smiley, believe me. Even now I don’t see it this side of
“the wall”. Something you may not know: this forum has an nntp gateway that
allow people like me to participate using thunderbird or other text news
clients - instead of a web browser.

I have to remind myself that sometimes things I write can get garbled at
the other side.

>> Go to the version tab. You will also see a version in parenthesis
>> (above). > If there is one, you have to update that package. If there is none,
>> you have to add a repo that contains it or consider removal.
>
> How do I find the appropriate repos?

That’s a good question.

You go to the openSUSE page, click on the “get it” big link, and on the top
you see a search box; enter there whatever package you need and you will
get a list of repos. Which are appropriate and which not, is a matter of
experience and personal preferences.

If you search for “suseRegister” there is one, but I don’t think it is a
needed package. I think you mentioned another one, but I haven’t seen where
you posted it, now.


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

The last steps described in SDB:Offline upgrade - openSUSE though tedious, went smoothly.

What I did was the following:

  1. Set a repository location to the distribution repository. Is there any reason I should not use this location as a repository?
  2. Ran zypper up
  3. An online update through SuSE Online Update
  4. Resolved the conf file problems - which were trivial. This was the tedious part as there were about 8 of them and none had significant changes.

Other repositories, like the update repository, were already set by the installation.

I still have two packages that appear in red, one is a cups printer driver - I know the source for that, and the other, IIRC, is something that does not sound important.

BTW - that the “tunctl” rpm is not in the DVD distribution is, I think, a bug or at least a symptom of another bug. tunctl is, however, in the distribution repository. tunctl is required for sysconfig, and if someone did either of a DVD install or a traditional upgrade and got an error similar to what I got and then chose to uninstall everything, they would have created themselves a big problem. In either of the two scenarios, DVD Install or “traditional upgrade,” my guess is that the problem may not show up until some unsuspecting user tries to run the software manager which is what happened in my case.

I am not sure what version of openSuSE added tunctl, so maybe this “bug” would only apply to ancient versions like mine at 11.0 when upgrading. If this is the only reason that an 11.0 -> 12.1 update is not supported, I think that is unfortunate; however, I suspect that it is more related to the fact that 11.0 is no longer supported.

Since tunctl is in the distribution repository, someone performing an “Online Install” or “Online Upgrade” from 11.0 -> 12.1 would likely not run into the same problem.

The last thing I had to do was update my Iptables script as it was dropping spoofed IPV4 private network addresses in the “nat” table - (a rule widely accepted in previous versions of Iptables). The correct table to do this in, with new versions of Iptables, is now the “mangle” table.

If there are others out there who have hesitated to update 11.0, from my experience, it is possible.

Thanks again to all who replied.

On 2012-02-24 17:56, wiyosaya wrote:
>
> The last steps described in ‘SDB:Offline upgrade - openSUSE’
> (http://en.opensuse.org/SDB:Offline_upgrade) though tedious, went
> smoothly.

Good :slight_smile:

> What I did was the following:
>
>
> - Set a repository location to ‘the distribution repository’
> (http://download.opensuse.org/distribution/12.1/repo/oss/suse/). Is
> there any reason I should not use this location as a repository?

I do not know. Let me see, I have…


> 5 | repo-non-oss               | openSUSE-12.1-Non-Oss              | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/12.1/repo/non-oss/                                    |
> 6 | repo-oss                   | openSUSE-12.1-Oss                  | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/12.1/repo/oss/                                        |

It is almost the same. I think they point in fact to the same thing.

> - Ran zypper up
> - An online update through SuSE Online Update

Yep, that’s one of the methods, at least when there are few repos. If not,
things get complicated.

> - Resolved the conf file problems - which were trivial. This was the
> tedious part as there were about 8 of them and none had significant
> changes.

Yes, it depends on each installation. In my case, I get dozens of them. If
you change local configuration files chances are you get that problem when
upgrading. If you don’t do configuration changes, just use the new file.

> BTW - that the “tunctl” rpm is not in the DVD distribution is, I think,
> a bug or at least a symptom of another bug. tunctl is, however, in the
> distribution repository. tunctl is required for sysconfig, and if
> someone did either of a DVD install or a traditional upgrade and got
> an error similar to what I got and then chose to uninstall everything,
> they would have created themselves a big problem. In either of the two
> scenarios, DVD Install or “traditional upgrade,” my guess is that the
> problem may not show up until some unsuspecting user tries to run the
> software manager which is what happened in my case.

That package is online, if it is not in the DVD then indeed it is not
upgraded and has to be taken care later, as I mention in that wiki page. I
have reported as bug that sort of thing, in general, but I doubt anything
is done.

The solution is to activate the online repos during the offline upgrade
procedure (yes, I see the contradiction). The problem is that in that case
the online repos take precedence and everything is downloaded, even if it
is in the DVD, wasting time and bandwidth.

You can report as bug in bugzilla that the tunctl package should be in the
dvd. But of course, the DVD will not be remastered, but perhaps a note can
be added to the release notes.

> I am not sure what version of openSuSE added tunctl, so maybe this
> “bug” would only apply to ancient versions like mine at 11.0 when
> upgrading. If this is the only reason that an 11.0 -> 12.1 update is not
> supported, I think that is unfortunate; however, I suspect that it is
> more related to the fact that 11.0 is no longer supported.

No, that upgrade is not supported simply because it is a big jump, more
than two versions. A jump of 11.0 to 11.2 would be “supported” (IMO), I
mean, should work, but you can not report bugs on it. It /was/ supported,
it is not /now/.

I don’t know if I explained myself sufficiently :-?

> Since tunctl is in the distribution repository, someone performing an
> “Online Install” or “Online Upgrade” from 11.0 -> 12.1 would likely not
> run into the same problem.

True, but they would get into other problems. A zypper dup over more than
one version is more problematic than an offline upgrade of the same jumps.

> The last thing I had to do was update my Iptables script as it was
> dropping spoofed IPV4 private network addresses in the “nat” table - (a
> rule widely accepted in previous versions of Iptables). The correct
> table to do this in, with new versions of Iptables, is now the “mangle”
> table.

Ah, yes, that sort of things happen in updates of any kind, your changes
can be obsoleted.

> If there are others out there who have hesitated to update 11.0, from
> my experience, it is possible.

:slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)