Re: WARNING CPU at linux/fs/btrfs/ioctl.c:558 create_subvol BTRFS Transaction aborted (error -2)

[Duncan <1i5t5.duncan@cox.net>]

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