Today’s X11:Bumblebee/nvidia-bumblebee break my Davinci Resolve installation.
Davinci Resolve is very sensitive to driver version,
how can I have the RPMs back I had until this update? I can not find them.
In Leap 15.0, the old versions should all still be there (in the repo). It is only in Tumbleweed that they disappear.
Open Yast Software Management
Search for the package
Click the “Versions” tab toward the bottom of the screen. Select the version that you want. And, after it is installed, best to lock it so that it does not update without your agreeing.
If you are not sure what was the previous version, then check history, which you can also do within Yast Software Management.
This is external repository, only official update repository keeps history.
You will need to build it yourself. Either locally or using OBS (in the latter case you will need to branch it so you can revert to previous version).
OK, thanks, . Sounds like the hard way,
But I will try this, hopefully there is a history of the spec files available.
Hi
There is, previous was rev 71;
https://build.opensuse.org/package/show/X11:Bumblebee/nvidia-bumblebee?rev=71
OBS seems to be mega awesome!
it was just a few clicks to get the rpms
https://download.opensuse.org/repositories/home:/a4z:/branches:/X11:/Bumblebee/openSUSE_Leap_15.0/
now I need just find out how to proper downgrade just the driver to my repo version
for the future I need of course find out how to get a workflow that, after a new Resolve version
- let me test which (latest) nvidia-bumblebee driver work
- pin my repo to the working version
- be able to swtich back and forth with the nvidia-bumblebee between the original repo and my one
did not fix the problem, davinci still not running, 
it worked, I got some update, it stopped working,
I don’t know why, but I start to become tired of this problems …
also, noticed this, when I run a GUI app
Invalid MIT-MAGIC-COOKIE-1 key
mind blowing
so after rolling back the driver did not work I switched to the regular ones,
and it did not work
last week there was a kernel update, and maybe other stuff
and guess what
now davinci works again on my notebook!
but why, it drives me mad that I do not know why or what is going on,
I wish I could eliminate this random breakage
Hi
Well it’s the kernel updates and all the out of tree kmp’s bumblebee etc that may not be built when a kernel-update arrives… So lock and wait, or be selective in what’s updated rather than just zypper up…
today additinal updates in the Q
he following package update will NOT be installed:
bbswitch-kmp-default
The following 13 packages are going to be upgraded:
bbswitch bumblebee chrony dkms libstorage-ng1 libstorage-ng-lang libstorage-ng-ruby primus timezone timezone-java VirtualGL VirtualGL-devel yast2-bootloader
I am full of fear and do not update, this is not how my Linux experience should be
unfortunately, since I had problems with btrfs on notebook I cant make snap shots since I am on ext4,
I start to understand why there are so many apps that will never come to Linux …
Hi
Well, perhaps if users stopped buying proprietary driven graphics hardware… 
It’s also the nature of OBS and repository priorities, some things lag (esp if OBS is busy) before they are rebuilt. So, just be patient and wait for the kmp to be rebuilt to match the kernel.
Hi
From your list, you could just install;
zypper up chrony libstorage-ng1 libstorage-ng-lang libstorage-ng-ruby timezone timezone-java VirtualGL VirtualGL-devel yast2-bootloader
I know this argument very well,but if you render a video 12 hours, or 4, makes a different, especially if its for a hobby that you do after work in the evening
(I record and render techtalks from meetups I organize)
And I have not the money to by a thinkpad A something with AMD just to see if this works better, and in general, my t460p is still great and optimus is working,
its just this app, and lightwork does not work on openSuSE either because of some odd so name issue
I know, I wish this things would not come from OBS …
will see, I have some more current work to do from our recent meetup, when this is done than I will run the update, and see what happens.
if it stops working again, I will think what I do, I have a intel fallback machien, but this is not fun doing this type of work on it, 15 hours of rendering for the latest 1.5 hour presentation video …
What are you talking about? bbswitch is provided by Leap main repo. It is part of official Leap stable distribution. SUSE guarantees kernel ABI stability during version lifetime which means KMP built for one kernel must work for all further kernel updates and does not need rebuild. If it does not work after kernel update and needs rebuild, it is bug that must be reported. If it incorrectly requires exact kernel version that was used to build it, it is bug and must be reported.
Whenever my system is in a seemingly inconsistent state, I check whether my initial RAM disk (initrd) reflects the changes I’ve made in my Linux installation (especially manual changes).
**l -rt /boot/**
total 139088
-rw-r--r-- 1 root root 196482 2018-12-04 11:47 config-4.12.14-lp150.12.28-default
-rw-r--r-- 1 root root 3475997 2018-12-04 12:39 System.map-4.12.14-lp150.12.28-default
lrwxrwxrwx 1 root root 34 2019-01-18 09:47 initrd -> initrd-4.12.14-lp150.12.45-default
...]
-rw------- 1 root root 50294784 2019-01-18 09:48 initrd-4.12.14-lp150.12.28-default
drwxr-xr-x 6 root root 4096 2019-01-18 09:49 grub2/
-rw------- 1 root root 51463680 **2019-01-18 09:50** initrd-4.12.14-lp150.12.45-default
drwxr-xr-x 4 root root 4096 2019-01-18 09:50 ./
Let’s say I manually updated my proprietary NVidia drivers or changed any configuration needed during boot after 2019-01-18. That would mean that next time my system will start up with an outdated initrd.
The remedy:
sudo dracut --force
… or, in my case, forcing a minimal custom initrd with USB+IPv4+ext4 support only:
sudo dracut --verbose --hostonly --force --no-compress --omit "img-lib cifs fcoe fcoe-uefi rdma multipath iscsi qemu lvm mdraid dm dmraid cdrom pollcdrom plymouth btrfs wacom convertfs wicked ipv6 mtp-probe"
Usually, YaST2 updates the initrd automatically whenever necessary (I don’t know about zypper in this case, I usually run YaST’s package-management and software-update modules because I find it more informative, and I can use AutoYaST to replicate+automate things server-side). Can’t hurt to check after updating or rolling back a RPM package too. Cheers!
I did all the work I had in Q and than run the full update, and this time everything continues to work, hurra!
still makes me nervous that I do not understand why id did not work with some state in between, the problem was something with opencl
is there a way I could help the authors of the bumblebee packages to ensure that davinvi resolve runs report something back?
I think it would be good for openSUSE to be able to run a professional video editing software like this, especially since lightworks has this strange so name issuel