I couldn’t boot on a Linux Mint 17 host (a Debian/Ubuntu derivative) until I deleted the hugepages settings. See prior thread I made here: [url=https://www.whonix.org/forum/index.php/topic,674.0.html]Whonix Forum.
I think it’s a Debian related thing.
thanks whonixfaithful for confirming. Will make a note of this in the KVM versions sticky.
Hulahoop, here is how to reproduce what I have seen, so anyone can verify it for themselves. I went through this today to confirm what I had found by accident previously, and using the current release of Debian Jessie.
Download latest the latest Debian Jessie from Index of /cdimage/weekly-builds/amd64/iso-cd . Any of them should do but the one I used was http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-kde-CD-1.iso (dated 2014-11-17).
Burn the ISO to a CD and boot the target computer from the CD.
During installation, unselect “Gnome” and select “KDE”.
After installation has finished, run “sudo apt-get update && sudo apt-get dist-upgrade”.
Run “sudo apt-get install -t jessie-backports qemu-kvm libvirt-bin virt-manager”.
Then UNINSTALL and RE-INSTALL the same three packages:
“sudo apt-get remove qemu-kvm libvirt-bin virt-manager”
“sudo apt-get install -t jessie-backports qemu-kvm libvirt-bin virt-manager”
Then proceed with the rest of the setup as given in Whonix ™ for KVM
After the foregoing steps you will have only one error after running a Whonix VM: “unable to connect to monitor” which can be remedied by editing out the hugepages settings from the xml files, and recreating the vm.
I don’t know why step 5. is necessary but without it, I have consistently found that when I run the Whonix VMs I get the same cascade of errors as before (i.e., if I remove one section from the xml files then there will be another error, and so on), starting with the error about “ACPI S3”. One might think that reinstalling KVM shouldn’t make any difference since the versions of the packages are the same before and after (I checked that that was the case), and no dependency packages get uninstalled and reinstalled, just those three.
Anyway, I found the steps above reproducible over several trials.
Hulahoop, here is how to reproduce what I have seen, so anyone can verify it for themselves.
Dennis I am not saying it doesn’t happen, but its become clear now whats doing this and how to fix it.
If I may ask, please list the version of your libvirt package here.
libvirt-bin 1.2.9-3
qemu-kvm 2.1+dfsg-7+b1
virt-manager 1:1.0.1.1-3
Sure, I’m not saying you were saying it doesn’t happen. I went through this exercise in order to do two things:
Give a recipe for anyone to run Whonix on KVM on Debian, minus hugepages but including everything else (such as the updated rng).
Establish a common, as-reproducible-as-possible platform for debugging the hugepages bug. I.e., using a default installation of Debian.
I note that there are two problems:
The hugepages bug.
Why is it necessary to uninstall and re-install KVM?
By the way, I established that permissions aren’t involved: On one trial I enabled root login at the beginning, logged in as root and installed KVM and performed all operations as root. The result was exactly the same.
1. The hugepages bug.
- Why is it necessary to uninstall and re-install KVM?
1 is not really a bug, its a feature thats not supported by your version of KVM (yet).
I am not sure why 2 was needed to make to work, but my guess is you had to remove the older version completely before installing the one from backports. whonixfaithfuldid not need to do this IIRC. I’m guessing then its either that or a system specific quirk which you ran into unfortunately.
“I am not sure why 2 was needed to make to work, but my guess is you had to remove the older version completely before installing the one from backports. whonixfaithfuldid not need to do this IIRC. I’m guessing then its either that or a system specific quirk which you ran into unfortunately.”
No, because it wasn’t an older version to begin with: I installed KVM from the backports repository onto a new installation of Debian Jessie. At that point I’m getting the multiple errors when trying to start Whonix. Then I uninstalled KVM, re-installed it from the SAME backports repository, and then Whonix starts OK if the hugepages option (only) is removed from the xml files. Like I said, checking the versions before and after gives the same versions.
Because it is repeatable on Debian, the same common distro that Whonix is a customization of, then it’s not really some peculiarity of “my version.”
You won’t say what your version your OS is, but could you please give the versions of the KVM packages that you are running?
By the way, I’m not trying to sound harsh, just making the facts clear. I’ve spent more time on this than I care to repeat, and it might have been made shorter if more information was available about what works and what doesn’t on what platforms.
I’m totally mystified why the failure of hugepages isn’t “a bug” but is simply a feature “not supported yet.”
According to:
https://fedoraproject.org/wiki/Features/KVM_Huge_Page_Backed_Memory
KVM Huge Page Backed Memory SummaryEnable KVM guests to use huge page backed memory in order to reduce memory consumption and improve performance by reducing CPU cache pressure.
OwnerChris Wright -- chrisw redhat com John Cooper -- john.cooper redhat comCurrent status
Targeted release: Fedora 12 Last updated: 2009-09-24 Percentage of completion: 100%An SELinux issue in the kernel still remains, preventing full sVirt protection being applied to huge pages.
CompletedKVM support for huge pages libvirt patch posted for running guests with -mem-path /dev/hugepages libvirt patch-v2 posted which detects the host's hugetlbfs mount point automatically. Identify SELinux issue in the kernel Get the libvirt patch committed to libvirt-0.7.1</blockquote>That’s from 2009, and it’s marked as 100% complete., but the latest Debian packages are missing this feature? What am I missing in my my understanding of this? Remember, I’m no developer, just a newbie Debian administrator, at most.
That's from 2009, and it's marked as 100% complete., but the latest Debian packages are missing this feature? What am I missing in my my understanding of this? Remember, I'm no developer, just a newbie Debian administrator, at most.
Ok now it makes sense to call it a bug. Its been supported a long time as you found out and my libvirt is 1.0 - a much older version than yours too.
With a problem like this its best to report it to upstream Debian and they should be able to fix it. Seeing it was reproduced by more people it should be easy to find. If its a libvirt regression then you will need to report it to libvirt mailinglist. Talking with both camps at the same time will help solve things quicker.
Its not the optimal answer you wanted to hear but please understand there is nothing I can personally do to fix it. I can try assisting you to find the right channels to report to. Meanwhile try running with the workaround you’re using.
https://www.debian.org/Bugs/Reporting
https://lists.debian.org/
http://www.redhat.com/mailman/listinfo/libvir-list
Thanks for your answer. Before logging such requests I’m going to have to get Whonix out of the picture and reproduce it with, say, a generic Debian VM.
I got answers behind the hugepages problems you’ve reported here. Yes I am a Fedora user.
The hugepages errors we saw is not a bug but a change in its behavior. Hugepages are not enabled in Linux by default and need to be done manually so the whonix vm was never using it anyway. older versions of qemu silently switched back to using regular system memory pages but now the newer versions force the need for hugepages and fail vm startup if they are not found. My solution is to remove hugepages from the default configuration and document how to enable them for those interested. I want Whonix to work with its default settings and not need and tinkering by users.
https://bugzilla.redhat.com/show_bug.cgi?id=1173218
The only real bug I saw with the recent version is with shared folders:
https://bugzilla.redhat.com/show_bug.cgi?id=1173224
You won't say what your version your OS is
I didn’t want to share that information because I was afraid of making it easier for de anonymizing. Hiding this made bug reporting difficult and ineffective. I over thought it and it isn’t that much help for unmasking.
Thanks to the assholes who devote so much effort and resources tracking innocent users, privacy enthusiasts and hacking sysadmins to violate everyone’s right to privacy, I don’t feel safe for my real identity to be associated with my contributions here. I don’t know if by just participating or something I said on the blog puts me on more of their shit lists.
Thank you very much for following this up.
I’ve neglected it since Virtualbox has been sufficient to my needs, and I have been absorbed in selecting a language to learn for my Phantom project. Maybe something useful will come of the latter.
Thank you very much for following this up.
No problem 
I’m curious about what the Phantom project is about.