Describe the bug
No clear way how to change deployment number if it's incorrect - use 0 instead of 1, or 1 instead of 0.
Like I have now:
Job for rpm-ostreed.service failed because the control process exited with error code.
See "systemctl status rpm-ostreed.service" and "journalctl -xeu rpm-ostreed.service" for details.
× rpm-ostreed.service - rpm-ostree System Management Daemon
Loaded: loaded (/usr/lib/systemd/system/rpm-ostreed.service; static)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: failed (Result: exit-code) since Sun 2024-01-28 17:48:13 AST; 29ms ago
Docs: man:rpm-ostree(1)
Process: 106412 ExecStart=rpm-ostree start-daemon (code=exited, status=1/FAILURE)
Main PID: 106412 (code=exited, status=1/FAILURE)
Status: "error: Couldn't start daemon: Error setting up sysroot: loading sysroot: Parsing deployment /ostree/boot.0/fedora/a09b0c8e25c11f61c9e23b00dfd8296593df43b2a111d1b068a4ee39f1687ae8/0 in stateroot 'fedora': readlinkat: No such file or directory"
CPU: 18ms
Jan 28 17:48:13 xenya.local systemd[1]: Starting rpm-ostreed.service - rpm-ostree System Management Daemon...
Jan 28 17:48:13 xenya.local rpm-ostree[106412]: Reading config file '/etc/rpm-ostreed.conf'
Jan 28 17:48:13 xenya.local rpm-ostree[106412]: error: Couldn't start daemon: Error setting up sysroot: loading sysroot: Parsing deployment /ostree/boot.0/fedora/a09b0c8e25c11f61c9e23b00dfd8296593df43b2a111d1b068a4ee39f1687ae8/0 in stateroot 'fedora': readlinkat: No such file or directory
Jan 28 17:48:13 xenya.local systemd[1]: rpm-ostreed.service: Main process exited, code=exited, status=1/FAILURE
Jan 28 17:48:13 xenya.local systemd[1]: rpm-ostreed.service: Failed with result 'exit-code'.
Jan 28 17:48:13 xenya.local systemd[1]: Failed to start rpm-ostreed.service - rpm-ostree System Management Daemon.
error: Loading sysroot: exit status: 1
ls -l /ostree/
total 12
drwxr-xr-x. 3 root root 4096 Jan 24 19:29 boot.0.1
lrwxrwxrwx. 1 root root 9 Jan 24 19:32 boot.1 -> boot.0.1/ #I've created this simlink in the grub-shell, to be able to boot system
drwxr-xr-x. 3 root root 4096 Jan 24 19:29 deploy
drwxr-xr-x. 7 root root 4096 Jan 24 19:29 repo
To Reproduce
Confuse silverblue with deployment number somehow, try to find documentation how to fix it, and find out, that there is no clear way how to fix problem
Expected behavior
1) A clear way, a command, or maybe configuration option, which should force ostree, rpm-ostree, etc use user-defined deployment number. Like 1, even if it's supposed to use 0, or 0 if it's supposed to use 1. And related documentation.
2) Clear way, how to force ostree/rpm-ostree use another number for next deployment, different than supposed. And related documentation
Screenshots
If applicable, add screenshots to help explain your problem.
rpm-ostree status -b
error: Loading sysroot: Failed to invoke RegisterClient: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer: startup job failed.
Additional context
Overall, Silverblue is very nice distro, but it's really lack of documentation about low-level hacks, how to fix things, if something is going bad, and not expected way.
Describe the bug No clear way how to change deployment number if it's incorrect - use 0 instead of 1, or 1 instead of 0.
Like I have now:
To Reproduce Confuse silverblue with deployment number somehow, try to find documentation how to fix it, and find out, that there is no clear way how to fix problem
Expected behavior 1) A clear way, a command, or maybe configuration option, which should force ostree, rpm-ostree, etc use user-defined deployment number. Like 1, even if it's supposed to use 0, or 0 if it's supposed to use 1. And related documentation. 2) Clear way, how to force ostree/rpm-ostree use another number for next deployment, different than supposed. And related documentation
Screenshots If applicable, add screenshots to help explain your problem.
OS version:
Additional context Overall, Silverblue is very nice distro, but it's really lack of documentation about low-level hacks, how to fix things, if something is going bad, and not expected way.