Project

General

Profile

Bug #12081

Fresh vagrant-libvirt setup has broken synced folders

Added by intrigeri almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
Build system
Target version:
Start date:
12/25/2016
Due date:
% Done:

100%

Feature Branch:
bugfix/12081-vagrant-basebox-20170105
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

I've (mistakenly) re-created my build VM from the basebox, and mounting the synced folders fails with "mount: special device XXX does not exist". Alan is experiencing the same problem since a few days (not sure if he re-created his build VM, but at least his build system did work until a few days ago).

I've "solved" this problem by running apt -t jessie-backports install linux-image-amd64 inside the build VM.

anonym, can you reproduce this? How about just using the backports kernel in the VM?


Related issues

Related to Tails - Feature #6224: Reproduce the 9p reload bug with a recent kernel Resolved 08/08/2013 07/15/2015
Related to Tails - Bug #11411: Vagrant build doc should tell what filesystem permissions must be granted to the libvirt-qemu user Confirmed 05/11/2016

Associated revisions

Revision ae1629ec (diff)
Added by anonym almost 3 years ago

Install the backported kernel in the Vagrant basebox.

The kernel version gap between stable and unstable/testing is at the
moment so big that it seems virtio devices won't work in the guest,
breaking disks, network and filesystem shares.

Will-fix: #12081

Revision 9742aa53 (diff)
Added by anonym almost 3 years ago

Upgrade the Vagrant basebox to 20170105.

Refs: #12081

Revision e6af82a8
Added by intrigeri almost 3 years ago

Merge remote-tracking branch 'origin/bugfix/12081-vagrant-basebox-20170105' into devel

Fix-committed: #12081

History

#1 Updated by intrigeri almost 3 years ago

  • Related to Feature #6224: Reproduce the 9p reload bug with a recent kernel added

#2 Updated by intrigeri almost 3 years ago

Perhaps the same trick as you did on #5571 could work here too? Or using vagrant-sshfs?

#3 Updated by intrigeri almost 3 years ago

  • Related to Bug #11411: Vagrant build doc should tell what filesystem permissions must be granted to the libvirt-qemu user added

#4 Updated by anonym almost 3 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • QA Check set to Dev Needed

Both me and spriver had even worse issues when trying to bootstrap on Debian Sid: the VM does not boot unless you switch the disk's bus from VirtIO to SATA. And then there's no network unless you switch it from VirtIO to e.g. pcnet. Upgrading to the backported kernel then solved both these issues (and presumably the shared folder issue too, which we didn't even reach). So I guess VirtIO is broken with some combination of host kernel vs guest kernel, and IIRC this has happened before (then possibly with the automated test suite).

So, installing the backported kernel solves the issue, so I'll start preparing a new basebox.

In fact, to better support stable and testing/unstable I suggest we always try to keep the "kernel gap" small by using the stable-backports kernel in the builder VM, and require the same kernel on the host if on stable. Thoughts?

#5 Updated by intrigeri almost 3 years ago

So, installing the backported kernel solves the issue, so I'll start preparing a new basebox.

Sounds great, thanks!

In fact, to better support stable and testing/unstable I suggest we always try to keep the "kernel gap" small by using the stable-backports kernel in the builder VM, and require the same kernel on the host if on stable. Thoughts?

ACK

#6 Updated by anonym almost 3 years ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 10 to 50
  • QA Check changed from Dev Needed to Ready for QA
  • Feature Branch set to bugfix/12081-vagrant-basebox-20170105

Works on my Debian Sid system. It'd be nice to have it tested on Debian Jessie running on bare metal. At the moment I cannot easily try that myself. Can you, intrigeri?

#7 Updated by intrigeri almost 3 years ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Ready for QA to Info Needed

Works on my Debian Sid system. It'd be nice to have it tested on Debian Jessie running on bare metal. At the moment I cannot easily try that myself. Can you, intrigeri?

I can't, sorry.

Now, I have one question: was the "I guess VirtIO is broken with some combination of host kernel vs guest kernel" hypothesis supported by experimental results, i.e. was there any case when upgrading the host kernel fixed a problem? Thinking about it again today, I'm less than convinced: AFAIK VirtIO has little (if anything) to do with the host kernel, as it's handled by QEMU. So my current best guess is that the breakage is rather caused by a new QEMU on the sid host, that uses a version of the VirtIO protocol that's not compatible with Linux 3.16's VirtIO guest kernel modules.

#8 Updated by anonym almost 3 years ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Info Needed to Ready for QA

What you say makes sense, but I'd rather not block on that investigation (in fact, I do not want to spend time investigating this at all). If you agree, let's just revert the suggestion to use the backported kernel (fd8c22374e8e6263c84511680a2f45ff2ab48bde) and merge. Ok?

That said, I guess it could be the QEMU upgrade from 1:2.7+dfsg-3+b1 to 1:2.8+dfsg-1 that caused mine and spriver's issues, but it was uploaded on 2016-12-28 after you reported the bug, so at least your problem was caused by something else.

#9 Updated by intrigeri almost 3 years ago

  • % Done changed from 50 to 60

anonym wrote:

What you say makes sense, but I'd rather not block on that investigation (in fact, I do not want to spend time investigating this at all). If you agree, let's just revert the suggestion to use the backported kernel (fd8c22374e8e6263c84511680a2f45ff2ab48bde) and merge. Ok?

Fully agreed, it's not worth spending more time on it. I'll do that.

Other than that: code review passes, testing.

#10 Updated by intrigeri almost 3 years ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 60 to 100

#11 Updated by intrigeri almost 3 years ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#12 Updated by anonym almost 3 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF