You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In snapper from an image builder perspective we are missing the capability of creating a new empty snapshot. By empty I mean creating a snapshot that is not based on a previous one.
The reasoning is the following, in Elemental, we aim to install/update images as snapshots with following sequence:
Start transaction (new snapshot playground is created)
include data into the new snapshot as desired
Close transaction (make the new snapshot the new default root)
Pretty similar to what tukit from transactional updates does. The problem we have is that we implement this procedure for the very first snapshot too (our first root is considered to be a snapshot too like in MicroOS). We are basically missing a way to call snapper to create a new empty subvolume as an snapshot, that way, snapper could be really our wrapper around btrfs utility.
Let me expose how we create the first root to be seen as a snapshot by snapper (roughly translated into shell steps):
# /mnt is a btrfs partition# Enable quota management and create subvolumes
btrfs quota enable /mnt
btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@/.snapshots
mkdir -p /mnt/@/.snapshots/1
btrfs subvolume snapshot /mnt/@ /mnt/@/.snapshots/1/snapshot
volid=$(btrfs subvolume list --sort path /mnt | head -n 1 | cut -d"" -f2)
btrfs subvolume set-default ${volid} /mnt
# Create snapshot 1 info
date=$(date +'%Y-%m-%d %H:%M:%S')
cat <<EOF > /mnt/@/.snapshots/1/info.xml<?xml version="1.0"?><snapshot> <type>single</type> <num>1</num> <date>${date}</date> <description>first root filesystem</description></snapshot>EOF# Dump content into the first snapshot subvolume# set first snapshot as readonly
btrfs property set /mnt/@/.snapshots/1/snapshot ro true
The so the problem we have is that we need to wrap btrfs to create subvolumes, create snapshot metadata, handle subvolumes IDs vs snapshot IDs, etc. It feels a bit like we are re-implementing core functionalities of snapper itself.
What we'd love to see in snapper is something similar to:
# Create required /mnt/@/.snapshots subvolumes structure
snapper --configdir custom-cfg --root /mnt --no-dbus init
# Create a new empty snapshot, use --empty or something similar instead of '--from ID'
snapshotID=$(snapper --configdir custom-cfg --root /mnt --no-dbus create --empty --read-write --print-number --description "First root install" --userdata "first snapshot")# Dump content into the first snapshot subvolume# Set just created snapshot as read only
snapper --configdir custom-cfg --root /mnt --no-dbus modify --read-only $snapshotID
So to my eyes is essentially bringing to snapshot the capability to create empty snapshots (no parent) and the capability to provide custom configuration beyond /etc. This is good for imaging and creating systems like Micro OS in which the very first / is considered a snapshot already. This would also be valuable for KIWI to simplify some of the logic, as there in order to support Micro OS builds there is also btrfs custom logic to mimic snapper.
The text was updated successfully, but these errors were encountered:
Creation of an empty snapshot is very easy since it is partly already implemented. YaST
also needs that functionality but it is so far only used in the "installation-helper".
In snapper from an image builder perspective we are missing the capability of creating a new empty snapshot. By empty I mean creating a snapshot that is not based on a previous one.
The reasoning is the following, in Elemental, we aim to install/update images as snapshots with following sequence:
Pretty similar to what
tukit
from transactional updates does. The problem we have is that we implement this procedure for the very first snapshot too (our first root is considered to be a snapshot too like in MicroOS). We are basically missing a way to call snapper to create a new empty subvolume as an snapshot, that way, snapper could be really our wrapper aroundbtrfs
utility.Let me expose how we create the first root to be seen as a snapshot by snapper (roughly translated into shell steps):
The so the problem we have is that we need to wrap btrfs to create subvolumes, create snapshot metadata, handle subvolumes IDs vs snapshot IDs, etc. It feels a bit like we are re-implementing core functionalities of snapper itself.
What we'd love to see in snapper is something similar to:
So to my eyes is essentially bringing to snapshot the capability to create empty snapshots (no parent) and the capability to provide custom configuration beyond
/etc
. This is good for imaging and creating systems like Micro OS in which the very first/
is considered a snapshot already. This would also be valuable for KIWI to simplify some of the logic, as there in order to support Micro OS builds there is alsobtrfs
custom logic to mimic snapper.The text was updated successfully, but these errors were encountered: