[opensuse-factory] Virtualbox broken on tumbleweed
Hi, Virtualbox is currently broken on tumbleweed because its kernel module has not been rebuilt against the latest kernel release. Right now on my machine I have the following packages: virtualbox-5.0.4-1.1.x86_64 virtualbox-host-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 virtualbox-guest-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 kernel-desktop-4.2.1-1.2.x86_64 I thought a kernel upgrade should automatically trigger a rebuilt of the virtualbox kernel packages. Cheers Flavio -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/06/2015 10:37 AM, Flavio Castelli wrote:
Hi, Virtualbox is currently broken on tumbleweed because its kernel module has not been rebuilt against the latest kernel release.
Right now on my machine I have the following packages:
virtualbox-5.0.4-1.1.x86_64 virtualbox-host-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 virtualbox-guest-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 kernel-desktop-4.2.1-1.2.x86_64
I thought a kernel upgrade should automatically trigger a rebuilt of the virtualbox kernel packages.
I thought so as well, but it seems not to be the case. If any gurus can shed light on this issue, please jump in here. I just checked out virtualbox from Factory, and it built for kernel 4.1.6-3.0. Why that kernel was selected is also a mystery. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-10-06 at 11:02 -0500, Larry Finger wrote:
On 10/06/2015 10:37 AM, Flavio Castelli wrote:
Hi, Virtualbox is currently broken on tumbleweed because its kernel module has not been rebuilt against the latest kernel release.
Right now on my machine I have the following packages:
virtualbox-5.0.4-1.1.x86_64 virtualbox-host-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 virtualbox-guest-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 kernel-desktop-4.2.1-1.2.x86_64
I thought a kernel upgrade should automatically trigger a rebuilt of the virtualbox kernel packages.
I thought so as well, but it seems not to be the case. If any gurus can shed light on this issue, please jump in here.
I just checked out virtualbox from Factory, and it built for kernel 4.1.6-3.0. Why that kernel was selected is also a mystery.
Rebuilds are triggered - but they only have an effect if the package builds. Follow for example the thread about the latest TW snapshot release at http://lists.opensuse.org/opensuse-factory/2015-10/msg00161.html Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op Tuesday 06 October 2015 17:37:04 schreef Flavio Castelli:
Hi, Virtualbox is currently broken on tumbleweed because its kernel module has not been rebuilt against the latest kernel release.
Right now on my machine I have the following packages:
virtualbox-5.0.4-1.1.x86_64 virtualbox-host-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 virtualbox-guest-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 kernel-desktop-4.2.1-1.2.x86_64
I thought a kernel upgrade should automatically trigger a rebuilt of the virtualbox kernel packages.
Cheers Flavio Same goes for X11:Bumblebee:bbswitch. Building in Factory was "blocked" though I saw the no of packages blocking go down today. -- Gertjan Lettink, a.k.a. Knurpht
Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Flavio Castelli <fcastelli@suse.de>:
Hi, Virtualbox is currently broken on tumbleweed because its kernel module has not been rebuilt against the latest kernel release.
Yes, attempting to start a VM fails with: The virtual machine 'Win7 Morrison' has terminated unexpectedly during startup with exit code 1 (0x1). Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {f30138d4-e5ea-4b3a-8858-a059de4c93fd}
Right now on my machine I have the following packages: virtualbox-5.0.4-1.1.x86_64 virtualbox-host-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 virtualbox-guest-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 kernel-desktop-4.2.1-1.2.x86_64
virtualbox-5.0.4-1.1.x86_64 python-virtualbox-5.0.4-1.1.x86_64 virtualbox-guest-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 virtualbox-host-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 virtualbox-qt-5.0.4-1.1.x86_64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
____________________________________ From: Adam Tauno Williams [awilliam@whitemice.org] Sent: Friday, October 09, 2015 2:38 PM To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Virtualbox broken on tumbleweed
Yes, attempting to start a VM fails with:
The virtual machine 'Win7 Morrison' has terminated unexpectedly during startup with exit code 1 (0x1). Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {f30138d4-e5ea-4b3a-8858-a059de4c93fd}
I saw this on Leap as well. I think the problem is that the install does not enable the kernel drivers. I rebooted the machine and then it worked fine (happily running a 32-bit client in the 64-bit host!). I guess I could also have found how it is enabled and not really have to reboot. But I did so anyway. So for Leap at least it was not a problem with the drivers themselves. Roger Oberholtzer RST Systems Office: +46 (0)10-615 6020 Mobile: +46 (0)70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/09/2015 07:38 AM, Adam Tauno Williams wrote:
Yes, attempting to start a VM fails with:
The virtual machine 'Win7 Morrison' has terminated unexpectedly during startup with exit code 1 (0x1). Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {f30138d4-e5ea-4b3a-8858-a059de4c93fd}
virtualbox-5.0.4-1.1.x86_64 python-virtualbox-5.0.4-1.1.x86_64 virtualbox-guest-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 virtualbox-host-kmp-desktop-5.0.4_k4.1.6_3-1.1.x86_64 virtualbox-qt-5.0.4-1.1.x86_64
Apparently, there are many possible reasons for this error, but the most common is that the kernel modules that are installed do not match the running kernel. Please post the output of 'uname -r' so that we know which kernel you are using. As noted in earlier messages today, the problems with the build of virtualbox in Tumbleweed have been fixed. Unfortunately, that new version cannot be released as there are now problems with booting that have nothing to do with booting. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-09 16:57, Larry Finger wrote:
As noted in earlier messages today, the problems with the build of virtualbox in Tumbleweed have been fixed. Unfortunately, that new version cannot be released as there are now problems with booting that have nothing to do with booting.
Use the update repo :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYX8MQACgkQja8UbcUWM1xYewD/QSv4Lf5RU2z/0p9Pmh0XibDM +OWGIxbFEyzIkiFc8ZsA/28tPO+9fkHD1QOIjf9kt3MGjxh+yU8YCpd/6KUhT7wH =3ksi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/09/2015 12:52 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-10-09 16:57, Larry Finger wrote:
As noted in earlier messages today, the problems with the build of virtualbox in Tumbleweed have been fixed. Unfortunately, that new version cannot be released as there are now problems with booting that have nothing to do with booting.
Use the update repo :-)
Yeppers, one of those rare instances for the update repo in TW. -- Ken Schneider -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9 October 2015 at 20:09, Ken Schneider - Factory <suse-list3@bout-tyme.net> wrote:
On 10/09/2015 12:52 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-10-09 16:57, Larry Finger wrote:
As noted in earlier messages today, the problems with the build of virtualbox in Tumbleweed have been fixed. Unfortunately, that new version cannot be released as there are now problems with booting that have nothing to do with booting.
Use the update repo :-)
Yeppers, one of those rare instances for the update repo in TW.
Personally, I'd much rather see people use this as an opportunity to move to a more 'proper' desktop virtualisation option, like KVM + virt-manager or KVM + GNOME boxes Virtualbox is a flaky pile of _____ which under security has a policy with it's security updates that's so untransparent it makes me very nervous Sure, on Windows, it's the only viable FOSS desktop virtualisation option, so we can't ignore it entirely, but on Linux, we have a much better option with KVM, I really think people should use it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9 October 2015 at 21:09, Richard Brown <RBrownCCB@opensuse.org> wrote:
Virtualbox is a flaky pile of _____ which under security has a policy with it's security updates that's so untransparent it makes me very nervous
Should really proof read stuff before sending.. What I meant to say was.. Virtualbox is a flaky pile of _____ with a security policy that lacking any transparency - it makes me very nervous that stuff could be going on under the radar, which is not a level of risk I want to take with my hypervisors -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi all, First of all, I want to say that I do appreciate the work people put into Tumbleweed and I do not want to be too negative. However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner. Many people use Virtualbox and this package has been missing for more than a week now. I know you can just use the previous kernel to have it working, but fixing this sooner or, even better, preventing the release of the kernel when important kernel modules do not build properly would be nice in my opinion. So please consider this as a question and in a constructive way as I really like Tumbleweed. Kind regards, Erwin On Fri, Oct 9, 2015 at 9:12 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 9 October 2015 at 21:09, Richard Brown <RBrownCCB@opensuse.org> wrote:
Virtualbox is a flaky pile of _____ which under security has a policy with it's security updates that's so untransparent it makes me very nervous
Should really proof read stuff before sending..
What I meant to say was.. Virtualbox is a flaky pile of _____ with a security policy that lacking any transparency - it makes me very nervous that stuff could be going on under the radar, which is not a level of risk I want to take with my hypervisors -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Erwin, If you want to make sure that virtualbox is considered in the release criteria for Tumbleweed, then you need to make sure it's tested in openQA You (or someone else) will need to write a test (or a series of tests) to install, configure and run virtualbox https://github.com/os-autoinst/openQA/blob/master/docs/WritingTests.asciidoc Then submit it to the opensuse openQA test repository https://github.com/os-autoinst/os-autoinst-distri-opensuse You'll need to modify the 'main.pm' to execute those new tests in the appropriate time (probably part of the load_x11tests subroutine) And of course, your biggest challenge will be either figuring out how to get virtualbox inside KVM (our default platform for testing in openQA), or resurrecting and refining the old openQA virtualbox backend to match the feature set of the qemu one ( https://github.com/os-autoinst/os-autoinst/blob/master/backend/vbox.pm ) or donating supermicro server hardware to openSUSE so we can use that as a 'real hardware' test using our IPMI backend or, you could reconsider your use of virtualbox and consider using KVM/GNOME Boxes/virt-manager instead With well documented issues such as http://www.theregister.co.uk/2015/09/15/oracle_virtualbox_security_updates/ and considering the fundamental fact that something in the kernel is infinitely less likely to break than some module, you really need a compelling reason to convince me that Virtualbox is a better choice for desktop virtualisation, and so far your reasoning that 'it should be treated as critical' does not sway my opinion in the face of the facts as I see them. I don't think it's critical, and I don't see why we should treat it as critical when we have alternatives that have the same features that we do treat as critical and are easier for us to support, more reliable for our users, and with an upstream who doesn't hide their security processes.. Of course..what I want doesn't matter if other people do the work to make something else happen, hence all those juicy links above, pick your path and have a lot of fun :) On 10 October 2015 at 14:41, Erwin Van de Velde <erwin.vandevelde@gmail.com> wrote:
Hi all,
First of all, I want to say that I do appreciate the work people put into Tumbleweed and I do not want to be too negative.
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner. Many people use Virtualbox and this package has been missing for more than a week now. I know you can just use the previous kernel to have it working, but fixing this sooner or, even better, preventing the release of the kernel when important kernel modules do not build properly would be nice in my opinion.
So please consider this as a question and in a constructive way as I really like Tumbleweed.
Kind regards, Erwin
On Fri, Oct 9, 2015 at 9:12 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 9 October 2015 at 21:09, Richard Brown <RBrownCCB@opensuse.org> wrote:
Virtualbox is a flaky pile of _____ which under security has a policy with it's security updates that's so untransparent it makes me very nervous
Should really proof read stuff before sending..
What I meant to say was.. Virtualbox is a flaky pile of _____ with a security policy that lacking any transparency - it makes me very nervous that stuff could be going on under the radar, which is not a level of risk I want to take with my hypervisors -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
resurrecting and refining the old openQA virtualbox backend to match the feature set of the qemu one ( https://github.com/os-autoinst/os-autoinst/blob/master/backend/vbox.pm )
Actually, scratch that, the vbox backend would be useless in this case, the only options for testing this kind of failure condition would be seeing if we can run vbox nested in KVM or on real hardware -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zaterdag 10 oktober 2015 16:07:29 schreef Richard Brown:
Erwin,
Richard, it's not just Virtualbox. Found out on thursday that the same goes for bbswitch ( and probably other kmp's ). The latest TW released snapshot has kernel 4.2.1, bbswitch-kmp-$KERNEL_FLAVOR is built against 4.1.6 A post re. Virtualbox by Dimstar hinted me to give osc a go, and I managed to get the kmp built on my laptop, but that's not the way every new TW user ( or one that wants a clean install ) should have to use IMHO. Shouldn't there be a mechanism that at least waits for the kmp's to be of the same version as the included kernel before a snapshot is released. Admit I'm not deep enough into the technical aspects of this re. openQA. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi all, Thank you for the interesting replies. The reason I see it as critical is that Virtualbox is still a very popular way to do virtualization and e.g. vagrant builds by default Virtualbox VMs. I have experience with KVM as well, but since I rely heavily on vagrant for some of my work and the libvirt plugin is not installed by default, i stuck to Virtualbox. I will try the libvirt plugin I think :) I am not familiar with OpenQA but can have a look. Is there no easier way for this issue? It should not really involve testing as it is more a dependency issue: TW should not push a kernel update as long as KMP packages are not ready. As mentioned by Gertjan, there are other KMP modules missing too, which can have a more severe impact on a user's system. It is all very interesting and I will certainly have a look, but on some occasions I also just want to be a user, there is already so much work to do, as is the case for all of us of course :) Kind regards, Erwin On Sat, Oct 10, 2015 at 4:24 PM, Knurpht - Gertjan Lettink <knurpht@opensuse.org> wrote:
Op zaterdag 10 oktober 2015 16:07:29 schreef Richard Brown:
Erwin,
Richard,
it's not just Virtualbox. Found out on thursday that the same goes for bbswitch ( and probably other kmp's ). The latest TW released snapshot has kernel 4.2.1, bbswitch-kmp-$KERNEL_FLAVOR is built against 4.1.6 A post re. Virtualbox by Dimstar hinted me to give osc a go, and I managed to get the kmp built on my laptop, but that's not the way every new TW user ( or one that wants a clean install ) should have to use IMHO.
Shouldn't there be a mechanism that at least waits for the kmp's to be of the same version as the included kernel before a snapshot is released. Admit I'm not deep enough into the technical aspects of this re. openQA. -- Gertjan Lettink, a.k.a. Knurpht
Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 10 Oct 2015, Erwin Van de Velde wrote:
with KVM as well, but since I rely heavily on vagrant for some of my work and the libvirt plugin is not installed by default, i stuck to Virtualbox. I will try the libvirt plugin I think :)
I run Vagrant with libvirt plugin on openSUSE 13.2 and it works fine :-) -- Francisco Javier Tsao Santín http://gattaca.es 1024D/71CF4D62 42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB
@Fransisco: Great to know, perhaps you can help me out :) I was just testing and get following error: "The box you're attempting to add doesn't support the provider" I am just using the Hashicorp Debian Jessie box (work-related choice of disro ;) ). There seem to be very few boxes prepared for libvirt :( Is there a way round this issue? Kind regards, Erwin On Sat, Oct 10, 2015 at 5:04 PM, Francisco J. Tsao Santin <tsao@gpul.org> wrote:
On Sat, 10 Oct 2015, Erwin Van de Velde wrote:
with KVM as well, but since I rely heavily on vagrant for some of my work and the libvirt plugin is not installed by default, i stuck to Virtualbox. I will try the libvirt plugin I think :)
I run Vagrant with libvirt plugin on openSUSE 13.2 and it works fine :-)
-- Francisco Javier Tsao Santín http://gattaca.es 1024D/71CF4D62 42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 10 Oct 2015, Erwin Van de Velde wrote:
@Fransisco: Great to know, perhaps you can help me out :) I was just testing and get following error: "The box you're attempting to add doesn't support the provider"
I am just using the Hashicorp Debian Jessie box (work-related choice of disro ;) ). There seem to be very few boxes prepared for libvirt :( Is there a way round this issue?
Check if you are trying to run the box with the --provider=libvirt (maybe you are getting the default Virtualbox provider...) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.10.2015 um 16:40 schrieb Erwin Van de Velde:
As mentioned by Gertjan, there are other KMP modules missing too, which can have a more severe impact on a user's system.
Well. Out of tree kernel modules are often a PITA. And the kernel hackers seem to somtimes make them a PITA on purpose. People / projects should 'just' get their modules upstream, then no KMPs are necessary. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Samstag, 10. Oktober 2015 schrieb Knurpht - Gertjan Lettink:
Shouldn't there be a mechanism that at least waits for the kmp's to be of the same version as the included kernel before a snapshot is released. Admit I'm not deep enough into the technical aspects of this re. openQA.
I don't know too much about openQA, but this sounds like the test should - zypper in all the kmp packages we want to have always installable - rpm -qa --qf '%{name}\n' '*-kmp*' | sort - check the output of the rpm command In theory we could also check the zypper in output, but that's harder because it often changes (hint: version numbers). Also, zypper might not always install the packages in the same order. Therefore I recommend the rpm output without version numbers and sorted. Implementing that as test should be quite easy for someone who knows openQA better than I do ;-) Regards, Christian Boltz -- [00:02:39] <kshitij8_> welcome, Happy New Year! :-) [00:05:00] * cboltz leaves to run systemctl start fireworks ;-) [00:09:30] <darix> should i tell him i ran systemctl disable lighter [00:34:35] <kshitij8_> systemctl start rain ;-) [from #apparmor, Jan 1 2015] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.10.2015 um 23:18 schrieb Christian Boltz:
Hello,
Am Samstag, 10. Oktober 2015 schrieb Knurpht - Gertjan Lettink:
Shouldn't there be a mechanism that at least waits for the kmp's to be of the same version as the included kernel before a snapshot is released. Admit I'm not deep enough into the technical aspects of this re. openQA.
I don't know too much about openQA, but this sounds like the test should - zypper in all the kmp packages we want to have always installable - rpm -qa --qf '%{name}\n' '*-kmp*' | sort - check the output of the rpm command
In theory we could also check the zypper in output, but that's harder because it often changes (hint: version numbers). Also, zypper might not always install the packages in the same order. Therefore I recommend the rpm output without version numbers and sorted.
Implementing that as test should be quite easy for someone who knows openQA better than I do ;-)
You only want to check that it's installable, no? Then just check the exit code of zypper. Here is the deal: you write a script in your preferred language that will exit 1 if the test failed and 0 if the kmps are fine (the script can be as verbose as you want to). And I will run that script as part of TW snapshot tests. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Sonntag, 11. Oktober 2015 schrieb Stephan Kulow:
Here is the deal: you write a script in your preferred language that will exit 1 if the test failed and 0 if the kmps are fine (the script can be as verbose as you want to). And I will run that script as part of TW snapshot tests.
OK, here we go: [1] cat install-kmp.sh #!/bin/bash # ensure kmp packages can be installed. # adjust $kernel_flavors and $kmps to add more tests. # kernel flavors to test kernel_flavors="default desktop" for kf in $kernel_flavors ; do # kmp packages to test (for each kernel flavour) kmps="virtualbox-guest-kmp-$kf virtualbox-host-kmp-$kf" # we only want to ensure that the kmp packages are installable, # so --dry-run is enough (and faster) zypper in --dry-run -y $kmps || exit 1 done Let's see if this script can make some VirtualBox users happy ;-) Needless to say that it's easy to add more kernel flavors and kmp packages - but I'll leave that to someone who complains about missing test coverage for one of them ;-) BTW: Is your deal available for another script? I'd like to add some AppArmor testing ;-) Regards, Christian Boltz [1] says someone who didn't use VirtualBox for years ;-) - so feel free to adjust the script as needed -- Graphisch??? Wie meinen? Hast du zuviel Fleisch von zu "gluecklichen" Rindern gefuttert? *scnr* Wozu zum Henker sollte man sowas brauchen? Logo ginge auch per ASCII :) (Logo? welches Logo? Wozu ueberhaupt?) [David Haller in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/12/2015 05:14 PM, Christian Boltz wrote:
Hello,
Am Sonntag, 11. Oktober 2015 schrieb Stephan Kulow:
Here is the deal: you write a script in your preferred language that will exit 1 if the test failed and 0 if the kmps are fine (the script can be as verbose as you want to). And I will run that script as part of TW snapshot tests.
OK, here we go: [1]
cat install-kmp.sh #!/bin/bash
# ensure kmp packages can be installed. # adjust $kernel_flavors and $kmps to add more tests.
# kernel flavors to test kernel_flavors="default desktop"
for kf in $kernel_flavors ; do # kmp packages to test (for each kernel flavour) kmps="virtualbox-guest-kmp-$kf virtualbox-host-kmp-$kf"
# we only want to ensure that the kmp packages are installable, # so --dry-run is enough (and faster) zypper in --dry-run -y $kmps || exit 1 done
Let's see if this script can make some VirtualBox users happy ;-)
Needless to say that it's easy to add more kernel flavors and kmp packages - but I'll leave that to someone who complains about missing test coverage for one of them ;-)
BTW: Is your deal available for another script? I'd like to add some AppArmor testing ;-)
Regards,
Christian Boltz
[1] says someone who didn't use VirtualBox for years ;-) - so feel free to adjust the script as needed
A good start, but not sufficient. The usual problem is not that the package is missing, but that the kmp's are built for the wrong kernel. That you will not find unless you try to modprobe vboxdrv. The problem is that it appears that neither modprobe nor insmod return a proper error code and the script is likely to need to parse the returned result to determine if the load succeeded. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
13.10.2015 04:20, Larry Finger пишет:
On 10/12/2015 05:14 PM, Christian Boltz wrote:
Hello,
Am Sonntag, 11. Oktober 2015 schrieb Stephan Kulow:
Here is the deal: you write a script in your preferred language that will exit 1 if the test failed and 0 if the kmps are fine (the script can be as verbose as you want to). And I will run that script as part of TW snapshot tests.
OK, here we go: [1]
cat install-kmp.sh #!/bin/bash
# ensure kmp packages can be installed. # adjust $kernel_flavors and $kmps to add more tests.
# kernel flavors to test kernel_flavors="default desktop"
for kf in $kernel_flavors ; do # kmp packages to test (for each kernel flavour) kmps="virtualbox-guest-kmp-$kf virtualbox-host-kmp-$kf"
# we only want to ensure that the kmp packages are installable, # so --dry-run is enough (and faster) zypper in --dry-run -y $kmps || exit 1 done
Let's see if this script can make some VirtualBox users happy ;-)
Needless to say that it's easy to add more kernel flavors and kmp packages - but I'll leave that to someone who complains about missing test coverage for one of them ;-)
BTW: Is your deal available for another script? I'd like to add some AppArmor testing ;-)
Regards,
Christian Boltz
[1] says someone who didn't use VirtualBox for years ;-) - so feel free to adjust the script as needed
A good start, but not sufficient. The usual problem is not that the package is missing, but that the kmp's are built for the wrong kernel. That you will not find unless you try to modprobe vboxdrv.
If KMP require exact kernel version N and only kernel N+1 is present installation should fail. At least for virtual box on TW I see hard Requires for exact kernel version and flavor. Test may not be sufficient on Leap where we probably want kABI ...
The problem is that it appears that neither modprobe nor insmod return a proper error code and the script is likely to need to parse the returned result to determine if the load succeeded.
Larry
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-13 00:14, Christian Boltz wrote:
Hello,
Am Sonntag, 11. Oktober 2015 schrieb Stephan Kulow:
Here is the deal: you write a script in your preferred language that will exit 1 if the test failed and 0 if the kmps are fine (the script can be as verbose as you want to). And I will run that script as part of TW snapshot tests.
OK, here we go: [1]
cat install-kmp.sh #!/bin/bash
# ensure kmp packages can be installed. # adjust $kernel_flavors and $kmps to add more tests.
# kernel flavors to test kernel_flavors="default desktop"
kernel-desktop has been dropped. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zaterdag 10 oktober 2015 14:41:48 schreef Erwin Van de Velde:
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner.
It's not just Virtualbox. Those of us having NVIDIA Optimus experience the same thing re. bbswitch. On an already running TW this IMHO should result in the system not updating the kernel, since the updates for the installed kmp packages have not been built yet. On a fresh TW install this has resulted in the issue as mentioned, I now know the same is going on for bbswitch-kmp-kernelflavour. Kernel is 4.2.1, kmp packacges are built for kernel 4.1.6, which won't work. I assume this happens for the other kmp packages as well. @Erwin: in the dutch subforums I posted about my getting around this issue using osc. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
10.10.2015 17:11, Knurpht - Gertjan Lettink пишет:
Op zaterdag 10 oktober 2015 14:41:48 schreef Erwin Van de Velde:
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner.
It's not just Virtualbox. Those of us having NVIDIA Optimus experience the same thing re. bbswitch. On an already running TW this IMHO should result in the system not updating the kernel, since the updates for the installed kmp packages have not been built yet.
Do you have any suggestion how it can be implemented? I.e. we have packages kernel-v1 kernel-v2 kernel-kmp-v1 kernel-kmp-v2 What Requires or Conflicts should be added to each package that allow - installing all packages at the same time on a system - not allowing installing kernel-v2 if kernel-kmp-v2 is missing Given that kernel package obviously can *not* list every KMP as prerequisites. I do not see how it can be expressed using package dependency. Nor RPM has any way to gracefully block installation. I think it could be implemented as trigger that runs before kernel package is installed and basically tests that for each KMP installed on system if KMP for new kernel is not available fail Small implementation details are a) how to find KMP and b) how to find KMP for new kernel. And even in this case installation of new KMP may fail or it may not function so you *must* be prepared to cope with this situation.
On a fresh TW install this has resulted in the issue as mentioned, I now know the same is going on for bbswitch-kmp-kernelflavour. Kernel is 4.2.1, kmp packacges are built for kernel 4.1.6, which won't work. I assume this happens for the other kmp packages as well.
@Erwin: in the dutch subforums I posted about my getting around this issue using osc.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Oct 10, 2015 at 05:33:40PM +0300, Andrei Borzenkov wrote:
10.10.2015 17:11, Knurpht - Gertjan Lettink пишет:
Op zaterdag 10 oktober 2015 14:41:48 schreef Erwin Van de Velde:
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner.
It's not just Virtualbox. Those of us having NVIDIA Optimus experience the same thing re. bbswitch. On an already running TW this IMHO should result in the system not updating the kernel, since the updates for the installed kmp packages have not been built yet.
Do you have any suggestion how it can be implemented?
I.e. we have packages
kernel-v1 kernel-v2 kernel-kmp-v1 kernel-kmp-v2
What Requires or Conflicts should be added to each package that allow
- installing all packages at the same time on a system - not allowing installing kernel-v2 if kernel-kmp-v2 is missing
Given that kernel package obviously can *not* list every KMP as prerequisites.
I do not see how it can be expressed using package dependency. Nor RPM has any way to gracefully block installation.
I think it could be implemented as trigger that runs before kernel package is installed and basically tests that
for each KMP installed on system if KMP for new kernel is not available fail
Small implementation details are a) how to find KMP and b) how to find KMP for new kernel.
I created stupid script which could test it naively: #!/bin/bash for i in default desktop pv pae xen; do provided_uname="$(zypper info --provides kernel-"$i" | grep kernel-uname-r)" while read pkg; do required_uname="$(zypper info --requires "$pkg" | grep kernel-uname-r)" if [ "$required_uname" != "$provided_uname" ]; then broken="${broken} $pkg" fi done < <(zypper se kmp-"$i" | grep -v debuginfo | sed '1,/^[-+]\+$/d;s@^[^|]*| \([^ ]\+\) .*@\1@') done echo "$broken" To have this working I rely on two things: 1] zypper info works with latest version of the package available 2] KMP packages contains 'kmp-$flavour' in its name (I could also search with `zypper se --requires kernel-uname-r' and ommit kernel packages) If package requires kernel-uname-r symbol, it must match provided one. Best solution would work directly with repository metadata and could be run in openQA easily. Best regards, Tomas Cech
Op zaterdag 10 oktober 2015 17:41:15 schreef Tomáš Čech:
On Sat, Oct 10, 2015 at 05:33:40PM +0300, Andrei Borzenkov wrote:
10.10.2015 17:11, Knurpht - Gertjan Lettink пишет:
Op zaterdag 10 oktober 2015 14:41:48 schreef Erwin Van de Velde:
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner.
It's not just Virtualbox. Those of us having NVIDIA Optimus experience the same thing re. bbswitch. On an already running TW this IMHO should result in the system not updating the kernel, since the updates for the installed kmp packages have not been built yet.
Do you have any suggestion how it can be implemented?
I.e. we have packages
kernel-v1 kernel-v2 kernel-kmp-v1 kernel-kmp-v2
What Requires or Conflicts should be added to each package that allow
- installing all packages at the same time on a system - not allowing installing kernel-v2 if kernel-kmp-v2 is missing
Given that kernel package obviously can *not* list every KMP as prerequisites.
I do not see how it can be expressed using package dependency. Nor RPM has any way to gracefully block installation.
I think it could be implemented as trigger that runs before kernel package is installed and basically tests that
for each KMP installed on system
if KMP for new kernel is not available
fail
Small implementation details are a) how to find KMP and b) how to find KMP for new kernel.
I created stupid script which could test it naively: #!/bin/bash
for i in default desktop pv pae xen; do provided_uname="$(zypper info --provides kernel-"$i" | grep kernel-uname-r)" while read pkg; do required_uname="$(zypper info --requires "$pkg" | grep kernel-uname-r)" if [ "$required_uname" != "$provided_uname" ]; then broken="${broken} $pkg" fi done < <(zypper se kmp-"$i" | grep -v debuginfo | sed '1,/^[-+]\+$/d;s@^[^|]*| \([^ ]\+\) .*@\1@') done
echo "$broken"
To have this working I rely on two things: 1] zypper info works with latest version of the package available
2] KMP packages contains 'kmp-$flavour' in its name (I could also search with `zypper se --requires kernel-uname-r' and ommit kernel packages)
If package requires kernel-uname-r symbol, it must match provided one.
Best solution would work directly with repository metadata and could be run in openQA easily.
Cheers. That's the reply I was hoping for. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zaterdag 10 oktober 2015 17:33:40 schreef Andrei Borzenkov:
10.10.2015 17:11, Knurpht - Gertjan Lettink пишет:
Op zaterdag 10 oktober 2015 14:41:48 schreef Erwin Van de Velde:
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner.
It's not just Virtualbox. Those of us having NVIDIA Optimus experience the same thing re. bbswitch. On an already running TW this IMHO should result in the system not updating the kernel, since the updates for the installed kmp packages have not been built yet.
Do you have any suggestion how it can be implemented?
I wish I had, but I guess I am simply lacking the knowledge. Was thinking in the depency direction but got stuck exactly the way you explain below.
I.e. we have packages
kernel-v1 kernel-v2 kernel-kmp-v1 kernel-kmp-v2
What Requires or Conflicts should be added to each package that allow
- installing all packages at the same time on a system - not allowing installing kernel-v2 if kernel-kmp-v2 is missing
Given that kernel package obviously can *not* list every KMP as prerequisites.
I do not see how it can be expressed using package dependency. Nor RPM has any way to gracefully block installation.
I think it could be implemented as trigger that runs before kernel package is installed and basically tests that
for each KMP installed on system if KMP for new kernel is not available fail
Small implementation details are a) how to find KMP and b) how to find KMP for new kernel.
And even in this case installation of new KMP may fail or it may not function so you *must* be prepared to cope with this situation.
100 % agreed.
On a fresh TW install this has resulted in the issue as mentioned, I now know the same is going on for bbswitch-kmp-kernelflavour. Kernel is 4.2.1, kmp packacges are built for kernel 4.1.6, which won't work. I assume this happens for the other kmp packages as well.
@Erwin: in the dutch subforums I posted about my getting around this issue using osc.
-- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 10 Oct 2015 14:41:48 +0200, Erwin Van de Velde wrote:
Hi all,
First of all, I want to say that I do appreciate the work people put into Tumbleweed and I do not want to be too negative.
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner. Many people use Virtualbox and this package has been missing for more than a week now. I know you can just use the previous kernel to have it working, but fixing this sooner or, even better, preventing the release of the kernel when important kernel modules do not build properly would be nice in my opinion.
So please consider this as a question and in a constructive way as I really like Tumbleweed.
It's an interesting question whether we can catch a virtualbox issue on openQA. Does the nested VM work? For a KMP build problem, it's easy to see, though. We can set up an OBS project (e.g. Kernel:stable:KMP) building only KMPs based on the latest Kernel:stable. We have already something similar for SLE, and this has helped to catch build issues beforehand. Takashi
Kind regards, Erwin
On Fri, Oct 9, 2015 at 9:12 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 9 October 2015 at 21:09, Richard Brown <RBrownCCB@opensuse.org> wrote:
Virtualbox is a flaky pile of _____ which under security has a policy with it's security updates that's so untransparent it makes me very nervous
Should really proof read stuff before sending..
What I meant to say was.. Virtualbox is a flaky pile of _____ with a security policy that lacking any transparency - it makes me very nervous that stuff could be going on under the radar, which is not a level of risk I want to take with my hypervisors -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.10.2015 um 16:12 schrieb Takashi Iwai:
For a KMP build problem, it's easy to see, though. We can set up an OBS project (e.g. Kernel:stable:KMP) building only KMPs based on the latest Kernel:stable. We have already something similar for SLE, and this has helped to catch build issues beforehand.
That would really helpful (if Kernel devs actually check that project too, but usually the bot submits the new kernel and that one doesn't care). But in this case VB and bbswitch were actually broken (indirectly) by the new systemd submission that ended up in Factory at the same time and the real problem is - as already highlighted elsewhere - the missing coverage for these use cases in our openQA testing. And I'm not exactly sure we want to cover *everything* - otherwise we will spend 2 days testing to publish and snapshot and that can't be the goal either. So having some gaps in TW that require workarounds - like installing VB from devel project - are fine IMO. We should cover what most people do - and I'm not so sure using VB is one of that. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 11 Oct 2015 10:49:48 +0200, Stephan Kulow wrote:
Am 10.10.2015 um 16:12 schrieb Takashi Iwai:
For a KMP build problem, it's easy to see, though. We can set up an OBS project (e.g. Kernel:stable:KMP) building only KMPs based on the latest Kernel:stable. We have already something similar for SLE, and this has helped to catch build issues beforehand.
That would really helpful
The setup should be trivial. Michal?
(if Kernel devs actually check that project too, but usually the bot submits the new kernel and that one doesn't care).
Well, actually it's more package maintainers who need to work on the breakage by the upstream kernel update. The kernel devs are willing to help, of course, though.
But in this case VB and bbswitch were actually broken (indirectly) by the new systemd submission that ended up in Factory at the same time and the real problem is - as already highlighted elsewhere - the missing coverage for these use cases in our openQA testing. And I'm not exactly sure we want to cover *everything* - otherwise we will spend 2 days testing to publish and snapshot and that can't be the goal either.
Right. Constantly delaying even more than now is really bad for users, too.
So having some gaps in TW that require workarounds - like installing VB from devel project - are fine IMO. We should cover what most people do - and I'm not so sure using VB is one of that.
I wonder whether we may have more lightweight test coverage for some cases. openQA is really great, but it's mostly lifting up the whole heavy system. The kernel team is trying to look for a CI testing, and a similar method might be used for KMPs, too, I suppose; at least loading a module would work in most cases even though it's actually not used. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 11.10.2015 um 18:36 schrieb Takashi Iwai:
On Sun, 11 Oct 2015 10:49:48 +0200, Stephan Kulow wrote:
Am 10.10.2015 um 16:12 schrieb Takashi Iwai:
For a KMP build problem, it's easy to see, though. We can set up an OBS project (e.g. Kernel:stable:KMP) building only KMPs based on the latest Kernel:stable. We have already something similar for SLE, and this has helped to catch build issues beforehand.
That would really helpful
The setup should be trivial. Michal?
(if Kernel devs actually check that project too, but usually the bot submits the new kernel and that one doesn't care).
Well, actually it's more package maintainers who need to work on the breakage by the upstream kernel update. The kernel devs are willing to help, of course, though.
Well, someone would have to actually watch for failures in that project before submitting a new kernel and alert the KMP packagers instead. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 12 Oct 2015 08:13:44 +0200, Stephan Kulow wrote:
Am 11.10.2015 um 18:36 schrieb Takashi Iwai:
On Sun, 11 Oct 2015 10:49:48 +0200, Stephan Kulow wrote:
Am 10.10.2015 um 16:12 schrieb Takashi Iwai:
For a KMP build problem, it's easy to see, though. We can set up an OBS project (e.g. Kernel:stable:KMP) building only KMPs based on the latest Kernel:stable. We have already something similar for SLE, and this has helped to catch build issues beforehand.
That would really helpful
The setup should be trivial. Michal?
(if Kernel devs actually check that project too, but usually the bot submits the new kernel and that one doesn't care).
Well, actually it's more package maintainers who need to work on the breakage by the upstream kernel update. The kernel devs are willing to help, of course, though.
Well, someone would have to actually watch for failures in that project before submitting a new kernel and alert the KMP packagers instead.
Yeah, we should check the build status before the kernel submission. Besides that, each KMP maintainer can receive a build failure via hermes, right? Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-11 18:36, Takashi Iwai wrote:
On Sun, 11 Oct 2015 10:49:48 +0200, Stephan Kulow wrote:
Am 10.10.2015 um 16:12 schrieb Takashi Iwai:
For a KMP build problem, it's easy to see, though. We can set up an OBS project (e.g. Kernel:stable:KMP) building only KMPs based on the latest Kernel:stable. We have already something similar for SLE, and this has helped to catch build issues beforehand.
That would really helpful
The setup should be trivial. Michal?
Yes, this is a good idea, I will add it.
(if Kernel devs actually check that project too, but usually the bot submits the new kernel and that one doesn't care).
Well, actually it's more package maintainers who need to work on the breakage by the upstream kernel update. The kernel devs are willing to help, of course, though.
Exactly. What I do for SLE is that I'm watching the *:KMP projects and notifying package maintainers about genuine failures (unfortunately, most failures are due to the build service building with incompatible versions of kernel packages).
The kernel team is trying to look for a CI testing, and a similar method might be used for KMPs, too, I suppose; at least loading a module would work in most cases even though it's actually not used.
This should work. At least for modules that are known not to legitimately fail to load with -ENODEV or something. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2015-10-10 at 14:41 +0200, Erwin Van de Velde wrote:
Hi all,
First of all, I want to say that I do appreciate the work people put into Tumbleweed and I do not want to be too negative.
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner. Many people use Virtualbox and this package has been missing for more than a week now. I know you can just use the previous kernel to have it working, but fixing this sooner or, even better, preventing the release of the kernel when important kernel modules do not build properly would be nice in my opinion.
Virtualbox has been published at http://download.opensuse.org/repositories/openSUSE:/Factory:/Update/sta ndard/ This should hopefully end this long thread :) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-10-13 at 11:44 +0200, Dominique Leuenberger / DimStar wrote:
On Sat, 2015-10-10 at 14:41 +0200, Erwin Van de Velde wrote:
Hi all,
First of all, I want to say that I do appreciate the work people put into Tumbleweed and I do not want to be too negative.
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner. Many people use Virtualbox and this package has been missing for more than a week now. I know you can just use the previous kernel to have it working, but fixing this sooner or, even better, preventing the release of the kernel when important kernel modules do not build properly would be nice in my opinion.
Virtualbox has been published at http://download.opensuse.org/repositories/openSUSE:/Factory:/Update/s ta ndard/
This should hopefully end this long thread
by the way: guys, when you run zypper dup and it tells you that it's going to uninstall packages you care for (as it very likely had to do in this case): why exactly do you do it then without thinking about the consequences? Just a thuoght: might be worthy to actually read the output of zypper dup before pressing 'y' to do it. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Dominique, We did not uninstall the package, it just stopped working when booting the new kernel. Booting with the old kernel still worked fine :) I always read the changes, but sometimes there are so many and you just overlook the fact that something like a KMP package is missing even though a new kernel will be installed. Kind regards, Erwin On Tue, Oct 13, 2015 at 11:58 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Tue, 2015-10-13 at 11:44 +0200, Dominique Leuenberger / DimStar wrote:
On Sat, 2015-10-10 at 14:41 +0200, Erwin Van de Velde wrote:
Hi all,
First of all, I want to say that I do appreciate the work people put into Tumbleweed and I do not want to be too negative.
However :-) I would like to see missing packages like the kermel modules preventing Virtualbox from working properly to be treated as a bit more critical and updated sooner. Many people use Virtualbox and this package has been missing for more than a week now. I know you can just use the previous kernel to have it working, but fixing this sooner or, even better, preventing the release of the kernel when important kernel modules do not build properly would be nice in my opinion.
Virtualbox has been published at http://download.opensuse.org/repositories/openSUSE:/Factory:/Update/s ta ndard/
This should hopefully end this long thread
by the way: guys, when you run zypper dup and it tells you that it's going to uninstall packages you care for (as it very likely had to do in this case): why exactly do you do it then without thinking about the consequences?
Just a thuoght: might be worthy to actually read the output of zypper dup before pressing 'y' to do it.
Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue 13 Oct 2015 01:32:43 PM CDT, Erwin Van de Velde wrote:
We did not uninstall the package, it just stopped working when booting the new kernel. Booting with the old kernel still worked fine :) I always read the changes, but sometimes there are so many and you just overlook the fact that something like a KMP package is missing even though a new kernel will be installed.
Kind regards, Erwin
Hi I always do a zypper dup and a zypper up and check the output, then decide the best way to go.... -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 | GNOME 3.10.1 | 3.12.44-52.18-default up 7 days 21:49, 5 users, load average: 0.19, 0.18, 0.21 CPU Intel® Core i3-3227U CPU @ 1.90GHz | GPU Intel® HD Graphics 4000 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-13 11:58, Dominique Leuenberger / DimStar wrote:
by the way: guys, when you run zypper dup and it tells you that it's going to uninstall packages you care for (as it very likely had to do in this case): why exactly do you do it then without thinking about the consequences?
Just a thuoght: might be worthy to actually read the output of zypper dup before pressing 'y' to do it.
It is quite difficult to understand that output. It is very large. It is possible that several (many?) packages are removed, and in another paragraph they are also installed. It is not easy to understand the real meaning of that output. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYdOE4ACgkQtTMYHG2NR9UQSQCeImyhI2IdIt4tF8XxjJEU1WJo e/gAn3w95UxYiDzT56vujkCM/9lZskEs =g5Vg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (20)
-
Adam Tauno Williams -
Andrei Borzenkov -
Carlos E. R. -
Carlos E. R. -
Christian Boltz -
Dominique Leuenberger / DimStar -
Erwin Van de Velde -
Flavio Castelli -
Francisco J. Tsao Santin -
Ken Schneider - Factory -
Knurpht - Gertjan Lettink -
Larry Finger -
Malcolm -
Michal Marek -
Richard Brown -
Roger Oberholtzer -
Stefan Seyfried -
Stephan Kulow -
Takashi Iwai -
Tomáš Čech