The Initramfs: regenerate means that whenever there is a new image pulled from the cloud (aka when updates happen), rpm-ostree automatically regenerates the initramfs on your computer during the deployment stage.
The two deployments have identical SHA256 checksum and version because they are the same “image” rpm-ostree pulled from the cloud. I’m guessing you did an rpm-ostree operation that changed the deployment before.
on that topic, does the output of ‘status’ correspond to the rollback options we see in GRUB? And would that mean that adding packages via rpm-ostree install removes some level of backup?
By default, without any modifications, rpm-ostree keeps two deployments: 0 and 1. 0 is the default deployment (≈ default GRUB entry) that the system boots into, 1 is the default rollback deployment.
When you run a system update (rpm-ostree update), upon success the system will have three deployments instead of two. The previous default deployment becomes 1 instead of 0, and becomes the next default rollback deployment. The previous rollback deployment becomes 2 instead of 1, and in addition, it will be marked for deletion. The updated system becomes the 0 deployment, and the system will boot into it the next time your computer is re/started.
This also applies to other changes made to the deployment specifications using rpm-ostree. So let’s say you enable/disable initramfs regeneration, add/remove/modify kernel arguments, manage base package overrides, install/layer RPM packages, rebase, etc.
So technically, rpm-ostree does remove unused rollback deployments by default. This happens not just when you layer packages, but also when system updates happen.
You can alter this behavior by pinning a deployment so they don’t get marked for deletion. The pinned deployment will remain bootable until you unpin it, after which an rpm-ostree update may remove it from your system.