So I think I know why this doesn't work under Ubuntu and it's related to the mount options Ubuntu sets by default for btrfs for a new installation.
By default, Ubuntu installs systems with btrfs into a subvolume called @ and the home directory into a subvolume called @home. It then proceeds to add the mount options of subvol=@ to /etc/fstab for the root volume's mount. This is all great until you want to revert via snapper.
Before going further, I want to clarify that, afaik, snapshots are just subvolumes for BTRFS. For snapper, the subvolume has a path of /.snapshots/<int>/snapshot. Since this is relative to the rootfs mounted, which is @, I believe it's actually @/.snapshots/<int>/snapshot.
snapper's rollback works by using the default subvolume feature for a filesystem. This means if you mount that file system (mount /dev/sda1), it will mount that subvolume instead of the top-level file system.
As an example, when rolling back to @/.snapshots/10/snapshot, snapper creates a read-writable subvolume from snapshot #10 and sets that as the default subvolume for the filesystem instead of the usual /. Its design hopes that on the next boot of the system, it will boot from the newly cloned rw-able snapshot, as opposed to the original subvolume. Note that it does not alter @.
However, since ubuntu's fstab entry for the root volume has subvol=@ as the default flag, it will ALWAYS mount subvol=@ as / and never mount the default subvolume as /.
As a workaround, you could in theory:
1. Remove the subvol=@ options from /etc/fstab
2. Set the default subvolume for your filesystem to be @ (or whatever snapshot you're using).
I haven't tested this yet, but it _should_ fix this problem. Although this may be more preferable to be done by the ubuntu installer by default instead. However, doing that is a major change and might have other implications that I'm not aware of.
Additionally, the .snapshots folder under @ is not quite idea for rollbacks from a liveCD... I don't know what the optimal layout would be tho, but having it nested under @ means you can't do something like mv @/.snapshots/.../snapshot @ easily.
So I think I know why this doesn't work under Ubuntu and it's related to the mount options Ubuntu sets by default for btrfs for a new installation.
By default, Ubuntu installs systems with btrfs into a subvolume called @ and the home directory into a subvolume called @home. It then proceeds to add the mount options of subvol=@ to /etc/fstab for the root volume's mount. This is all great until you want to revert via snapper.
Before going further, I want to clarify that, afaik, snapshots are just subvolumes for BTRFS. For snapper, the subvolume has a path of /.snapshots/ <int>/snapshot. Since this is relative to the rootfs mounted, which is @, I believe it's actually @/.snapshots/ <int>/snapshot.
snapper's rollback works by using the default subvolume feature for a filesystem. This means if you mount that file system (mount /dev/sda1), it will mount that subvolume instead of the top-level file system.
As an example, when rolling back to @/.snapshots/ 10/snapshot, snapper creates a read-writable subvolume from snapshot #10 and sets that as the default subvolume for the filesystem instead of the usual /. Its design hopes that on the next boot of the system, it will boot from the newly cloned rw-able snapshot, as opposed to the original subvolume. Note that it does not alter @.
However, since ubuntu's fstab entry for the root volume has subvol=@ as the default flag, it will ALWAYS mount subvol=@ as / and never mount the default subvolume as /.
As a workaround, you could in theory:
1. Remove the subvol=@ options from /etc/fstab
2. Set the default subvolume for your filesystem to be @ (or whatever snapshot you're using).
I haven't tested this yet, but it _should_ fix this problem. Although this may be more preferable to be done by the ubuntu installer by default instead. However, doing that is a major change and might have other implications that I'm not aware of.
Additionally, the .snapshots folder under @ is not quite idea for rollbacks from a liveCD... I don't know what the optimal layout would be tho, but having it nested under @ means you can't do something like mv @/.snapshots/ .../snapshot @ easily.