When OSTree deploys a new configuration, it creates a systemd configuration file with a +3 tag in the name, indicating the maximum retry count, such as ostree-boot+3.conf. This enables boot counting.
systemd-boot detects the +3 tag in the configuration file name and renames it to ostree-boot+2-1.conf, indicating that one boot attempt has started. After renaming the file, the boot process continues.
The systemd-bless-boot-generator creates the systemd-bless-boot.service, which starts when boot-complete.target is reached. If there are any failures during the Linux boot-up, the systemd-bless-boot.service does not remove the +2-1 counter tags from the configuration file.
On the subsequent boot, systemd-boot detects the +2-1 tag in the configuration file name, renames the file to ostree-boot+1-2.conf, and tries to boot with it.
If the Linux bootup fails on the second attempt, the systemd-bless-boot.service does not remove the counter tags +1-2 from the configuration file.
On the next boot, systemd-boot detects the +1-2 tag in the configuration file name, renames the file to ostree-boot+0-3.conf, and tries to boot with it. This is the last attempt to boot Linux deployment.
If the device fails to bootup Linux during the third attempt, the systemd-bless-boot.service does not remove the counter tags +0-3 from the configuration file.
On the subsequent boot, systemd-boot finds the +0-3 tag in the configuration file name. As the counter has reached zero, the entry (configuration file) is considered bad. The systemd-boot reverts to an earlier version by trying the valid configuration file entry.
|
- **Usrmerge**
The usrmerge feature in Linux simplifies the filesystem layout by merging certain directories under `/usr` path.
It combines `/bin`, `/sbin`, and `/lib` with `/usr/bin`, `/usr/sbin`, and `/usr/lib`, respectively.
With usrmerge, executables and libraries found in `/bin`, `/sbin`, and `/lib` are placed in `/usr/bin`, `/usr/sbin`, and `/usr/lib`.
The original directories become symbolic links to their /usr counterparts. This unified structure makes maintenance easier and reduces
redundancy, as there is only one location for binaries and libraries instead of separate location for root-level and `/usr` directories.
Symbolic links ensure compatibility, allowing scripts and software that reference paths like `/bin` to continue functioning.
Linux distributions are adopting usrmerge to align with the filesystem hierarchy standard (FHS) recommendations and simplify root
filesystems, especially in containerized and embedded systems.
Distributions like Debian, Ubuntu, and Fedora have adopted usrmerge as part of their system layout, making it a standard in recent versions.
The transition involves creating symbolic links and moving any remaining files from the original directories to their `/usr` equivalents.
In summary, the usrmerge feature consolidates the Linux filesystem, making it more manageable, modernized, and aligned with the evolving
needs of system management and containerization.
- **Management of** `/var`, `/home`, `/media`, `/mnt`, `/opt`, `/srv`, **and** `/usr` **in Qualcomm Linux**
>
>
> OSTree considers `/var` as a persistent directory. This means user/runtime
> created contents under `/var` remian untouched by OSTree and persist across OTA updates.
> For more information, see [OSTree Overview](https://ostreedev.github.io/ostree/introduction/).
>
>
> Other directories that remain untouched by OSTree during an OTA update are `/home`, `/media`, `/mnt`, `/opt`, and `/srv`.
> OSTree maps these directories as symbolic links as follows:
>
> - `/home` is a symbolic link to `/var/rootdirs/home`
> - `/media` is a symbolic link to `/var/rootdirs/media`
> - `/mnt` is a symbolic link to `/var/rootdirs/mnt`
> - `/opt` is a symbolic link to `/var/rootdirs/opt`
> - `/srv` is a symbolic link to `/var/rootdirs/srv`
>
>
>
> Any runtime data stored under `/home`, `/media`, `/mnt`, `/opt`, `/srv`, and `/var` stays persistent
> across OTA updates.
>
>
> To maintain a clean and consistent filesystem, OSTree recommends not to install any artifacts under
> the above directories at build-time. Any artifacts installed in these directories during build-time are
> not packaged into the rootfs image generated by the Qualcomm Linux build command, that is, `bitbake