Yes. DKMS seems like a really good way of doing it.
Unfortunatly it doesn't work very well for Virtualbox yet.
This is what I get when I start virtualbox, even though I have the packages
installed and the module is compiled everytime I kernel-upgrade:
-
WARNING: The
try doing /etc/init.d/vboxdrv restart, then running virtualbox. if that
works read on:
if you have been doing an upgrade on intrepid for a while, you are stuck with
some old settings that dont work (but have since been fixed on fresh installs)
if you remove and purge all the virtualbox stuff,
It finds vboxdrv now.
However, now VirtualBox reports the following error:
VirtualBox can't operate in VMX root mode. Please disable the KVM kernel
extension, recompile your kernel and reboot.
VBox status code: -4011 (VERR_VMX_IN_VMX_ROOT_MODE).
Does this mean I can't have kvm installed in
this is done now in ubuntu intrepid
--
Should ship new kernel modules at same time as new kernel
https://bugs.launchpad.net/bugs/253831
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I'm closing this bug as Fix Released since in Intrepid virtualbox-ose
uses dkms to automatically build the kernel module for ABI bumps.
Pascal, please file a new bug report for your new issue. Sorry, I cannot say
anything about the combination of kvm/virtualbox: it works for me using the
According to the release notes, intrepid alpha 5 now includes dkms.
Could this be used to solve this problem?
--
Should ship new kernel modules at same time as new kernel
https://bugs.launchpad.net/bugs/253831
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I also don't see why providing the module would be a problem anyway.
It's open source and as long as the kernel changes are not breaking the
build of that module it should always be delivered with the new kernel.
--
Should ship new kernel modules at same time as new kernel
That won't work, since the old images still are available (and
therefore won't cause a conflict).
I don’t understand your objection. Note that the goal is not to
conflict with any kernel image packages, but only with new versions of
the linux-image-generic _metapackage_, which is responsible
That won't work, since the old images still are available (and therefore won't
cause a conflict).
Apart from that, a missing kernel module (from universe) should not block a
security kernel update.
There's a solution in sight (DKMS, IIRC) for Intrepid. Somebody wanted
to look into it, but it
Now, after rolling linux-image-2.6.24-21 out, my virtualization will be
broke again. Last time it took almost a week before it worked again.
I think Anders proposes a good idea. Now, how does this practice become
spread out? I suppose this message has got to go out to the maintainers,
right?
--
This could be solved by modifying each module metapackage to depend on
an exact version of the corresponding linux-image metapackage. For
example:
Package: virtualbox-ose-modules-generic
Depends: virtualbox-ose-modules-2.6.26-5-generic, linux-image-generic (=
2.6.26.5.7)
Then kernel upgrades
** Also affects: virtualbox-ose-modules (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux-meta (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: Confirmed = Invalid
--
Should ship new kernel modules at same time as new
** Changed in: linux (Ubuntu)
Importance: Undecided = Wishlist
--
Should ship new kernel modules at same time as new kernel
https://bugs.launchpad.net/bugs/253831
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
13 matches
Mail list logo
