/rw is not mounted in the standard way from /etc/fstab, because of for example DispVM, which does not have /rw mounted at all. This is also the reason why standard fsck isn't run on VM startup.
Add feature to qubes-manager to:
Currently if one want to run fsck on /rw, it requires:
qvm-prefs -s VMNAME kernelopts single
sudo xl console VMNAME
fsck -f /dev/xvdb
qvm-prefs -s VMNAME kernelopts default
We should go with running standard fsck on VM startup. If it isn't desirable for some VM (which doesn't have /rw at all - DispVM), this could be addressed in .mount unit file with some condition.
Alternatively you can run fsck on private.img from dom0 (if you trust fsck to not have security flaws, which is grantedly a risky assumption). Either way it's a required step for shrinking/compacting appvm filesystems to free up space.
The agent really should detect if there is an error in the kernel ringbuffer or journald log, and submit that error for dom0 to display it in qubes-manager or with a notification.
But this will not cover the case of a system entirely failing to boot. In that case, it's possible that monitoring the console log in dom0 can provide a mechanism that lets the user know (qubes-manager or notification) that the VM is not booting properly, MUCH, much faster than just waiting for a timeout and then just dying.