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 is0, 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 specialostree=kernel argument that allows the initramfs to find (andchroot()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.
1 Like
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?
Question- Is it possible to change the number of the deployment? e.g. I want to change deployment 1 to deployment 0, so that the next reboot can use it by default
Use rpm-ostree rollback.
My issue is I’ve already rolled back. Because there’s usually a staged deployment taking up the spot of “0”, my current deployment is at spot “1”
If you have “rolled back” by booting the rollback deployment (1) from the bootloader, then rpm-ostree rollback will swap them so that the booted deployment becomes the default (0).
It might be easier to explain if you share the output of rpm-ostree status
Actually nvm. I found my issue (SDDM needs manual re-starting during bootup) is deployment agnostic.
I see the same thing using FCOS on Raspberry 4
here is my output
admin@CoreOS:~$ rpm-ostree status
State: idle
warning: Failed to query journal: couldn't find current boot in journal
AutomaticUpdatesDriver: Zincati
DriverState: active; periodically polling for updates (last checked Wed 2025-01-01 13:39:59 UTC)
Deployments:
â—Ź fedora:fedora/aarch64/coreos/stable
Version: 41.20241122.3.0 (2024-12-16T21:54:30Z)
BaseCommit: 4c2285b3993e7c505ae167fbcf1d14dfa353a7c05732c79e7ecd67732e74ef55
GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1
LayeredPackages: brcmfmac-firmware NetworkManager-wifi
fedora:fedora/aarch64/coreos/stable
Version: 41.20241122.3.0 (2024-12-16T21:54:30Z)
Commit: 4c2285b3993e7c505ae167fbcf1d14dfa353a7c05732c79e7ecd67732e74ef55
GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1