Is there is way to predict whether it will /ostree/boot.0 or /ostree/boot.1 after next reboot?

For some reason I need to know whether after installation of rpm pacakges for the next reboot /ostree/boot.0 or /ostree/boot.1 will be used So far I could not find out how to know in front what this will be.

I currently am not in front of the installation but maybe grep/cut it from rpm-ostree status output?
PS: I am curious about the reason.

The reason I am trying to find out is this:

I wrote some small script in order to be able to get rid of grub on a Fedora Silverblue system.

As you can see my script tries to find the right deployment in order to write a loader entry.

This works ok if I do “rpm-ostree upgrade”. I cannot remember it failed just doing this.

But for installing and/or removing rpms this is another story. Suddenly it is changed from /ostree/boot.0 to /ostree/boot.1 or the other way round. Or there is not change at all. Also there is no hint that it will change before booting. I checked the /boot/efi/EFI/fedora/grub.cfg before such a change took place and the result was that it changed but not before next boot.

I have not idea what this os-tree stuff is doing. I have read this:

https://people.gnome.org/~walters/ostree/doc-onepage/

but also did not find a hint from what to know before I boot whether it will be boot.0 or boot.1.

I guess it will be possible but so far I did not find out. “rpm-ostree status” is not the answer.

I looked at the output of rpm-ostree status -v and ostree admin status -v
which gives not what you are looking for, maybe ask at the ostree mailing list.

https://ostree.readthedocs.io/en/latest/manual/atomic-upgrades/#the-bootversion

The bootversion

OSTree allows swapping between boot configurations by implementing the “swapped directory pattern” in /boot . This means it is a symbolic link to one of two directories /ostree/boot.[0|1] . To swap the contents atomically, if the current version is 0 , we create /ostree/boot.1 , populate it with the new contents, then atomically swap the symbolic link. Finally, the old contents can be garbage collected at any point.

Yes. But when exactly will this happen and how can I check this?

Example: when I update my system I have let’s say boot.0. When I now install a new rpm package I have to use boot.1 - otherwise I get a blank screen. When I install another rpm after this it will stay boot.1.

This I know now from experience. The problem is I would like to know before rebooting my system whether I have to change my boot config or not.

I assume you’ll get the same boot.<number> when your update doesn’t include kernel.
The swapping itself seems occurs on reboot.

You would need to use ostree itself for that. Reading of their doc’s would seem to indicate that commit 0 is default always. There is also an option with rpm-ostree to pin a specific commit you wish to keep which can be a way to have more than two commits. In any case, the default one chosen for next boot would normally be 0. When you update the ostree the new commit becomes 0 after the command that made changes to the ostree is issued, and the commit that was 0 becomes commit 1, while the commit that was 1 gets dropped as an option. Pinned commits will remain unchanged in status as far as I can tell, but you’d have to verify that.
From ostree docs

When a tree is deployed, it will have a configuration file generated of the form /boot/loader/entries/ostree-$stateroot-$checksum.$serial.conf . This configuration file will include a special ostree= kernel argument that allows the initramfs to find (and chroot() into) the specified deployment.

That documentation is here. It may be necessary for you to look for the developers documentation of Ostree. There is a file Silverblue uses, comp-sync.py which I believe is the file responsible for generating the necessary metadata to build the local commit based upon the newly deployed image from the repo and the current layering being used, but that is supposition on my part as of yet since I didn’t dig deeper into it.
And talking of rpm-ostree, which is what Silverblue uses, you may want to look here for more details on what is happening during the new commit process. Repository Management seems to be what you are after WRT the info required to predict the next boot. It is also worth looking at how the boot loader is informed (above link for Ostree) since that is the information you are basically needing.

Sorry for offtopic, I’ve created my custom /boot/loader/entries/my.conf file, and after upgrade it’s just gone!
Maybe you guys know why is this?