-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add orange flavor btrfs support #2207
base: main
Are you sure you want to change the base?
Conversation
rdesaintleger
commented
Oct 17, 2024
- remove btrfs default subvolume,
- save btrfs device in Btrfs structure,
- rework brtfs state mountpoint detection (uses btrfs device, got rid of rootSubvolID and snapshotsSubvolID constants),
- add 'active' relative symlink to active snapshot (updated in CloseTransaction() and read in getActiveSnapshot()),
- add grub 'active_snap' variable (could it be replaced by dracut resolving the 'active' link ?),
- add grub 'root_subpath' variable which allows to prefix kernel and initrd image with a subpath,
- handle grub modules packaging under /usr/lib/elemental/bootloader
- add RelativizeLink() to recursively make symbolic links relative,
- ensure kernel and initrd are relative links (allow grub to process without mounting subvolume)
- update orange Dockerfile
@rdesaintleger thanks for your PR ! |
Sorry, my PR is bad for the moment I found a fix for the RelativizeLink() function which allow build tests to go further (up to snapshotter). Also I didn't notice that snapper did use the btrfs default subvolume feature. I think that I'll make a new snapshotter without snapper named 'btrfs_nosnapper' with its own regression tests. This will have the advantage of not breaking existing btrfs green flavors and being cross distro when using new snapshotter. |
@rdesaintleger really nice to see this implemented! Looking forward to the new snapshotter! Looking back we should probably have named the current "btrfs" snapshotter as "snapper" instead.. oh well! |
At a time when I coded this snapshotter in head there were few configuration options for the btrfs snapshotter. Those were related to the required stack. Pure btrfs implementation, without snapper, implementation with snapper and third option using tukit. So my idea was having like three different levels of abstraction. So, even if the implementation could be in different files or structures I imagined all three as single snapshotter for btrfs. The thing is that snapper also support some sort of LVM snapshots which are definitely not supported by Elemental-toolkit and tukit assumes snapper. Hence in all cases we are talking about BTRFS subvolumes. Just explaining that because most of the parts that are required to make a wrapper for btrfs tool are already implemented in the current snaphsotter hence we should figure out some ways to reuse all that. See the following manual steps I did at a time to make a PoC before actually implementing the snapshotter for btrfs. For install (first snaphsot): # 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
# ID should be computed from a "btrfs subvolume list" command
# default set to the equivalent of the STATE partition (probably a /@/state subvolume would make more sense)
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 the built image into the first snapshot subvolume
./build/elemental pull-image --local ${osimage} /mnt/@/.snapshots/1/snapshot/
# Create the quota group
btrfs qgroup create 1/0 /mnt
#chroot /mnt/@/.snapshots/1/snapshot snapper --no-dbus set-config QGROUP=1/0
# set first snapshot as readonly
btrfs property set /mnt/@/.snapshots/1/snapshot ro true All of the above is already coded in the current snapshotter. So most if not all pieces are already there. I'd be happy to help on getting a proper btrfs wrapper that can be used in both cases. With snapper and without. Probably it is even possible to achieve a snapper compatible setup without snapper. For completeness the rough steps for an upgrade are: # Get current snapshot
current=$(snapper --csvout list --columns number,active | grep yes | cut -d"," -f1)
# Create new snapshot from current
id=$(snapper create --from ${current} --read-write --print-number --description "Snapshot Update of #${current}" --userdata "update-in-progress=yes")
# Apply image to the new snapshot
elemental pull-image --local ${osimage} /mnt/@/.snapshots/${id}/snapshot/
snapper modify --userdata "update-in-progress=no" $id
# Make snapshot RO
btrfs property set /.snapshots/${id}/snapshot ro true See here snapper is only used for the creation of a new subvolume. |
Thanks for information. I'll try the following (not sure yet for the grub part)
If grub is unable to test for snapshot directory I'll search for another solution. The property name comes from the original problem which is that other distro's grub do not handle properly default subvolumes. |
Now able to boot orange on btrfs. elemental upgrade works in recovery but not in active state due to snapper configuration |
e437f86
to
e20d8e2
Compare
- remove btrfs default subvolume, - save btrfs device in Btrfs structure, - rework brtfs state mountpoint detection (uses btrfs device, got rid of rootSubvolID and snapshotsSubvolID constants), - add 'active' relative symlink to active snapshot (updated in CloseTransaction() and read in getActiveSnapshot()), - add grub 'active_snap' variable (could it be replaced by dracut resolving the 'active' link ?), - add grub 'root_subpath' variable which allows to prefix kernel and initrd image with a subpath, - handle grub modules packaging under /usr/lib/elemental/bootloader - add RelativizeLink() to recursively make symbolic links relative, - ensure kernel and initrd are relative links (allow grub to process without mounting subvolume) - update orange Dockerfile
orange now boots on btrfs snapshotter. - grub configuration can now work without default subvolume - moved kernel link relativize call
- added two configuration booleans for btrfs - elemental upgrade is now working on orange flavor - orange iso builds and install in btrfs Still have to implement the 'max-snaps' when snapper is disabled. Try to make snapper configuration work on orange too btrfs configuration: - disable-snapper: disable snapper usage and rely only over btrfsprogs. tested on orange and green - disable-default-subvolume: disable subvolume get/set-default (as it is an incompat feature of btrfs). When default subvolume usage is disabled, a symlink is used in the state dir to find active snapshot. It is not possible to disable default subvolume usage while using snapper (an error is returned). TODO: - try to rework snapper based snapshotter - implements 'max-snaps'
af3bde8
to
67fbaa4
Compare
need to fix test-cli and more checks for error handling. install, reset and upgrade is tested and working on green/orange Changelog: - reintroduced state directories variables, it makes code simpler, - changed grub configuration. It should allow downgrades, - snapper configuration is now created using a chroot in the snapshot, - snapper initial snapshot bootstrap has changed (rely on snapper chroot initial snapshot creation), - removed snapper xml code (handled by snapper itself), - fixed old snapshot deletion, - added snapper wrappers to run inside chroot or in current context, - default btrfs subvolume is always updated
67fbaa4
to
b19d09f
Compare
I'm actually near the end of snapshotter modifications. I've added two booleans for configuration
The real needed change for orange to boot with own bootloader is the grub variable (since 'set btrfs_relative_path="y"' has no effect at all). I've managed to get snapper running with Ubuntu (However sometimes it takes time to enable snapper on first boot, making elemental upgrade fail until fully snapperd is fully bootstraped). I've done the following changes for snapper bootstrap (it's not actually real shell code) :
This process is compatible at least with orange and green flavor. It's heavier than the previous process but I find it more proof to distro specific file path for templates (root snapper config was not created in Ubuntu). What do you think about it ? Have you got any advice before I work to fix test-cli make target ? I may need help to fix tests which need chrooted calls. |