Warn, so the user can intervene to install immediately, or even reject (e.g. as current, but then…).
Wait for the user to Shut down.
If there are any non-rejected updates…
a) Display Don’t pull the plug.
b) Shut down any unnecessary VMs.
c) Overwrite the previous backup with a current one, showing progress bar (e.g. as normal).
d) Carry out the update(s), while showing progress bar (as normal).
e) Shutdown as normal.
At least that is what I (try to) do manually when I see an update. Backing up that night, updating in the morning, and rebooting to check the update.
I have never needed it, but it does make me feel better, knowing that any disastrous updates can be restored
If updates could be done by just running qubes-vm-update it may be possible to start it as a systemd service under some conditions:
before shutdown
at boot
prevent shutdown until qubes-vm-update is done
try it every X hours / days (the clock counter can work independently from the system uptime, so if you say every day at 03h00 and you never start your computer at that time, it will try it ASAP once 03h00 was passed since last time)
It should be possible to have usable logs from this too as it is sent to journald.
Perhaps I could polish up my scripting and if I see an overnight update is needed run a properly conditioned version of … qvm-backup qubes-vm-update shutdown
Can you think of any problems? The only disadvantage I can think of is that any overnight updates are ignored.
Slight necrobump, but has anyone tried implementing this (such as with cron)? I’d be very interested to hear if there are any pitfalls to watch out for.
