Standard fsck isn't run on VM startup #979

Open
nrgaway opened this Issue Apr 29, 2015 · 4 comments

Projects

None yet

4 participants

@nrgaway
nrgaway commented Apr 29, 2015

/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 marmarek added this to the Release 3.1 milestone May 12, 2015
@marmarek
Member
marmarek commented Aug 5, 2015

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
Member

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
cfcs commented Aug 27, 2015

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.

@marmarek marmarek modified the milestone: Release 3.2, Release 3.1 Feb 8, 2016
@marmarek marmarek modified the milestone: Release 3.2, Release 4.0 Aug 5, 2016
@Rudd-O
Rudd-O commented Oct 23, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment