Leap 15 system broken by one-click install

I had a smoothly running leap 15 installation until I attempted to do a one-click install of something or other (google earth I think). That failed. On next boot I was offered a huge list of updates, which I accepted at face value. Next attempt to boot showed TW instead of Leap in the grub menu and choosing that ended in the machine being stuck in an totally unresponsive black screen. From a different Linux on that machine, the relevant Leap BTRFS+LVM partition was showing up as corrupted and could not be mounted. From another forum thread I gather that the trigger for all of this can be a bad one click install. While I recovered the system using a previous external image-copy based backup, I would like to better understand what happened and how to avoid a repeat of this.

So, may I ask or request pointers to documentation on:

  • How does the one-click process work? Is the process itself based on an OpenSuse design/product/pattern?
  • Does it check the target OpenSuse OS flavour before doing it’s thing?
  • Does OpenSuse necessarily have any QA role over one-click install offers?
  • Am I better off avoiding using all one-click install offers like the plague?
  • What do I need to look out for with one-click install offers otherwise?


I wouldn’t be surprised of none of the regular helpers here use it enough to know answers to all your questions. I certainly do not. All I know can be found on SDB One_click_install, and what I can remember from the mailing lists and these forums. The main thing I remember is that what happened to you seems too common. Typically a wanted package is only in BS or TW repos, and the user fails to notice before proceeding that the desired package selected is not for the OS version it is to be installed into. Probably the SDB page needs emphasis added for ensuring this does not happen.

First: If you have btrfs, you can rollback to a snapshot before the one-click.
To the rest of your questions: No, though I’d love to see some mechanism that avoids doing so.
Then again, the one-click procedure actually tells you it’s going to add the TW repo, which you chose to ignore.
FWIW, it cannot have been google-earth, google have their own ( version independent ) repos.

I’m not an expert on that. As far as I know, it adds a repo and then installs one or more packages from that repo. But it leaves the repo enabled. If you were to disable the added repo (or repos), you would be less likely to run into this problem.

Does it check the target OpenSuse OS flavour before doing it’s thing?

If you used a package search on “software.opensuse.org”, then it tells you what opensuse version the package is for. But perhaps it does not tell you that is a sufficiently prominent way.

I did open a bug report: Bug 1130707
on this issue. But I don’t know whether that’s enough to get the problem fixed.

My advice: if you do a package search on software.opensuse.org, pay careful attention to the opensuse version. If the package is for Tumbleweed or factory, then click the option to find other versions. If you cannot find a version of the package appropriate to your opensuse version, then think twice before installing. And if you install anyway, then go back and disable the added repos.

Any time you see a huge update for Leap you know you have somehow added a Tumbleweed repo.

You must pay attention when doing one clicks since all current OS are in the lists there. You must be sure to select only Leap sources. You can install programs from TW but you must then disable or remove that repo or you can get slammed.

You can correct if you can boot to the terminal and remove or disable any TW repos and do a zypper dup to bring you back to pure leap

One Click Installer picks up correct distribution version if it is specified in YMP file (it can contain multiple distributions). Otherwise there is no way OCI can verify that given file is intended for current (distribution) version. In specific case of SOO it needs actual example to verify that it defaults to wrong distribution, in which case it may be fixed for this site. There is also usability issue - default link offered by SOO does not mention distribution and so is extremely confusing.

In general case it is up to publisher to include correct distribution tag and up to user to double check what link (s)he clicks on.

But it leaves the repo enabled.

This is controlled by YMP file itself (at least, default setting). Normally leaving repository enabled is the expected result - it ensures receiving updates for your software.

Having caused several involuntary distro up-/down-/sidegrades in the distant past (with Yellow Dog, Mandrake, Ubuntu, Debian stable/testing, and some massive recompiles with Gentoo) while »just« playing around, I have grown weary of those »one-click« wonders.

Nowadays, I always look into a YMP file for a package I’m interested in, and then perform the steps manually with YaST myself:

  • add the repository
  • check its digital fingerprint
  • select the package in YaST’s Software Management
  • look closely at any changes that the dependency solver proposes
  • check changes again in the »Installation Summary« tab
  • install what I’ve selected if (and only if) I’m satisfied

Not only do I learn more this way about the interplay and function of — in part obscure — bits of software (because YaST’s Software Management module lets me read descriptions, file listings, dependencies and recommended packages — see »Extras« menu), I also avoid those avalanche-like, massive install »orgies«, for example when you find yourself installing half of Gnome when on a KDE system or vice-versa.

Even with the possibility of rolling back to a former btrfs snapshot, you cannot ever get back the time it took to install hundreds of packages. In my opinion, the snapshot ability may give some users a false sense of security and not make them backup their stuff regularly anymore. Using ext4 exclusively myself, I prefer the quick, simple, incremental regular backup to external SSD. It never fails. Restored btrfs snapshots, however, have been found to be broken occasionally in the past, or the restored snapshot wouldn’t bring back the installation to the state the user remembers it should have been back then. I feel that starting from a clean backup or a fresh installation are better options.

Maybe container technologies like Docker, FlatPack or AppImage could help in the future, and be able to prevent a Leap installation from involuntarily turning into Tumbleweed — along with the cost of some inevitable redundancy and storage overhead (two containers with Qt-based software each having their Qt libraries on board and so on). We’ll see.

Cheers, and nice holidays if you’re into the whole bunny-and-eggs thing. :wink:

Here is what i do to avoid that sort of problem:

  • I use One-click-installs only on rare occasions and if i do, i always check my list of repositories directly afterwards (to disable any unwanted repository brought in by the one-klick-install).
  • I update my system very regularly (if possible every day but at least once a week). openSUSE Leap releases in general will not receive several hundred updates within a week (openSUSE Tumbleweed is different!). However if that happens, i do not accept the updates but check my list of repositories for enabled “unwanted” repositories (like ones not belonging to the release i am running) first.



Here is the definitive answer

Every time you use the One-Click Install, the very first screen displayed will suggest adding repos.
In the following screenshot from a 15.1, this is an example of what you would see installing a package from a Tumbleweed repo.

  • Note that at least one entry (only one in this case) is checked by default
  • Note the Tumbleweed name in the repository URI, in fact it is the Tumbleweed main repository!

If you proceed and click “Next” then the repository will be added and enabled to your system which can cause additional Tumbleweed packages to be installed the next time your system is updated, and in the worst case can cause your system to be converted to the other openSUSE version (eg Tumbleweed) unexpectedly and unintentionally.

To Avoid catastrophe!
[HR][/HR]In this example situation, because the system is not Tumbleweed** it’s critical to uncheck the box** to add the new repository.
Note that it might be human nature to assume the default setting will always be the safe setting but in this case it’s not!

After unchecking the entry, the “One-Click Install” will remain connected to the alien repository for only as long as it takes to install the package, but no longer so that it won’t be present when your system is next updated.

Am not sure why there is also the checkbox at the bottom to “remain subscribed,” it does the same thing as unchecking the boxes in the selection pane above.