diff options
author | Sam Thursfield <sam.thursfield@codethink.co.uk> | 2015-05-14 12:42:27 +0100 |
---|---|---|
committer | Baserock Gerrit <gerrit@baserock.org> | 2015-05-19 15:05:51 +0000 |
commit | b3b69e8cc9c1adf7141caa4d3676b69d89246de9 (patch) | |
tree | 16383c9ab226e76b5bfd4509d0667dd69278d7a1 /README | |
parent | c3927f773be52b92a1ef257307c69905da8b97a6 (diff) | |
download | baserock-chroot-b3b69e8cc9c1adf7141caa4d3676b69d89246de9.tar.gz |
Refuse to delete chroots which are in use
It turns out that `manage-baserock rm` can delete data from filesystems
that are mounted in a chroot directory. This is most likely to happen if
the chroot is active (and schroot created the mounts), so let's check
that there are no active sessions before deleting.
You now get a message like this if you try to remove a chroot with
active sessions:
I found the following active sessions for chroot '15.19':
session:baserock-15.19-4ef616d2-fdbf-4796-bcee-7132b989a2f8
session:baserock-15.19-e0f00498-190a-44be-9d29-cce057cbb259
You might lose data in mounted filesystems if I were to
recursively delete path /opt/baserock/chroots/15.19.
If you think these sessions are stale, you can run the
following command to end ALL schroot sessions:
schroot --end-session --all-sessions
I found that on my laptop there were a lot of stale sessions, probably
from when my computer had crashed while an 'schroot' session was open
so the session didn't get automatically ended. Stale sessions now will
prevent the user from being able to use `manage-baserock rm` so we need
to tell them about them.
Change-Id: I90aa19717d8e7007fb6aced9a8e9422967ddc64f
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions