per bug#1048338, subvolume handing is (or was) suboptimal.
Today I tried to upgrade an existing subvolume to 15.1. I set the default to
this subvolume and booted with 'upgrade=1'. Since I do not use snapshots, there
is no /.snapshots. Something does not like that fact:


[Ruby] yast2/fs_snapshot.rb:317 Executing:
"/usr/lib/snapper/installation-helper --step 5 --root-prefix=/mnt
--snapshot-type pre --description before\ update --userdata "important=yes"
--cleanup number"
[bash] ShellCommand.cc(shellcommand):78 reading failed
[bash] ShellCommand.cc(shellcommand):78 terminate called after throwing an
instance of 'snapper::IOErrorException'
[bash] ShellCommand.cc(shellcommand):78   what():  open failed
path:/mnt//.snapshots errno:2 (No such file or directory)
[Ruby] yast2/fs_snapshot.rb:323 Snapshot could not be created:
/usr/lib/snapper/installation-helper --step 5 --root-prefix=/mnt
--snapshot-type pre --description before\ update --userdata "important=yes"
--cleanup number returned: {"exit"=>134, "stderr"=>"reading failed\nterminate
called after throwing an instance of 'snapper::IOErrorException'\n  what(): 
open failed path:/mnt//.snapshots errno:2 (No such file or directory)\n",
"stdout"=>""}
[Ruby] yast/builtins.rb:586 tostring builtin called on wrong type Class
[Ruby] yast/wfm.rb:253 Client
/mounts/mp_0001/usr/share/YaST2/clients/inst_update_partition.rb failed with
'Filesystem snapshot could not be created.' (Yast2::SnapshotCreationFailed).

It seems the expectation is btrfs == snapshots.

Did all of our fresh btrfs installs have a /.snapshots? If yes, the assumption
might be valid, except for bug#1048338.