Bug #12081

Fresh vagrant-libvirt setup has broken synced folders

Added by intrigeri 2016-12-25 12:54:31 . Updated 2017-01-24 20:43:00 .

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

100%

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

Starter:
Affected tool:
Deliverable for:

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?

Subtasks

Related issues

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

History

#1 Updated by intrigeri 2016-12-25 13:02:42

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

#2 Updated by intrigeri 2016-12-28 08:43:19

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

#3 Updated by intrigeri 2016-12-28 08:43:32

  • related to Bug #11411: The build system should tell what filesystem permissions must be granted to the libvirt-qemu user added

#4 Updated by anonym 2017-01-05 13:25:06

  • 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 2017-01-05 14:40:21

> 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 2017-01-05 22:02:27

  • 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 2017-01-07 09:07:02

  • 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 2017-01-10 14:47:49

  • 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 (commit: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 2017-01-11 08:21:05

  • % 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 (commit: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 2017-01-11 12:14:04

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

Applied in changeset commit:e6af82a86d9a90611a31b9d97b8d630e5e14e8e1.

#11 Updated by intrigeri 2017-01-11 12:22:39

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

#12 Updated by anonym 2017-01-24 20:43:00

  • Status changed from Fix committed to Resolved