Repository navigation
Conversation
mcanevet
force-pushed
the
fix/dell-secure-boot-via-bios-attribute
branch
from
September 11, 2026 15:02
3adc447 to
d4d282f
Compare
mcanevet
marked this pull request as draft
September 11, 2026 15:03
mcanevet
force-pushed
the
fix/dell-secure-boot-via-bios-attribute
branch
4 times, most recently
from
September 17, 2026 14:04
2040fcb to
53ec95f
Compare
mcanevet
force-pushed
the
fix/dell-secure-boot-via-bios-attribute
branch
4 times, most recently
from
September 25, 2026 07:54
beea028 to
33e8a5f
Compare
ApplyBiosAttributes writes BIOS attributes keeping their native JSON types (bool, number, string), for callers that resubmit attributes they read back from the BMC, where stringifying a value could be rejected by a strict attribute registry. SetBiosConfiguration now delegates to it, so the apply-time handling exists once. Jobs lists the jobs of the Redfish JobService, in a single request on a BMC that supports $expand: a used iDRAC holds well over a hundred jobs, and reading them one by one takes a request each. Both are used by the Dell provider to merge a BIOS write into an already pending job. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>
iDRAC allows one pending BIOS config job at a time. Any write to Bios/Settings, or to a resource that mirrors a BIOS attribute such as the SecureBoot resource, seals that job, and every further write is rejected with SYS011 until the job is deleted or has run. Two BIOS-affecting calls in one boot cycle therefore fail on the second, although both would apply together at the next reset. SetBiosConfiguration now reads the pending attributes before writing: - Nothing pending: a plain write, as before. - Something pending: delete the live job (only if it has not started applying), merge the requested attributes over the staged ones and write once. The merge carries attributes an earlier caller staged, because iDRAC keeps a single job and deleting it discards what it staged. If the merged write fails, the attributes the deleted job held are staged again and the error says whether that worked. The deletion is logged. - Every requested attribute already at the requested value, staged or, where nothing is staged for it, applied, with a live job carrying the staged ones: nothing is done, so repeating a call is idempotent. A SYS011 the read could not foresee is returned to the caller, with a note when no job could be found to delete. The sequence is not safe against another client writing BIOS settings on the same BMC at the same time. A job is recognized by Oem.Dell.JobType or by its "ConfigBIOS:" name, as not every iDRAC generation returns an Oem block in the JobService collection. It is deleted only in a state in which it has not started, and only if Dell's own job resource, the one the firmware code already reads, shows no ActualRunningStartTime: that resource reports it on every generation. A pending job shows "Scheduled" or "Starting" depending on the generation; gofish's JobState set has neither. Unknown states are refused rather than assumed safe. Tested against a PowerEdge R760xd2 (iDRAC 7.30.10.50) and a PowerEdge R6715 (iDRAC 1.20.80.51). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>
Dell's SetSecureBoot delegated to the shared Redfish implementation, which PATCHes the standard ComputerSystem SecureBoot resource's SecureBootEnable property. That PATCH unconditionally creates iDRAC's one exclusive BIOS Configuration Job, so it is order-dependent: run before another Bios/Settings write in the same boot cycle, it makes that later write fail with SYS011; the reverse order merges cleanly because no job exists yet. PATCH the SecureBoot BIOS Setup attribute via SetBiosConfiguration instead, so SetSecureBoot goes through the same Bios/Settings path as every other Dell BIOS-backed setter. A write made before or after it, in the same boot cycle, is then merged into the same pending job instead of being rejected. Behaviour is otherwise unchanged: the write is staged into Bios/Settings and takes effect on the next POST. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>
mcanevet
force-pushed
the
fix/dell-secure-boot-via-bios-attribute
branch
from
October 2, 2026 11:04
33e8a5f to
7760036
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Dell's SetSecureBoot delegated to the shared Redfish implementation, which PATCHes the standard
ComputerSystemSecureBootresource'sSecureBootEnableproperty. iDRAC mirrors that property to its ownSecureBootBIOS Setup attribute, but only the BIOS Setup attribute fits Dell's BIOS staging model.Depends on #467 - this branch is rebased on top of it, so the diff here includes #467's commits until that one merges.
The
ComputerSystemSecureBootresource has an order-dependent bug: PATCHing it unconditionally creates a real, exclusive BIOS Configuration Job immediately (no@Redfish.SettingsApplyTimeneeded or even accepted on that resource). If that PATCH runs before anotherBios/Settingswrite in the same maintenance window, the later write fails withIDRAC.2.14.SYS011, naming the attribute it was trying to set even though that attribute was never touched before. The reverse order merges cleanly, only because no job yet exists when the resource PATCH runs — confirmed with a same-box, order-only-swapped A/B.That made
SetSecureBootthe one call in this package that could break an otherwise-safe sequence of BIOS-affecting writes, purely because of which resource it targeted. This PATCHes theSecureBootBIOS Setup attribute directly viaSetBiosConfigurationinstead, soSetSecureBootgoes through the same path as every other Dell BIOS-attribute setter: with #467, a write made before or after it in the same boot cycle is merged into the same pending job instead of being rejected. (Checked on an R6715: a PATCH to theSecureBootresource shows up asSecureBootinBios/Settings, which is what lets #467's pending-attributes read see the job it seals.)Behavior is otherwise unchanged: the write stages into
Bios/Settingsand takes effect on the next POST, exactly as it did through theSecureBootresource.