Bug #11965

Tails 2.7 won't start in Virtual Box

Added by jzakiya 2016-11-19 15:39:19 . Updated 2016-12-14 20:10:51 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Virtualization
Target version:
Start date:
2016-11-19
Due date:
% Done:

100%

Feature Branch:
bugfix/11965-virtualbox-5.1.8
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Tails 2.7 won’t start in Virtual Box (5.1.8) on Linux 64-bit host.
Tails 2.6, 2.5, … etc have no problems starting up.
Tails 3.0 alpha starts up correctly too.

All using the iso files downloaded off of site verified by
Firefox download plugin.


Subtasks


Related issues

Related to Tails - Bug #11992: Tails 2.7 is missing 64-bit VirtualBox kernel modules Rejected 2016-11-22
Related to Tails - Bug #11848: Clarify that VirtualBox guest utilities only work in 32-bit virtual machines Rejected 2016-09-28
Related to Tails - Bug #12001: Document that Tails requires I/O APIC being enabled in the VirtualBox VM config Resolved 2016-11-27

History

#1 Updated by obfusk 2016-11-22 22:26:41

I had the same problem. I turned on “Enable I/O APIC” in virtualbox’s motherboard settings; now it starts and seems fine.

#2 Updated by obfusk 2016-11-23 00:40:51

Except that shared folders don’t seem to work (see Bug #11992).

#3 Updated by elouann 2016-11-23 09:38:42

  • Status changed from New to Confirmed

#4 Updated by elouann 2016-11-24 12:04:29

Another user reported:

“I was able to get 2.7 to boot to work switching the virtual machine to 64 bit. I believe by default that also sets Enable I/O APIC.”, but the documentation says to use 32bits:
https://tails.boum.org/doc/advanced_topics/virtualization/virtualbox/

#5 Updated by elouann 2016-11-25 12:01:43

Another user reported:

After starting Tails, Systemd tries to load jobs but nothing happens
Adding ‘modprobe.blacklist=vboxvideo’ or ‘nomodeset’ solved my issue

#6 Updated by intrigeri 2016-11-27 16:59:54

  • Assignee set to elouann
  • QA Check set to Info Needed

> After starting Tails, Systemd tries to load jobs but nothing happens Adding ‘modprobe.blacklist=vboxvideo’ or ‘nomodeset’ solved my issue

Is that with a 64-bit VM with I/O APIC enabled? If not, let’s not bother as it seems that this is the only configuration we support nowadays.

#7 Updated by intrigeri 2016-11-27 17:00:45

  • Category set to Virtualization
  • Priority changed from Normal to Elevated
  • Type of work changed from Test to Research

(Regression)

#8 Updated by intrigeri 2016-11-27 17:01:39

  • related to Bug #11992: Tails 2.7 is missing 64-bit VirtualBox kernel modules added

#9 Updated by intrigeri 2016-11-27 17:12:21

intrigeri wrote:
> > After starting Tails, Systemd tries to load jobs but nothing happens Adding ‘modprobe.blacklist=vboxvideo’ or ‘nomodeset’ solved my issue
>
> Is that with a 64-bit VM with I/O APIC enabled? If not, let’s not bother as it seems that this is the only configuration we support nowadays.

I think I was wrong, and the best supported config for Tails 2.x should be a 32-bit VM with I/O APIC enabled. So my question becomes: was this a 32-bit or 64-bit VM? Was I/O APIC enabled?

#10 Updated by intrigeri 2016-11-27 17:14:16

  • related to Bug #11848: Clarify that VirtualBox guest utilities only work in 32-bit virtual machines added

#11 Updated by intrigeri 2016-11-27 17:19:47

  • related to Bug #12001: Document that Tails requires I/O APIC being enabled in the VirtualBox VM config added

#12 Updated by intrigeri 2016-11-27 17:23:36

Documenting the need for I/O APIC is now tracked on Bug #12001. If that’s not enough, then I need to be told what else is broken exactly, so this ticket remains “info needed” for now.

Upgrading (in a running Tails) virtualbox-guest-utils might help in some cases; in a root terminal, run: apt update && apt install virtualbox-guest-utils/jessie-backports && systemctl restart virtualbox-guest-utils. But of course this only works if the VM booted far enough.

#13 Updated by obfusk 2016-12-01 07:40:25

My second attempt at a report on problems w/ tails 2.7 and virtualbox (from Bug #11992):

1. w/o I/O APIC, tails does not boot in either 32-bit or 64-bit mode.

2. w/ I/O APIC, tails boots in 64-bit mode, but (for obvious reasons as this is currently unsupported) has no guest utils.

3. w/ I/O APIC and 32-bit mode, tails does not boot:

> booting in 32-bit mode seems to cause some kind of error (I can’t read the screen fast enough to see the details) regarding vbox_ something during boot; this seems to cause the “waiting for plymouth” to hang and thus the “welcome screen” never appears.

4. w/ I/O APIC and 32-bit mode and failsafe, tails does boot, however:

> now the virtualbox-guest-utils service doesn’t start (call trace indicates problem with modprobe).
> the vboxvideo kernel module does not get loaded and a modprobe attempt results in a call trace.
> mount -t vboxsf … results in a OOPS for a kernel null pointer dereference…

5. w/ I/O APIC and 32-bit mode and modprobe.blacklist=vboxvideo, tails seems to work:

> mount -t vboxsf … then works too.
> FYI: I’m using virtualbox 5.1.8-dfsg-7 (debian sid).
> I haven’t tested shared clipboard, resizing the display seems to work fine.

NB: will try w/ tails 2.7.1 soon; will try nomodeset; also will look into updating the guest utils when it runs.

#14 Updated by anonym 2016-12-01 11:02:47

My tests are with virtualbox 5.1.10-dfsg-1 on Debian Sid, and with Tails 2.7.1:

obfusk wrote:
> 2. w/ I/O APIC, tails boots in 64-bit mode, but (for obvious reasons as this is currently unsupported) has no guest utils.

Right. However, for me everything works pretty nicely without the guest modules loaded: mouse-integration works, and host window resizing => guest resolution changes. IIRC these two did not work before without the guest additions, but I might be wrong. I guess filesystem sharing, host-to-guest time syncing and clipboard sharing are the only features missing with the 64-bit kernel.

Perhaps we can stop recommending 32-bit, recommend 64-bit instead and not install the guest additions until we have a 64-bit user land again, and these things perhaps work again?

> 3. w/ I/O APIC and 32-bit mode, tails does not boot:
>
> > booting in 32-bit mode seems to cause some kind of error (I can’t read the screen fast enough to see the details) regarding vbox_ something during boot; this seems to cause the “waiting for plymouth” to hang and thus the “welcome screen” never appears.

I confirm this. The kernel starts, but some time around/after live-config I see a stack trace that I think is related to trying to load some module, then systemd is waiting for the “Tor” and “Plymouth” services indefinitely. We have switched to vt7 and I can see GDM logged as started, so X crashed I guess. Then we get a

vgsvcTimeSyncWorker: VbglR3GetHostTime failed: rc2=VERR_NOT_SUPPORTED


every other second or so. VERR_NOT_SUPPORTED is interesting. Perhaps we need to upgrade the guest additions to the version in jessie-backports (5.1.8-dfsg-6~bpo8+2 — we install 5.0.24-dfsg-1~bpo8+1).

I also tried booting with nosplash break=bottom and then removed the modules (so they won’t be loaded later) and then boot went completely fine. So, I’m pretty sure our current guest modules are the problem, possibly versus the host’s version of virtualbox.

#15 Updated by obfusk 2016-12-02 02:02:26

New tests w/ virtualbox 5.1.10-dfsg-2 (debian sid), tails 2.7.1:

  • Everything I reported before w/ tails 2.7 still holds.
  • I did forget to mention that when booting in failsafe mode, mouse integration is a little flaky.
  • Booting w/ nomodeset seems the same as w/ modprobe.blacklist=vboxvideo.

anonym wrote:
> … everything works pretty nicely without the guest modules loaded: mouse-integration works, and host window resizing => guest resolution changes. IIRC these two did not work before without the guest additions, but I might be wrong. I guess filesystem sharing, host-to-guest time syncing and clipboard sharing are the only features missing with the 64-bit kernel.

Same here.

> Perhaps we can stop recommending 32-bit, recommend 64-bit instead and not install the guest additions until we have a 64-bit user land again, and these things perhaps work again?

Sure, but only for those who don’t need/want shared folders etc.

> I also tried booting with nosplash break=bottom and then removed the modules (so they won’t be loaded later) and then boot went completely fine. So, I’m pretty sure our current guest modules are the problem, possibly versus the host’s version of virtualbox.

  • Booted w/ break=bottom and removed the vbox* modules.
  • Updated from 5.0.24-dfsg-1~bpo8+1 to 5.1.8-dfsg-6~bpo8+2:
    apt update && apt install linux-headers-4.7.0-0.bpo.1-686 && apt install virtualbox-guest-{utils,x11,dkms}/jessie-backports && systemctl restart virtualbox-guest-utils
  • modprobe vboxvideo changes to the framebuffer now; does crash X, which restarts fine.
  • mount -t vboxsf ... still works.

Since the changes are not persistent, I can’t really say whether booting works fine now,
but it seems that updating the guest modules fixes the problem.

#16 Updated by anonym 2016-12-02 10:50:08

  • Status changed from Confirmed to In Progress
  • Assignee changed from elouann to anonym
  • Target version set to Tails_2.9.1
  • % Done changed from 0 to 20
  • QA Check changed from Info Needed to Dev Needed
  • Type of work changed from Research to Code

obfusk wrote:
> * Booted w/ break=bottom and removed the vbox* modules.
> * Updated from 5.0.24-dfsg-1~bpo8+1 to 5.1.8-dfsg-6~bpo8+2:
> apt update && apt install linux-headers-4.7.0-0.bpo.1-686 && apt install virtualbox-guest-{utils,x11,dkms}/jessie-backports && systemctl restart virtualbox-guest-utils
> * modprobe vboxvideo changes to the framebuffer now; does crash X, which restarts fine.
> * mount -t vboxsf ... still works.
>
> Since the changes are not persistent, I can’t really say whether booting works fine now,
> but it seems that updating the guest modules fixes the problem.

Thanks! I tried a recent build from our devel branch, which installs version 5.1.8-dfsg-6~bpo8+2 of the VirtualBox guest packages, and then all works well. If you want to reproduce, try a nightly build: https://nightly.tails.boum.org/build_Tails_ISO_devel/lastSuccessful/archive/build-artifacts/

In fact, it’d be interesting to know how such a Tails boots with much older versions of the VirtualBox host modules/software e.g. Jessie’s 4.3.36-dfsg-1+deb8u1. Wanna give it a try, obfusk?

Let’s summarize the whole Tails vs VirtualBox situation, as I understand it:

  • Tails 2.10 will get the boot fix for free.
  • Tails 2.9 needs a freeze exception for the virtualbox* packages if we want the boot fix, which I think we do. I’m taking over this ticket for this reason since I’m the release manager for 2.9.
  • Our user docs say “The shared folders work both on 32-bit and 64-bit guests”, which is wrong — it will only work on 32-bit.
  • Bug #11848 (Clarify that VirtualBox guest utilities only work in 32-bit virtual machines) seems wrong, so it should probably be rejected.
  • Bug #12001 (Document that Tails requires I/O APIC being enabled in the VirtualBox VM config) is still valid.
  • Depending on the 4.3.36-dfsg-1+deb8u1 test, we might have to recommend users to upgrade their VirtualBox to jessie-backports or equivalent.

#17 Updated by spriver 2016-12-05 10:16:12

> Thanks! I tried a recent build from our devel branch, which installs version 5.1.8-dfsg-6~bpo8+2 of the VirtualBox guest packages, and then all works well. If you want to reproduce, try a nightly build: https://nightly.tails.boum.org/build_Tails_ISO_devel/lastSuccessful/archive/build-artifacts/

This works for me now with VirtualBox 5.1.8-dfsg-6~bpo8+2, too. Boots without passing any options etc. (32-bit with I/O APIC enabled)

> In fact, it’d be interesting to know how such a Tails boots with much older versions of the VirtualBox host modules/software e.g. Jessie’s 4.3.36-dfsg-1+deb8u1. Wanna give it a try, obfusk?

At least I’ve been not able to install 4.3.36-dfsg-1+deb8u1 properly on my Jessie host I’ve got here. I can give it a try on another machine this weekend maybe.

#18 Updated by anonyme 2016-12-05 15:56:02

Guys, the problem appears to have something to do with the X video driver starting in 2.7.

Besides “Enable I/O APIC” in the settings, if you just increase the Video Memory slider from 16MB to 128MB, it solves the boot problem entirely.

#19 Updated by intrigeri 2016-12-05 16:19:25

> Guys, the problem appears to have something to do with the X video driver starting in 2.7.

> Besides “Enable I/O APIC” in the settings, if you just increase the Video Memory slider from 16MB to 128MB, it solves the boot problem entirely.

Good catch! Doc ticket?

#20 Updated by anonym 2016-12-09 14:40:57

  • Feature Branch set to bugfix/11965-virtualbox-5.1.8

#21 Updated by anonym 2016-12-10 16:32:31

  • Assignee changed from anonym to intrigeri
  • % Done changed from 20 to 50
  • QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:
> > Guys, the problem appears to have something to do with the X video driver starting in 2.7.
>
> > Besides “Enable I/O APIC” in the settings, if you just increase the Video Memory slider from 16MB to 128MB, it solves the boot problem entirely.

I can confirm that “Enable I/O APIC” + bumping the Video Memory indeed makes Tails 2.7.1 boot. So technically we don’t need bumping the version of the guest modules/additions we ship for Tails 2.9…

> Good catch! Doc ticket?

… but I rather not make the configuration harder for our users (in addition to I/O APIC), especially since we then have to track the removal of that instruction in 2.10. So, yeah, freeze exception.

Please review’n’merge! Actually, since we’ll get this in Tails 2.10 I’m tempted to merge it myself without review. Except commit:208244e. Could you just have a look at it and tell me whether it’s ok, intri? If so, please re-assign the ticket back to me afterwards.

#22 Updated by intrigeri 2016-12-11 08:35:32

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

Applied in changeset commit:41b567c3319926d0d4c10f8f312e99d7e9106e80.

#23 Updated by intrigeri 2016-12-11 08:36:23

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

Merged, and reverted the freeze exception on devel.

#24 Updated by anonym 2016-12-14 20:10:51

  • Status changed from Fix committed to Resolved