Upgrading from 12.1 to 12.3

I haven’t posted to these forums in years. Because OpenSuse 12.1 was close to perfection for me. Everything just worked.

Sadly, it’s no longer supported.

So last week I decided to move to 12.3, and did a system upgrade by changing my repositories to point to the new ones, booting into runlevel 3, and running zypper dup. And you know what? That actually worked pretty well. 30 minutes later I was running the new OS and everything was more or less up to date. But there are three issues that are bothering me. From least annoying to greatest they are

  • The screensaver asks for a password to unlock the screen, but no password is actually required. Googling shows that others have this problem. It’s not really worth fixing for me, because I never lock my screen.

  • Hibernating does not work. It does not shut down the computer, locks up the screen, and there seems to be no way to recover from it except killing my x-session. I never used hibernate anyway.

  • Booting directly into runlevel 3 no longer works. I used to type a 3 at the end of the grub options line and get a command prompt. Now adding the 3 does nothing for me, and I need to log out and tell KDM I want console mode.

  • AisleRiot no longer keeps statistics. Are my Spider wins going to be stuck at 330 out of 470 games forever?? NO! THIS CANNOT BE!

  • Suspend does not work. It shuts down quickly, but when starting up again the monitor turns on and the computer seems to hang in the middle of drawing a splash screen. My USB keyboard turns on its numlock light, but is unresponsive. My USB optical mouse never turns on.

Of these, not being able to suspend is the only one that’s killing me right now. Since power management problems like this are generally buggy kernels or graphics driver issues (in my experience anyway) I’ve tried multiple kernels from the standard kernel repository with multiple versions of the proprietary nvidia 319 series drivers with no success.

Any thoughts on how to solve or go about troubleshooting this?

On 2013-09-15 20:56, incognito9 wrote:
>
> I haven’t posted to these forums in years. Because OpenSuse 12.1 was
> close to perfection for me. Everything just worked.
>
> Sadly, it’s no longer supported.
>
> So last week I decided to move to 12.3, and did a system upgrade by
> changing my repositories to point to the new ones, booting into runlevel
> 3, and running zypper dup. And you know what? That actually worked
> pretty well. 30 minutes later I was running the new OS and everything
> was more or less up to date. But there are three issues that are
> bothering me. From least annoying to greatest they are

An upgrade via “zypper dup” jumping over a release or more is not really
supported. It may work, it may not.

Online upgrade
method

Offline upgrade
method

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

> - The screensaver asks for a password to unlock the screen,

You do not say which desktop.


Cheers / Saludos,

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

I’ve browsed all of those links previously. Everything (except for the few issues above) seemed to work just fine. Surprisingly well. Are you suggesting that re-installing from a DVD image will solve these issues?

> - The screensaver asks for a password to unlock the screen,

My apologies. I’m a KDE quy.

Thanks for the quick response.

A fresh install will probably fix most of the problems. But you also face a huge jump in KDE so you may want to save off or rename your ~/.kde4 directory and re-setup KDE from scratch. In fact I’d try resetting KDE first before you try a new install.That may fix several of your problems.

Note when you do an upgrade generally configuration files are not over written so you end up with some config files that are old and my be out of date as things change. The larger the version jump the more likely the configs won’t match what the program expects.

On 2013-09-15 21:46, incognito9 wrote:
>
> robin_listas;2585179 Wrote:
>>
>>
>> An upgrade via “zypper dup” jumping over a release or more is not really
>> supported. It may work, it may not.
>
> I’ve browsed all of those links previously. Everything (except for the
> few issues above) -seemed- to work just fine. Surprisingly well. Are you
> suggesting that re-installing from a DVD image will solve these issues?

No… I hate upgrades having “strange” issues. Me, I always upgrade my
system, but I use the DVD method, not “zypper dup”.

Question. Did you have any other repository active save the oss and
non-oss repos? Having more repos active during the upgrade causes
problems. If that was the case, the cure might be to disable those repos
and do the zypper dup again.

Personally, I believe that the update repos should also be temporarily
disabled during the upgrade; after the reboot, ractivate the update
repos for the next version, and run “zypper patch”)

Also, verify that the URL of all active repos point to 12.3. You can run:


zypper lr --details

and verify the result.

At worst, one method to solve some issues is to attempt an upgrade from
12.3 to 12.3 using the DVD method instead.

One possibility is that you have “wrong” config files lying around. Run,
as root in a terminal, “rcrpmconfigcheck”. It gives a list of config
files that you should verify after an upgrade.

> My apologies. I’m a KDE quy.
>
> Thanks for the quick response.

Welcome - an idea: create a new user, and try the screensaver there. If
it works, then part of the issues are due to the local config of your
normal user.


Cheers / Saludos,

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

On 2013-09-15 22:16, gogalthorp wrote:

> Note when you do an upgrade generally configuration files are not over
> written so you end up with some config files that are old and my be out
> of date as things change. The larger the version jump the more likely
> the configs won’t match what the program expects.

True; but the command “rcrpmconfigcheck” lists the system config files
that are altered or that should be altered.

And to check the user config files, you simply have to create a new user
and try.


Cheers / Saludos,

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

I do it quite often on 12.3 and it most certainly works. I wonder if this can be sysvinit-vs-systemd issue. Did you end up using sysvinit or systemd after jump from 12.1?

That screensaver issue is a known bug in KDE since 4.10.0.
It’s mainly cosmetical though (although it could lead the user to the false impression that the screen is locked when in fact it is not, of course):
The screenlocker shows the “enter password” screen although it is configured to not require a password (which is the default).
Have a look in “Configure Desktop”->“Screen and Monitor”->“Screenlocker”. If you enable “Require Password” you will have to enter the password.
You can of course turn off the screenlocker/screensaver there completely, if you want to (“Start automatically after…”).

Booting to runlevel 3 works fine here as well. Maybe you added the “3” at the wrong place? Which bootloader are you using? (grub legacy I suppose)

For your suspend/hibernate problems, try to run “pm-suspend” or “pm-hibernate” from the command line and have a look in /var/log/pm-suspend.log if there’s any clue.
If you have “acpid” installed, try to uninstall it. It may clash with systemd, which takes over most of the powermanagement functions now.

Regarding Aisleriot: this seems to be a permissions issue. In earlier versions the gnome games ran as group “games” and saved their highscores in /var/games. But they now run as mere user and have no permissions to write to /var/games anymore. There was even a bugreport about this IIRC.
You can copy the highscore file from /var/games to somewhere in your home directory and it should work again, I believe, but I can’t give you more details at the moment…

FWIW, here’s the bug report: Access Denied
So apparently it is not possible to use a highscore file in the home directory.
But I guess you could change the binary’s (“/usr/bin/sol”) group to “games” and set the setgid flag. Or give all users write permissions to the files in /var/games.

Btw, why are you playing Aisleriot if you’re a KDE guy? Ever had a look at KPatience? :wink:

Thanks for all the good suggestions. There were certainly some configuration issues: creating a new user fixed the screen locking issue.

Question. Did you have any other repository active save the oss and non-oss repos? Having more repos active during the upgrade causes problems. If that was the case, the cure might be to disable those repos and do the zypper dup again.

Read various howto’s before doing the upgrade, which suggested (IIRC) disabling all the repositories except for the new 12.3 and 12.3 updates (and maybe 12.3 non-oss?). Then I re-enabled the rest of my repositories as I thought appropriate (ie pacman) and updated if a newer version was available from YAST.

True; but the command “rcrpmconfigcheck” lists the system config files
that are altered or that should be altered.

There are a handful that are pointed out by this command.

etc/default/passwd.rpmnew
/etc/init.d/mythbackend.rpmsave
/etc/ntp.conf.rpmnew
/etc/pam.d/common-account.rpmnew
/etc/pam.d/common-auth.rpmnew
/etc/pam.d/common-password.rpmnew
/etc/pam.d/common-session.rpmnew
/etc/pam.d/login.rpmnew
/etc/plymouth/plymouthd.conf.rpmnew
/etc/postfix/main.cf.rpmnew
/etc/postfix/master.cf.rpmnew
/etc/samba/smb.conf.rpmnew
/etc/sane.d/dll.conf.rpmnew
/etc/sysconfig/SuSEfirewall2.rpmnew
/etc/xinetd.d/vnc.rpmnew
/usr/share/fonts/encodings/encodings.dir.rpmsave
/usr/share/info/dir.rpmnew
/usr/share/kde4/config/kdm/kdmrc.rpmnew

Some of these seem to be ok. I don’t want to reset my firewall configuration, do I? I fixed kdmrc. That or creating a new user seems to have changed the look and feel of my plasma network monitor widget.

For your suspend/hibernate problems, try to run “pm-suspend” or “pm-hibernate” from the command line and have a look in /var/log/pm-suspend.log if there’s any clue.
What I actually ran from the command line was “systemctl suspend” because I read that we’re using systemd now, and that’s what the systemd help files say to use. The logs look clean. Sleep seems to happen fine, but the system locks up upon waking up again.

If you have “acpid” installed, try to uninstall it. It may clash with systemd, which takes over most of the powermanagement functions now.

It WAS installed, and I removed it. Didn’t seem to fix anything though. But maybe we’re on to something here…

I wonder if this can be sysvinit-vs-systemd issue. Did you end up using sysvinit or systemd after jump from 12.1?

As I mentioned, I read up on the changes. It never occurred to me that I wouldn’t end up with systemd. When I checked which rpms are installed I found I had… BOTH! Yeah that’s probably a check in the “not good” column. My first thought was to just remove the sysvinit packages. My second thought was that if it wasn’t obvious to the upgrade process I should ask for advice first.

Thoughts?

On 2013-09-16 18:15, incognito9 wrote:

>> True; but the command “rcrpmconfigcheck” lists the system config files
>> that are altered or that should be altered.
>
> There are a handful that are pointed out by this command.

Well. Those named .rpmsave are your old configuration. The system is
using a totally new config ignoring your configuration.

Those named .rpmnew are using the old configuration instead. The new
config is in that .rpmnew file, so new features in config are not in use.

So, you have to manually check those files one by one, and when done,
delete all of them (.rpm*). Or move them to another directory under
/root/something.

Until you do, some services might be broken.

I do it this way:


meld /etc/init.d/mythbackend /etc/init.d/mythbackend.rpmsave

and accept or reject modifications as appropriate.

>> For your suspend/hibernate problems, try to run “pm-suspend” or
>> “pm-hibernate” from the command line and have a look in
>> /var/log/pm-suspend.log if there’s any clue.

> What I actually ran from the command line was “systemctl suspend”
> because I read that we’re using systemd now, and that’s what the systemd
> help files say to use.

Don’t you believe everything you are told :stuck_out_tongue:

Why?

Because the old method runs a bunch of script and hacks to solve known
hibernation problems. The new method does not.

>> I wonder if this can be sysvinit-vs-systemd issue. Did you end up using
>> sysvinit or systemd after jump from 12.1?
> As I mentioned, I read up on the changes. It never occurred to me that I
> wouldn’t end up with systemd. When I checked which rpms are installed I
> found I had… BOTH! Yeah that’s probably a check in the “not good”
> column. My first thought was to just remove the sysvinit packages. My
> second thought was that if it wasn’t obvious to the upgrade process I
> should ask for advice first.

What systemv packages exactly? Because there are some compatibility
packages that should be installed.


Cheers / Saludos,

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

I have the following packages installed:


sysvinit - System V style init programs by Miquel van Smoorenburg
|sysvinit-tools - Tools for basic booting|
|---|


syslog-service -  Syslog service files & scripts
systemd - A System and Session Manager

|systemd-sysvinit - System V init tools|
|---|



I think the first two-- sysvinit and sysvinit-tools-- need to go. The rest look ok.

I’ll try out pm-hibernate and pm-suspend later this afternoon and see if those make a difference.

Thanks again for the help.

No! You need those, especially sysvinit-tools. Trying to remove that will remove most of your system as well because of dependencies…
The “real” sysvinit, that is replaced by systemd, would be “sysvinit-init”.

sysvinit-tools seems to break setserial
Removing sysvinit doesn’t break anything.

Glad I didn’t just go ahead and remove them yet.

Not only that.
Running “zypper rm sysvinit-tools” wants to remove 1731 packages on my system!
Just try it, you can still say no when zypper asks for confirmation (or use the option “–dry-run” to be on the safe side). :wink:

The following packages have direct dependencies on sysvinit-tools:

 rpm -e --test sysvinit-tools
error: Failed dependencies:
        sysvinit-tools is needed by (installed) sysvinit-2.88+-83.2.1.x86_64
        sysvinit-tools is needed by (installed) mkinitrd-2.7.2-3.5.1.x86_64
        /bin/pidof is needed by (installed) udev-195-13.40.1.x86_64
        /sbin/checkproc is needed by (installed) rpcbind-0.2.0_git201103171419-7.1.1.x86_64
        /sbin/isserial is needed by (installed) setserial-2.17-736.1.1.x86_64
        /sbin/pidof is needed by (installed) lsb-4.0-20.1.1.x86_64

The rest will be uninstalled as consequence of removing those…

I’m not sure if the package “sysvinit” is needed or if it’s only there for compatibility, though. But I do have it installed and don’t have your problems, so better keep it I would say.

On 2013-09-16 19:46, incognito9 wrote:
>
> I have the following packages installed:
>
>
> Code:
> --------------------
>
> sysvinit - System V style init programs by Miquel van Smoorenburg
>
> sysvinit-tools - Tools for basic booting
>
> syslog-service - Syslog service files & scripts
> systemd - A System and Session Manager
>
> systemd-sysvinit - System V init tools
>
> --------------------


Telcontar:~ # rpm -qa | grep -i sysvinit
sysvinit-2.88+-83.2.1.x86_64
systemd-sysvinit-195-13.40.1.x86_64
sysvinit-tools-2.88+-83.2.1.x86_64
Telcontar:~ #

This is normal. The first one is almost empty:


Telcontar:~ # rpm -ql sysvinit
/lib/sysvinit
/lib/sysvinit/telinit
/sbin/sysvinit
Telcontar:~ #

>
> I think the first two-- sysvinit and sysvinit-tools-- need to go. The
> rest look ok.

None needs to go. They are designed to be there.


Cheers / Saludos,

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

Be careful with /etc/pam.d. Packages and yast in openSUSE often add and remove entries dynamically; so .rpmnew represents just the most basic content. Blindly replacing existing files with .rpmnew may actually cause missing features (like pam_sysemd).

Unfortunately, I’m not aware of any command that could recreate /etc/pam.d files according to current configuration.

> What I actually ran from the command line was “systemctl suspend”
> because I read that we’re using systemd now, and that’s what the systemd
> help files say to use.

Don’t you believe everything you are told :stuck_out_tongue:

Why?

Because the old method runs a bunch of script and hacks to solve known
hibernation problems. The new method does not.

In 12.3 systemd calls pm-utils if it is present.

On 2013-09-17 06:36, arvidjaar wrote:
>
> robin_listas;2585404 Wrote:
>>
>> Those named .rpmnew are using the old configuration instead. The new
>> config is in that .rpmnew file, so new features in config are not in
>> use.
> Be careful with /etc/pam.d. Packages and yast in openSUSE often add and
> remove entries dynamically; so .rpmnew represents just the most basic
> content. Blindly replacing existing files with .rpmnew may actually
> cause missing features (like pam_sysemd).

Correct. I did not say “copy files”, but “edit files as appropriate”,
which an understatement.

> Unfortunately, I’m not aware of any command that could recreate
> /etc/pam.d files according to current configuration.

Me neither. Except, install another system and copy files across, perhaps.

> In 12.3 systemd calls pm-utils if it is present.

In my system, the systemd call doesn’t work as smooth.


Cheers / Saludos,

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

UGRH.

All I managed to do was break things further. When I first posted here I was sure that I was very very close to fixing these few issues when I first posted on this thread. Apparently not.

Upgrading by changing the repositories and doing a zypper dup, as I said in an earlier post, went extremely smoothly. Installing 12.3 from scratch was a completely miserable experience. What made it even worse was that I installed 12.3 on two other machines with similar configurations and the install went fairly smoothly in those cases.

Some of the hurdles I faced:
grub2 refused to install and configure properly. I’m guessing it was confused by the presence of multiple hard drives on this computer? Previously grub had trouble with that and I configured things from the grub command line. Didn’t work out with grub2, so I had to re-reinstall and use grub instead of grub2. This time around grub configured itself perfectly. but then…
The open source nvidia driver didn’t work. At all. Hung the system. Had to reboot into the failsafe setup to configure the system. Got the proprietary drivers added and everything updated and things were up and running fairly smoothly again. So where am I now?

Some of my previously compiled software is still not working. Compiled against a much older version of the QT libraries, so I have some porting to do.
Booting into runlevel 3 works again.
Hibernate works, but is very slow. Much slower than before. It seems subjectively slower than my son’s computer, which is my old one.
Waking from sleep still locks up the system, though it does so in a very different way. Before, It would draw an inch or so of the “computer is locked” screen starting at the top and die. Now it puts a colorful bar across the bottom of the screen-- white, blue, and orange. This seems like a graphics driver problem (which is what I thought to begin with) and I’m hopeful that there may be some combination of a linux kernel version with an nvidia driver version that works. I really wish 12.1 were supported for another six months or a year.