support configuring host to retain more than two deployments

[dustymabe]

Right now when you upgrade you get the latest deployment and the previous one you were on so that you can rpm-ostree rollback. It would be nice if we could configure this behavior so that you can keep multiple deployments locally to switch back and forth to for debugging purposes.

AFAICT this is really only useful for debugging.

[dustymabe]

related: ostreedev/ostree#1460

[dustymabe]

is this taken care of by ostreedev/ostree#1464 or is there another PR needed?

[matthiasclasen]

See this story https://blogs.gnome.org/mclasen/2018/03/22/fedora-atomic-workstation-almost-fool-proof/ for some of the unintended consequences that can occur with the combination of package layering and a fixed number of deployments

[jlebon]

See this story https://blogs.gnome.org/mclasen/2018/03/22/fedora-atomic-workstation-almost-fool-proof/ for some of the unintended consequences that can occur with the combination of package layering and a fixed number of deployments

FWIW, ostreedev/ostree#1960 will fix this.

[andreldmonteiro]

This is not only useful for debugging, for one I would like to customize the number of deployments.

[sandorex]

I hate to be that guy, but what is status of this issue?

[jlebon]

I hate to be that guy, but what is status of this issue?

It's not being actively worked on AFAIK. Note that nowadays, there's ostree admin pin to prevent specific deployments from being GC'ed.

[xrishox]

i would also like to see support for this added. pinning definitely is nice, but there are times where i'm futzing around with stuff where i don't realize at the time i should be pinning a safe deployment and by the time i realized i've caused problems for myself i'm 5 deployments deep and the original safe deployment is long gone.

[brettgilio]

i would also like to see support for this added. pinning definitely is nice, but there are times where i'm futzing around with stuff where i don't realize at the time i should be pinning a safe deployment and by the time i realized i've caused problems for myself i'm 5 deployments deep and the original safe deployment is long gone.

Adding on to this, it would be potentially nice for an option to not only retain a full set of deployments, but also have any unpinned deployments be GC'ed after an indicated time delay. For example, retain all deployments for 30 days, and any deployment at 30+n days in age would be hit by the GC unless it is marked as pinned.

[cig0]

I like the OSTree approach, running Universal Blue on my laptop and my battle station (Kinoite). However, having only one recovery deployment by default severely limits the ability to recover a system from an unwanted/mis-triggered change.

On the other hand, having to manually pin a deployment before a potentially disruptive upgrade (kernel upgrade, Wayland stack upgrade, etc.) creates significant friction when enabling automatic updates.

Allowing at least a bunch of deployments ready to boot from (i.e., openSUSE MicroOS keeps the last five snapshots by default) would significantly provide more substantial protection.

[awebeer256]

As another point of comparison, NixOS lets you just type in a number and that's how many it'll keep. It defaults to 100 if you use Grub and infinity if you use systemd-boot (source).

[waifairer]

I’d love to contribute this enhancement. Does anyone have any pointers for doing so?

[westurner]

FWICS,

• copy_kernel_into updates /boot or /usr/lib/ostree/boot

  • rpm-ostree/src/libpriv/rpmostree-kernel.cxx

    Lines 311 to 314 in 3c9febf

    	copy_kernel_into (int rootfs_dfd, const char *kver, const char *boot_checksum_str,
    	const char *kernel_modules_path, const char *initramfs_modules_path,
    	gboolean only_if_found, const char *bootdir, GCancellable *cancellable,
    	GError **error)

• Keep last version of deployment ostreedev/ostree#1960

  • https://github.com/ostreedev/ostree/pull/1960/files

• https://github.com/ostreedev/ostree/blob/main/src/ostree/ot-admin-builtin-deploy.c

  • ‎ot_admin_builtin_deploy‎
    • https://github.com/search?q=repo%3Aostreedev/ostree%20os_admin_builtin_deploy&type=code
  • ostree_sysroot_simple_write_deployment
    • https://github.com/search?q=repo%3Aostreedev/ostree%20ostree_sysroot_simple_write_deployment&type=code
    • OSTREE_SYSROOT_SIMPLE_WRITE_DEPLOYMENT_FLAGS_RETAIN_PENDING
    • OSTREE_SYSROOT_SIMPLE_WRITE_DEPLOYMENT_FLAGS_RETAIN_ROLLBACK
    • OSTREE_SYSROOT_SIMPLE_WRITE_DEPLOYMENT_FLAGS_RETAIN_PREVIOUS_VERSION
    • OSTREE_SYSROOT_SIMPLE_WRITE_DEPLOYMENT_FLAGS_RETAIN = .. & ..

• https://github.com/ostreedev/ostree/blob/main/src/ostree/ot-admin-instutil-builtins.h

  • ot_admin_builtin_pin
    • https://github.com/ostreedev/ostree/blob/main/src/ostree/ot-admin-builtin-pin.c#L82
  • ot_admin_instutil_builtin_grub2_generate
    • https://github.com/ostreedev/ostree/blob/main/src/ostree/ot-admin-instutil-builtin-grub2-generate.c#L31
    • https://github.com/search?q=repo%3Aostreedev/ostree%20ot_admin_instutil_builtin_grub2_generate&type=code

• /? grub (coreos/rpm-ostree)
  https://github.com/search?q=repo%3Acoreos%2Frpm-ostree+grub&type=code

  • https://github.com/coreos/rpm-ostree/blob/main/tests/vmcheck/test-layering-basic-2.sh
    • assert_file_has_content grubenv.txt grubenv

• /? grub (ostreedev/ostree)
  https://github.com/search?q=repo%3Aostreedev%2Fostree%20grub&type=code

  • https://github.com/ostreedev/ostree/blob/main/src/boot/grub2/ostree-grub-generator#L108 ; src/boot/grub2/ostree-grub-generator

[westurner]

From #1239 (comment) :

Including in the GRUB label whether something is pinned or not, and at what pin location (e.g. pin 0, pin 1) would be useful.

I also agree with the OP that custom labels would be useful, but specifically for pinned deployments - e.g. 'New Install', 'Pre-rebasing 37 to 38', etc. Optional, of course, as some users wouldn't use this feature, but would make the GRUB entries much easier to navigate for those that do.