[arch-projects] [devtools] [PATCH] makechrootpkg: Be recursive when deleting btrfs subvolumes.

[Jan Alexander Steffens]

On Fri, Feb 10, 2017 at 9:46 AM <lukeshu at lukeshu.com> wrote:

> From: Luke Shumaker <lukeshu at sbcglobal.net>
>
> Motivation:
>
>   When installing the necessaryssary dependencies in the chroot, the
>   ALPM hooks run; and if 'systemd' is a dependency, then one of the
>   hooks is to run systemd-tmpfiles.  There are several tmpfiles.d(5)
>   commands that instruct it to create btrfs subvolumes if on btrfs
>   (the `v`, `q`, and `Q` commands).
>
>   This causes a problem when we go to delete the chroot.  The command
>   `btrfs subvolume delete` won't recursively delete subvolumes; if a
>   child subvolume was created, it will fail with the fairly unhelpful
>   error message "directory not empty".
>
> Solution:
>
>   Because the subvolume that gets mounted isn't necessarily the
>   toplevel subvolume, and `btrfs subvolume list` gives us paths
>   relative to the toplevel; we need to figure out how our path relates
>   to the toplevel.  Figure out the mountpoint (which turns out to be
>   slightly tricky; see below), and call `btrfs subvolume list -a` on
>   it to get the list of subvolumes that are visible to us (and quite
>   possibly some that aren't; the logic for determining which ones it
>   shows is... absurd).  This gives us a list of subvolumes with
>   numeric IDs, and paths relative to the toplevel (actually it gives
>   us more than that, and we use a hopefully-correct `sed` expression
>   to trim it down; the format certainly isn't human-friendly, but it's
>   not machine-friendly either.)  So then we look at that list of pairs
>   and find the one that matches the ID of the subvolume we're trying
>   to delete (which is easy to get with `btrfs subvolume show`); once
>   we've found the path of our subvolume, we can use that to filter and
>   trim the complete list of paths.  From there the remainder of the
>   solution is obvious.
>
>   Now, back to "figure out the mountpoint"; the normal `stat -c %m`
>   doesn't work.  It gives the mounted path of the subvolume closest to
>   the path we give it, not the actual mountpoint.  Now, it turns out
>   that `df` can figure out the correct mountpoint (though I haven't
>   investigated how it knows when stat doesn't; but I suspect it parses
>   `/proc/mounts`).  So we are reduced to parsing `df`'s output.
>

The chroot management is getting so complex I wonder if we're not better
off killing the btrfs support (it doesn't buy us much over rsync since the
base (root) chroot tends to be small) or using someone's else container
framework, maybe rkt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.archlinux.org/pipermail/arch-projects/attachments/20170210/3b0719bd/attachment.html>