Standard fsck isn't run on VM startup

[nrgaway]

/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.

Possible solutions:
Add feature to qubes-manager to:

1. Show if there is disk error
   2 .Check disk
   3 .Repair disk

[marmarek]

Currently if one want to run fsck on /rw, it requires:

1. Adding single parameter to kernel command line (qvm-prefs -s VMNAME kernelopts single)
2. Starting VM - it would timeout on qrexec connection, but that's ok.
3. Access VM console using sudo xl console VMNAME
4. Get shell access (just press enter when prompted for root password)
5. Run fsck on /dev/xvdb (/rw): fsck -f /dev/xvdb
6. Shutdown the VM - poweroff from that shell
7. Restore default kernel command line: qvm-prefs -s VMNAME kernelopts default

[marmarek]

Currently if one want to run fsck on /rw, it requires:

1. Adding single parameter to kernel command line (qvm-prefs -s VMNAME kernelopts single)
2. Starting VM - it would timeout on qrexec connection, but that's ok.
3. Access VM console using sudo xl console VMNAME
4. Get shell access (just press enter when prompted for root password)
5. Run fsck on /dev/xvdb (/rw): fsck -f /dev/xvdb
6. Shutdown the VM - poweroff from that shell
7. Restore default kernel command line: qvm-prefs -s VMNAME kernelopts default

[marmarek]

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.

[marmarek]

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.

[cfcs]

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.

[cfcs]

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.

[Rudd-O]

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.

[Rudd-O]

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.