Whonix11 Development Status For Qubes 3.0

I finally have a successful build of gateway with no manual intervention during build process with 11.0.0.0.4-developers-only :slight_smile:

I needed to manually patch parse-cmd to allow the `–target qubes’ build options, but understand I can revert back to using ‘–target root’ for time being.

Gateway builds, installs and runs. Tor starts and control-port functioning properly.

timesync and whonixcheck do not seem to be functioning. The systemd status for these services states they are running, but after whonix-setup no timesync or whonixcheck is completed.

Also manually running timesync or whonixcheck in terminal does not work, just sits there with no response what so ever.

I just want to know if that is expected behaviour at this point.

Otherwise Whonix10 gateway can successfully access Tor via gateway.

great news,keep it up!

Hope that you’ll solve the bug asap ,you are doing a great job there :wink:

Yes. --target qubes has been fixed (⚓ T298 add --target qubes) in 11.0.0.1.5-developers-only.

The other issues are known, outstanding bugs, todo as per:

The issues I stated above in regards to whonixcheck and sdwdate not responding were due to the msgcollector.service being in the wrong location (/lib/systemd instead of /lib/systemd/system).

Once I placed the msgcollector.service in place, I did receive an error that it could not mount

May 17 02:48:42 host systemd[1]: msgcollector.service: main process exited, code=exited, status=3/NOTIMPLEMENTED
May 17 02:48:42 host systemd[1]: Failed to start msgcollector.
May 17 02:48:42 host systemd[1]: Unit msgcollector.service entered failed state

Running /usr/lib/msgcollector/msgdispatcher_init directly gave me the error:

root@host:/lib/systemd/system# /usr/lib/msgcollector/msgdispatcher_init
mount: wrong fs type, bad option, bad superblock on none,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

I then proceeded to comment the line mounting the tmpfs, and was able to start the msgdispatcher service and at that point whonixcheck worked, but I can see sdwdate is not implemented. No dialogs appeared, but I assume you are aware of this already.

As for the other issue of services not being enabled, I don’t know why still, as you may have notices I always enable them in postinit script.

Anyway, this is good news that I believe the Qubes build has working whatever is already implemented.

To bad I don’t fully understand the business logic of msgdispatcher or sdwdate or I would have fixed them and I now will have a few hours of down time until you release next development-version.

I have tomorrow available to work on any issues if there is anything that won’t take you longer to explain how it works than to implement it yourself :slight_smile:

msgcollector required two fixes:

And more.

Anyhow. Takes some time. No Qubes specific stuff.

So far the latest build (11.0.0.2.1-developers-only) seems to be working nice.

Gateway built without issues, installed and started okay.

The only immediate issue I has was permission problem of /tmp/uwt directory which gave an initial whonixcheck error. The uwt directory was owned by root.root 775 (rwxrwxr-x). I changed the ownership to user.user and re-ran whonixcheck okay.

This last build included your pull requests. Just building workstation next…

Nice.

Answer here: