Qubes OS GPS Stand-alone VM


This is a Standard debian-12 with with small modifications. The main idea is to sync time to 0.0* seconds Manualy as recomended by Whonix through all the running VM’s.

Size 3.8 GB (3805777920 bytes)
$ sha512sum qubes-backup-2024-03-08T162207
59bedc98addab37498411d26fd6e175cbf498211a1030da831732cbb1bac03f0d4ee3682b95673bb18bcf27ddb051607b9a83dbd8ab6da91158759c36ff64d9d qubes-backup-2024-03-08T162207

You can download it from:

The disk space used when restored from backup is 11.6 GB. If this puts you in the LAST 50 GB (or last 10%) of available disk space (check the icon on the bar top right), don’t install it. Running out of disk space is painful.

Target audience
You started with Qubes less than 6 month ago.
If you do not have additional hardware, software, or legacy templates, get a USB Ublox GPS and install the VM before you go online for the first time. This is a baby step to safety.

How to use.
General: The file manager is Caja. It can be called from terminal with /gpCaja/opt/gnu/bin/caja

Start GPS-deb12. From the hardware icon (top right) move the GPS hardware/dongle (which is by default in sys-usb VM) to GPS-deb12 VM.

Start xterm (write click in Qubes Manager on GPS-deb12 VM entry, select to run a command, type xterm and press Enter).
In xterm run /home/user/gpsd-gp/opt/gnu/bin/cgps. If you don’t see anything, most likely you forgot to move the GPS hardware to the GPS-deb12 VM or your GPS is not compatible (bummer, the majority of GPSes are compatible and the most common Ublox is compatible).

After everything GPS settles, and you can see a location fix (latitude and longitude), and the Time offset, open another terminal. Type ./gpstimeT1.sh and repeat a maximum of 3 times in a minute until your Time offset is 0.0*. In most cases once or twice is enough.

In Qubes Global Config set your time VM as GPS-deb12. In Dom0 terminal execute sudo qvm-sync-clock.
You can even use it as Dom0 update. Who am I to tell you what to do or not do? I’m No-Curva and that is a guarantee.

You can get a similar VM on i2p that includes GPS time.

Keybase and Amazon are just…

Could you provide a script to run on a debian template to achieve the same changes?

It would be a lot more easier to review and audit the code rather than looking for all your changes done on the template.


Worth noting, just in case:


Thank you @Qball. I’m with @solene on this, an auditable script would be the next obvious step.

Public Safety:

As with everything not signed by the Qubes OS team exercise extreme caution and only use if you know what you are doing / have minimal risk in doing so. The above is a contribution from the community and in no way endorsed, verified or otherwise recommended by the project.

1 Like

Also, restoring someone else’s backup file without passing --paranoid-mode to qvm-backup-restore is probably equivalent to giving whoever created the the backup file full access to the system, including dom0.

Stripped of the normal integrity mechanism which is “I created this backup file myself on an uncompromised computer, and protected it with a password only known to me” it’s a complex file format that will be parsed by scary (and usually outdated, in dom0) codebases like libxml2, GNU tar, etc. Paranoid Mode at least moves that parsing into an untrusted DisposableVM.


It can happen if I made lots of mistakes in jugments. I did take some precautions hopefully enough. The point was to show how GPS time works in Qubes. There are some more subtle security points such as: if you have Qubes file manager in sys-net, you escaped to early from the asylum… etc. I do understand the risk.

1 Like

Thanks for pointing out that transfering VM even between your own machines is Extremely Dangerous. Keybase and Amazon needs security minded people such as yourself.

I’m not sure if that’s the right conclusion to draw. If you trust both of your own machines equally, for example, then it’s not a security risk to use Qubes backup and restore without paranoid mode.