If you create an snapshot of your own, it's 1:1 identical to the already existing read-only snapshot. Means it includes /etc and the configuration for the overlays.
Thanks Thorsten that was very helpful and I appreciate it! I have not used mount overlays before so I had to do some reading. One reason I thought there was an issue is because when I did snapper create -d "test" It created snapshot 11 ( in /.snapshots/11/snapshot ) but since there is no /var/lib/overlay/11 folder I incorrectly concluded that it would be a problem at boot as it would not have an overlay for etc for snapshot 11. I now see that since the overlays are stored on the /@var subvolume, and since /etc is an overlay, that snapshot 11 has etc in /.snapshots/11/snapshot/etc and that the fstab there is using overlay 9 and overlay 10 ( just like it did for snapshot 10 - the current default/booted snapshot ) Did I get that all right ? I did find something that was broken by the R/O root fs. mksubvolume is a convenience program to make it easy to create new subvolumes whose parent subvolume is the /@ subvolume. It creates the subvolume with /@ as the parent, adds the /etc/fstab entry to mount it, but then fails when it tries to create the folder for the mountpoint because the root fs is R/O. Manually doing the steps is not hard mount /dev/sdaX /mnt -o subvol=/ btrfs subvolume create /mnt/@/myvol Add to /etc/fstab systemctl daemon-reload But you still have the issue of how to create the folder for the mount point btrfs property set /.snapshot/10/snapshot ro false mkdir /.snapshots/10/snapshot/myvol btrfs property set /.snapshot/10/snapshot ro true mount /myvol It seems like the R/O root did not take into consideration a user needing to add mount points for other drives. I have many drives in my system for different uses. Is there a better way to add the additional mount points that I have missed ?
If you can come up with a real good use case, why somebody need to create identical snapshots themself, we can look at it. Currently I don't see such an use case, except making the current code even more complex for duplicate data.
If you want to keep a snapshot, there is no need to create a new one, just tell snapper to not delete the existing one when doing the cleanup.
Thanks, your response has caused me to think through the main reasons I have created my own snapshots. It seems they fall into 2 categories. The first reason is because the snapshot descriptions for snapshots that zypper creates are not real useful IMHO. When I install something I have used the following so I have a good description on the pre/post snapshots. snapper create -d 'install programXYZ' --command 'zypper install programXYZ' zypper does not have a way that I've found to provide a meaningful snapshot description as a parameter. I considered using the --userdata option but that seems to be used for key/value pairs and is already used for things like marking a snapshot as important so I didn't want to mess with that. If zypper provided a way to also specify what the description was that would address that. I guess, one other option would be to just modify the description after the fact using 'snapper modify SnapShot# -d "New description". The descriptions are no better with transactional-update as doing a pkg install will just have a description of "Snapshot Update of #XX". While that is technically correct it is also not very useful and having to do a snapper status x..y to figure out what occurred in that snapshot is a pain and could be error prone, especially if multiple things were done. The second reason that I create my own snapshots is because I like to manually cleanup snapshots that I have created and not have them subject to the cleanup algorithm settings in the snapper config for the volume. My manually created snapshots never have a cleanup algorithm therefore they will never be deleted until I decide to do so which is also why having meaningful names is really important to me. If it really is a zypper dup update than DUP would be fine but snapshots are often created for other points in time which were not DUPS. Also, when you do "transactional update cleanup" it can change a snapshot from no cleanup to number cleanup and also add "important=yes" to the userdata. For example snapshot #10 had no cleanup and no userdata and then after running 'transactional update cleanup' it changed snapshot 10 to number cleanup and added "important=yes" to the userdata. I have not seen it mess with snapshots I created manually which I suspect is because it deemed them not important like a zypper dup would be. I get your point though about creating identical snapshots and agree that with the root fs R/O that need does not exist but it would be nice if there was a way to specify the description to use for a snapshot when doing transactional-update as well as specifying how we'd like the snapshot cleaned up and also not have it be later modified when transactional-update cleanup is run. Hope that helps explain my use cases. Regards, Joe