I’m currently running Tumbleweed 20170125, and after an attempt to update the system, I was no longer able to launch it correctly; after the boot sequence, all I got was a X window stating that “Could not start kdeinit5. Check your installation”.
I reverted back to a previous snapper snapshot, and tried to update again, just in case something went wrong the first time, but I still have this problem.
How can I diagnose and solve this ?
This sounds like http://bugzilla.opensuse.org/show_bug.cgi?id=1022459 .
Are you using infinality? That seems to break things currently.
If not, try to run kdeinit5 in a terminal window (xterm or konsole) and post the output.
Also, how did you update?
Maybe try running “zypper dup” instead if you used “zypper up” or the desktop’s updater applet.
Yes, I use infinality fonts from this repo http://download.opensuse.org/repositories/home:/nick31:/INFINALITY-ULTIMATE/openSUSE_Tumbleweed/
I’ll try to disable it, migrate its packages to the default ones, and update the whole system again.
It is a pity, I’ve found that using Infinality greatly improves the font rendering on my laptop, I’ve used it since I started to use openSUSE and I’ve nevee had any problem. But if the alternative is to break the system, I think that I have no choice.
I usually update with “zypper up”.
you should update first with zypper dup --no-allow-vendor-change
they made some changes to font rendering about 2 months ago if you didnt know
im surprised, fonts are perfect on my system except firefox (i use chrome)
I don’t see how that could possibly help here.
It will by definition not fix the incompatibility between the mentioned repo and the rest of the system, because it will keep the (currently) incompatible packages from that repo…
What’s the difference between “zypper up” and “zypper dup --no-allow-vendor-change” ?
Anyway, when I first installed my system, the default font configuration without Infinality fonts was really bad, at least on my machine, and it really was annoying to see badly drawn and sometimes unreadable characters on the screen.
I was just sticking with the solution that worked for me.
No after trying out the new packages on the default repo, I see that the font rendering is greatly improved, and even if it is slightly different to what I was used, I no longer need Infinality repos to have a pleasant experience.
The main difference between “up” and “dup” is that “up” only updates packages (i.e. it won’t install a lower version but rather keep the installed one even if it’s not available in any repo), while “dup” always takes the version that’s in the repos even if it would be a downgrade.
The other main difference is that “dup” normally ignores from which repo a package is installed, it just takes the highest version available in all configured repos (or the one from the repo with the highest priority), while “up” only considers packages with the same vendor (i.e. from the same repo).
“–no-allowed-vendor-change” prevents “zypper dup” to switch packages to other repos, so it makes it behave a bit more like “up” (which uses “–no-allowed-vendor-change” as default)
That’s considered safer than “dup” alone if you have additional repos and it should avoid surprises like Packman packages getting replaced with the crippled versions from the standard repos.
(If you only use the standard repos, there’s no difference anyway)
So if using this option, only the first point applies, i.e. “zypper dup --no-allow-vendor-change” will also downgrade packages (if only a lower version is in the same repo meanwhile) while “zypper up” will only install packages with a higher version (from the same repo).
There are other minor differences, e.g. “dup” will also remove packages that are listed as dropped, and it will try harder to resolve conflicts automatically (at least partly due to the fact that it will also consider downgrades).
perhaps you have greater insight into what the root of the problem is, what i see is that someone most likely has an inconsistent system from using “up” which has the potential to cause problems and is a poor starting point for diagnosis.
Maybe try running “zypper dup” instead if you used “zypper up”
my mistake - i did not realise a dup alone was in fact part of the solution.
Well, I did post a link to a bug report that sounded similar in my first reply. 
my mistake - i did not realise a dup alone was in fact part of the solution.
Yeah.
If a problem is caused by mixing incompatible packages from different repos, “zypper dup” is better suited trying to fix it.
But of course it may also involve removing some repos first.
I do agree with you that “zypper dup” (unrestricted) is not a good way to keep your system up-to-date if you use additional repos (as I wrote, with the standard repos there is no difference as there is no vendor change anyway)
Even more so on Leap where a normal “up” should be the better choice in any case.
Unless you want to switch all packages to some repo like Packman in the first place, but then it’s better to restrict “dup” with the “–from” parameter…
Honestly I don’t think that I have a messed up list of repos.
Repository priorities are without effect. All enabled repositories share the same priority.
# | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service
---+---------------+-----------------------------+---------+-----------+---------+----------+--------+-------------------------------------------------------------------------------+--------
1 | google-chrome | google-chrome | Yes | (r ) Yes | Yes | 99 | rpm-md | http://dl.google.com/linux/chrome/rpm/stable/x86_64 |
2 | google-earth | google-earth | Yes | (r ) Yes | Yes | 99 | rpm-md | http://dl.google.com/linux/earth/rpm/stable/x86_64 |
3 | libdvdcss | libdvdcss | Yes | (r ) Yes | Yes | 99 | rpm-md | http://opensuse-guide.org/repo/openSUSE_Tumbleweed/ |
4 | packman | packman | Yes | (r ) Yes | Yes | 99 | rpm-md | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/ |
5 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/debug/tumbleweed/repo/oss/ |
6 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Yes | (r ) Yes | Yes | 99 | yast2 | http://download.opensuse.org/tumbleweed/repo/non-oss/ |
7 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | Yes | 99 | yast2 | http://download.opensuse.org/tumbleweed/repo/oss/ |
8 | repo-source | openSUSE-Tumbleweed-Source | No | ---- | ---- | 99 | NONE | http://download.opensuse.org/source/tumbleweed/repo/oss/ |
9 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/tumbleweed/ |
10 | sekhemty | sekhemty | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/repositories/home:/sekhemty/openSUSE_Tumbleweed/ |
11 | skype-stable | skype (stable) | Yes | (r ) Yes | Yes | 99 | rpm-md | https://repo.skype.com/rpm/stable/ |
Besides the standard repos + packman, the other few repos that I have enabled don’t have much package overlapping and I usually double-check the updates.
I usually update with zypper up, is that something that can lead to problems?
No, not really.
Although, you can put anything into your home: repo, that may mess up things…
Repository priorities are without effect. All enabled repositories share the same priority.
That means that “zypper dup” would “randomly” take packages from any repo.
Well, not quite random, it will take the one with the highest version, from whichever repo it comes.
Besides the standard repos + packman, the other few repos that I have enabled don’t have much package overlapping and I usually double-check the updates.
Yes, but “zypper dup” may switch back packages from Packman to the standard repos, which lack support for non-free codecs.
There is no guarantee that the packages in Packman have a higher version.
Actually, many of Packman’s packages are just links to the standard ones (with additional features enabled), so they are exactly the same version.
So the rebuild count will decide which ones will be taken.
You can circumvent this problem by giving Packman a higher priority, then “zypper dup” will take the packages from there.
Or use “zypper dup --no-vendor-change”, so it will take packages from the same repo as they are currently installed from.
I usually update with zypper up, is that something that can lead to problems?
It should normally be ok.
But there can be situations where “zypper up” won’t do well.
It might give conflicts, or it might overlook “updates”.
There was a case like this recently, when the versioning scheme was changes for the Xorg packages.
Instead of 7.6_1.18.3 (which doesn’t make any sense for a long time, but was kept for compatibility), it has the “real” version now, 1.19.1, which is lower than the previous one.
“zypper up” will just not install that “update” (which is a downgrade according to the version number). There were people having problems because of that.
Also, as mentioned, “zypper up” will not uninstall packages that got dropped from the distribution, while “zypper dup” (with or without "–no-allow-vendor-change) will.
There was quite a long mailing list discussion on opensuse-factory recently about the “proper” way to update a Tumbleweed system, and the preferred way is “zypper dup --no-allow-vendor-change” (that option is relatively new btw).
But as I wrote, “zypper up” should be fine most of the time, but it’s a good idea to use “dup” (preferably with “–no-allow-vendor-change” to prevent vendor change and surprises caused by that) from time to time too, especially if you do have problems.
Actually that was the recommended thing since (the new) Tumbleweed exists, before the “–no-allow-vendor-change” was added to “zypper dup”.