____________________________________ 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

-----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 9 October 2015 at 20:09, Ken Schneider - Factory 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

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 wrote:

On 9 October 2015 at 21:09, Richard Brown 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

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 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

@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 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

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

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

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

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

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

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

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 wrote:

...

On 9 October 2015 at 21:09, Richard Brown 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

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

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 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

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 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

-----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