What's new in OSTree 2019.2
Apr 30, 2019
- New features:
- A new sysroot.bootloader key was added to be more explicit about which bootloader OSTree should use. Notably a none value is supported, in which OSTree is solely responsible for writing the BLS entries. This can then be used by bootloaders like GRUB2, which now supports BLS natively. (#1814)
- ostree config now supports the unset command to unset a key from the OSTree repo config (#1743)
- ostree remote add now supports the --force flag to replace a remote of the same name if it exists (#1166)
- ostree-prepare-root now logs a structured journal message after finding the deployment to which to pivot. This can be used by higher-level apps like RPM-OSTree to build a history of the deployments the machine was booted into. (#1842)
- The staging API now supports a lockfile which prevents finalization at shutdown. This is intended to be used in systems like Fedora CoreOS, which needs more fine-tuned control between staging a deployment, and setting it as the default deployment on reboot. (#1841)
- ostree static-delta show now prints the From and To commits for which the delta was generated (#1823)
- Bug fixes:
- Make looking up collection-refs similar to how regular refs are looked up, i.e. first in the transaction, then in the current repo, and then in the parent repo (#1821)
- Don't include the OSTree commit version number twice in the boot menu title. This affected at least Fedora-based systems composed with
- RPM-OSTree's mutate-os-release. (#1829)
- Activate ostree-finalize-staged earlier; this should hopefully make deployment finalization more reliable by running it later in the shutdown sequence, when less services are running (#1840)
- Run grub2-mkconfig on the filesystem tree of the pending deployment, rather than the previously deployed tree. This was a corner case where the deployment failed if a previous deployment did not exist, on systems where grub.cfg is used. (#1831)