Not sure how I can check this, but running this command: sudo ls /var/lib/docker/btrfs/subvolumes lists various subvolumes. I'm pretty sure the docker folder is running on the btrfs partition rather than one of the other various partitions. The worst case approach you just described is the solution I had taken the last time after I had given up. I woud prefer not to nuke my docker installation everytime I rollback as a lot of my docker images require a long bootstrap process to setup at work :/ Is there an inherent problem with the way docker has been setup on btrfs that is causing this issue? Is this something we can fix? Thanks for the reply! Mike On Mon, Sep 18, 2017 at 3:29 AM, Aleksa Sarai <asarai@suse.de> wrote:
After a recent rollback I've noticed my docker containers dont want to start. From what I can tell this is related to btrfs since all the messages are all along the lines of:
If this is a snapper rollback this might be caused by some weird btrfs issue. I believe we have a subvolume for /var/lib/docker, but if we don't then a rollback with snapper might have screwed up the layer store.
Worst case scenario you can do something like:
% btrfs subvolume delete /var/lib/docker/btrfs/subvolumes/* % rm -rf /var/lib/docker
Which will delete everything that Docker had stored and you can start "fresh".
-- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/
-- Michael Aquilina -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org