james harvey posted on Sat, 02 Jan 2016 23:40:38 -0500 as excerpted: > I notice snapper always forces me to have a subvolume > "main/var/lib/machines". I don't store vm files there, I've tried > deleting it, but snapper forces it back. But, when running off the > archiso the subvolume delete for the .snapshots folder, I don't see the > "main/var/lib/machines" subvolume... So I'm thinking this oddity may be > a pointer toward why this is happening. > > I was confused why I was even seeing "create_subvol" during boot. It > must be then snapper makes the "main/var/lib/machines" subvolume during > boot, not when on the archiso. So, deleting the .snapshots volume > booted off the ISO must be leaving btrfs in a bad state, so on reboot > when a subvol is created by snapper, it fails. FWIW... I don't use snapper, or indeed, subvolumes/snapshots at all, on my (gentoo with systemd) installation, but FWIW, recent versions of systemd will try to create /var/lib/machines (and a few others) as a subvolume at boot time, if it doesn't already exist. Older versions of systemd, before it integrated more btrfs support, created normal subdirs at these locations (tho the /var/lib/machines one was /var/lib/container or some such, back then). I happen to know about it as the first systemd version (218, IIRC, or was it 219?) that attempted to include that integration didn't handle the errors from attempts to do the subvolume create on a still read-only- mounted / [1], so the corresponding tmpfs.d running service failed. The previous version's mkdir -p calls had worked fine, since mkdir -p succeeds when the dirs already exist. That wasn't fixed until 221 or perhaps 222. Of course your post mentions main/var/lib/machines, not simply /var/lib/ machines, but obviously, in the correct context the main/ version is there due to the /var/lib/machines case, and /var/lib/machines may in fact be seen as main/var/lib/machines depending on subvolume usage and mounting. So I'm guessing either it's systemd creating it (with the /var/ context) and not snapper, or it's snapper creating it (with the main/ context), knowing that systemd uses the corollary, so it can manage the systemd created subvolume in snapshot context as well. Doesn't solve your transaction aborted situation, but should provide a bit more information on those specific subvols/subdirs and why snapper or systemd is trying to create them. --- [1] Read-only mounte /: I keep my / mounted read-only by default, only mounting it writable when I want to update or change configuration. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
