https://download.whonix.org/13.0.0.1.0/
Please test if these work in KVM. @HulaHoop
There is a problem. In VirtualBox, X no longer starts. It could be because of the new https://github.com/Whonix/qxl-xorg-enhance.
Yes, removing /usr/share/X11/xorg.conf.d/50-qxl.conf fixes the VirtualBox X issues.
Options:
- no longer install qxl-xorg-enhance in images build by me by default
- make 50-qxl.conf somehow not interfere with VirtualBox
This is kinda in a rush because I want to release Whonix 13.
I don’t know how to handle such cases in future. If after proposing such changes by one virtualizer maintainer to test if it breaks other virtualizers.
I think this is a better option. I thoought this package depended on the qcow build switch - that is the preferred way of making port versions dependencies separate IMHO. How much work would it take? (This is a necessity for KVM to become usable so please try to include it before the final release. If you’re in a rush then axe it if you must)
It does. But official images are made using --target virtualbox as well as --target qcow2. I don’t do separate builds. That’s why virtualbox guest additions and kvm qxl stuff is installed in the same images. Until this day this non-ideal combination was doable, now something breaking was introduced. I don’t do separate builds of virtualbox and qcow2, because that would make the already very time consuming build process (a lot is already taken by the qcow2 xz creation) even more time consuming. Each time I am regretting not having left creating builds to the kvm maintainer, i.e. you.
make 50-qxl.conf somehow not interfere with VirtualBox
I have no idea how to do that.
Options:
- a) Not install qxl-xorg-enhance by default in the shared VirtualBox / qcow2 builds.
- That means then even when using the build script with
--target qcow2, qxl-xorg-enhance would not be installed. Some additional build option to install custom packages or just for that would have to be developed for Whonix 13. - Then qxl-xorg-enhance could be manually installed by kvm users.
- b) Continue install qxl-xorg-enhance by default in the shared VirtualBox / qcow2 builds but rename
/usr/share/X11/xorg.conf.d/50-qxl.confto/usr/share/X11/xorg.conf.d/50-qxl.conf_in the package so it becomes no longer functional by default (and therefore does not break Whonix VirtualBox).
- We could never remove the
_again for the qxl-xorg-enhance package unless 50-qxl.conf becomes compatible with VirtualBox. (Otherwise it would break X for VirtualBox users.) - c) By when can you make
/usr/share/X11/xorg.conf.d/50-qxl.confcompatible with VirtualBox? - d) The KVM maintainer builds, signs and uploads qcow2 images, no longer me.
- e) Some other solution?
I’ve chosen option a) for the soon upcoming testers-only release.
https://github.com/Whonix/Whonix/commit/4b6bda89bfd33ba26340acf707c148b08c6aebad
It can be potentially combined with option c), d) and possibly e).
a) Not install qxl-xorg-enhance by default in the shared VirtualBox / qcow2 builds.
Already opted for as per next post but I don’t understand why this happens see: e)
b) Continue install qxl-xorg-enhance by default in the shared VirtualBox / qcow2 builds but rename …
That would be confusing to KVM users and provides no advantage over a). Packages are small.
c) By when can you make /usr/share/X11/xorg.conf.d/50-qxl.conf compatible with VirtualBox?
I don’t have an ETA for this. My interactions with upstream are not promising either. How do we know its not a bug in the VBox graphics system?
d) The KVM maintainer builds, signs and uploads qcow2 images, no longer me.
Until reproducible builds are an option I can never risk putting my machine between sophisticated adversaries and users they want to target thru compromising my build system.
Offtopic: When reproducible builds are done perhaps it will be safe to distribute compiled binaries like hardened kernels through Whonix repos.
e) Some other solution?
Please explain how the build system works. Does it build two separate images in parallel (one for each hypervisor flag) from the same set of downloaded packages? If so then the --qcow2 flag would ideally omit any VBox packages and vice versa in the others image. This will become more necessary at some point when hypervisor specific packages like grsec kernel images are shipped.
Without the extraneous 50-qxl.conf file that probably around zero VirtualBox are using, everything works fine. If it was a bug, it would be futile. “X11 does not work without this 50-qxl.conf file which we have for KVM compatibility but without it that works.”
If there is a bug here, it’s the X11 bug not doing proper auto detection and to require 50-qxl.conf:
⚓ T511 abolish /usr/share/X11/xorg.conf.d/50-qxl.conf by having X11 auto detection fixed - X11 bug report
Please explain how the build system works.
Whonix ™ Source Code Introduction
Most importantly, first everything is installed into the raw image before the hypervisor specific steps create specific vdi and qcow2 images.
Does it build two separate images in parallel (one for each hypervisor flag) from the same set of downloaded packages?
No parallel stuff.
If so then the --qcow2 flag would ideally omit any VBox packages and vice versa in the others image.
–target qcow2 only installs KVM stuff indeed and vice versa for --target virtualbox. But. Official images are created with both flags at once… About the why, I wrote that in post 4: Non-Qubes-Whonix 13.0.0.1.0 X issues - #2 by Patrick
(Yes, some things could be improved. And speed up. In theory. Such as not building all Debian packages twice for gateway and workstation builds. And more. But it would require major work on the build script. And add more complexity. With the scare amount of people who completely understand and work on the build script as of now, I am hesitate to make it more complex. Perhaps some existing complexity could be buried by offloading it to other projects and/or Debian. For example contributing something like apt-get-unattended to Debian. Or something like chroot-raw could be generalized, turned into a command that gets merged into an existing package. Or one could contribute to Debian to get an official mechanism to build and distribute raw, vdi, qcow2 etc. images. And more. All of that requires manpower.)
This will become more necessary at some point when hypervisor specific packages like grsec kernel images are shipped.
I don’t see hypervisor specific packages like grsec kernel images happening for many reasons but that’s off-topic.
Then I’ll document installing this package manually.
Will using the --qcow2 on its own install it by default?
HulaHoop:
Then I’ll document installing this package manually.
Ok.
Will using the --qcow2 on its own install it by default?
No.
What’s the status of this?
Should qxl-xorg-enhance be installed by default?
https://github.com/Whonix/Whonix/blob/master/build-steps.d/1700_install-packages#L347
Is not needed for Whonix 14 or beyond. The original bug has been fixed upstream since. Feel free to deprecate.
1 Like