Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support locking an existing staged deployment with --download-only

Aperta
  • Qualcosa non va?
#2,425 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
operating-systems

Direzione di ricerca

Inizia riproducendo bootc switch --download-only con un'immagine già predisposta sui backend OSTree e composefs, quindi traccia la gestione dello stato del deployment predisposto. Il lavoro è completato quando uno stage sbloccato diventa bloccato senza modificare la sua immagine o il suo digest, uno stage già bloccato rimane invariato e le modifiche non supportate restituiscono un errore chiaro.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

triaged

Problem

Running bootc switch --download-only for the same image that is already
staged does not convert the staged deployment from unlocked to download-only.
Instead, bootc exits successfully without changing the staged deployment:

Image specification is unchanged.

The staged deployment continues to report:

{
  "downloadOnly": false
}

This means management software cannot safely enable a policy requiring an
explicit apply operation after the image has already been staged.

The result was reproduced on both:

  • OSTree backend using XFS
  • composefs backend using ext4, GRUB and BLS

Both returned Image specification is unchanged. with exit status 0, and both
left status.staged.downloadOnly set to false.

The OSTree-specific ostree admin lock-finalization command may provide a
low-level workaround, but it is not a backend-independent bootc interface.

Background Why this matters https://github.com/bootc-dev/bootc-operator/pull/151

While implementing RequireSoftReboot support in bootc-operator, we need to
guarantee that a staged deployment cannot be applied by an ordinary reboot
before the operator explicitly applies it.

For RequireSoftReboot, the operator must ensure that an ordinary reboot
cannot accidentally apply the staged image.

If RequireSoftReboot is enabled after an update was staged normally,
bootc-operator currently cannot safely lock that existing stage. It must reject
the policy transition and report SoftRebootStageUnlocked.

Expected Behavior:

If changing the state is unsupported, the command should return a clear error
instead of successfully reporting that the image specification is unchanged.

The operation should ideally be idempotent:

  • An unlocked staged deployment becomes locked.
  • An already locked deployment remains locked.
  • The selected image and digest do not change.

A backend-independent bootc operation would let the operator safely adopt the
existing stage instead.

Lingua principale
Rust
Stelle
2.3k
Fork
230
Merge medio
2g 21h
PR unite (30g)
45

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bootc-dev/bootc

Tutte le issue di bootc-dev/bootc

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.