Comment # 42 on bug 1178360 from Stefan Hundhammer

It keeps getting weirder and weirder.

I did more experiments with kernel-default locked and doing "zypper dup" for
all the rest. I had not realized that this would also install
kernel-default-base which zypper installed to resolve the dependencies of
virtualbox-kmp.

That lead to being restricted to a 640x480 (standard VGA) screen resolution
because virtualbox-kmp could not be properly initialized:

Nov 12 14:21:12 localhost kernel:

  vboxvideo: Unknown symbol ttm_bo_mmap (err -2)
  vboxvideo: Unknown symbol ttm_bo_manager_func (err -2)
  vboxvideo: Unknown symbol ttm_bo_glob (err -2)
  vboxvideo: Unknown symbol ttm_bo_device_release (err -2)
  vboxvideo: Unknown symbol ttm_bo_kunmap (err -2)
  vboxvideo: Unknown symbol ttm_bo_device_init (err -2)
  vboxvideo: Unknown symbol ttm_bo_init_mm (err -2)
  vboxvideo: Unknown symbol ttm_bo_dma_acc_size (err -2)
  vboxvideo: Unknown symbol ttm_tt_init (err -2)
  vboxvideo: Unknown symbol ttm_bo_kmap (err -2)
  vboxvideo: Unknown symbol ttm_bo_init (err -2)
  vboxvideo: Unknown symbol ttm_bo_validate (err -2)
  vboxvideo: Unknown symbol ttm_bo_move_to_lru_tail (err -2)
  vboxvideo: Unknown symbol ttm_bo_put (err -2)
  vboxvideo: Unknown symbol ttm_tt_fini (err -2)
  vboxvideo: Unknown symbol ttm_bo_eviction_valuable (err -2)

But there was no pixel garbage.

Later I unlocked kernel-default, uninstalled kernel-default-base (which also
uninstalled the virtualbox-* packages) and then force-reinstalled the new
kernel and the virtualbox-* packages:

  zypper in --force kernel-default virtualbox-guest-x11 virtualbox-guest-tools
virtualbox-kmp-default

...and now everything is working again: No pixel garbage, not restricted to
640x480.


Somehow I feel this is a bootstrap problem of the involved packages or a binary
compatibility problem: Just like previously, upgrading the packages step by
step appears to work fine, while upgrading everything at once has weird side
effects.

virtualbox-kmp-default rebuilds the kernel module in its post-install script
(and  recreates the initrd with dracut). Is it possible or plausible that in
certain situations it does that with the wrong kernel headers or something like
that? Using the ones of the currently running kernel rather than the one that
is also being installed in the same "zypper dup" run?

Is it plausible that this might be only a missing dependency in the virtualbox
.spec file; or a post-install script being executed at an inappropriate time,
before the complete upgrade process is complete?