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: