osbuild: add force option to org.osbuild.groups and always enable [HMS-9825] by achilleas-k · Pull Request #2146 · osbuild/image-builder

achilleas-k · 2026-01-19T12:24:08Z

The --force option of the groupadd command makes it possible to run with a group name or GID that already exists without failing. This is very useful for letting users define groups in their configs without worrying about the group existing in the base system or being created from a package, which isn't always predictable.

See osbuild/image-builder#2146

achilleas-k · 2026-01-19T15:33:31Z

Cross-arch qemu based image build/boot smoke test will be fixed by #2145

bcl · 2026-01-19T18:18:47Z

+func TestNewGroupsStageOptions(t *testing.T) {
+	type testCase struct {
+		groups     []users.Group
+		expOptions *GroupsStageOptions


I didn't initially parse this as meaning expected options :) I see we've used both expOptions and expectedOptions in various places so it might be nice to just use the long form.

bcl

Looks good, I don't feel too strongly about the naming of expOptions :)

achilleas-k · 2026-01-19T21:24:22Z

I don't feel too strongly about the naming of expOptions :)

hah, funny you should mention it, I felt it was a bit too lazy to call it that, paused for a second, thought I shouldn't spend much time thinking hard about a variable name in a tiny test, and moved on.

thozza

In general, LGTM.

I've added a few comments. I think that the behavior of the --force option with two groups with the same GIDs is worth addressing, but could be in a follow up or as a documentation.

thozza · 2026-01-20T07:13:42Z

+		// groups in their configs without worrying about the group existing in
+		// the base system or being created from a package, which isn't
+		// predictable. Enable it unconditionally for all builds
+		Force: true,


Nitpick: After reading the man page, it also When used with -g, and the specified GID already exists, another (unique) GID is chosen (i.e. -g is turned off).. This means that if a user specifies two different groups with the same GID in the BP, one of them will get a different GID and the build will pass. This behavior should be probably called out explicitly, or we should have an option validation to catch it and don't generate such manifest.

You're right. We can't control for conflicts between the blueprint and the packages/system, but we should make things more predictable by keeping the blueprint sane at least and error on duplicates, even though it would technically work. I think that wouldn't be surprising or unusual behaviour.

That might be more appropriate for validation in the blueprint itself though.

The note I added to the blueprint reference covers the GID behaviour too, though maybe that's not entirely clear either: https://github.com/osbuild/osbuild.github.io/pull/188/changes

ACK. Documentation and validation on the BP level sound good to me!

This version introduced the 'force' option in org.osbuild.groups. It's also the current latest release.

The --force option of the groupadd command makes it possible to run with a group name or GID that already exists without failing. This is very useful for letting users define groups in their configs without worrying about the group existing in the base system or being created from a package, which isn't always predictable.

The wheel group is created by the setup package on all systems by default. Before our use of the force option, this would fail. This new config now tests that the build doesn't fail since we enable the force option unconditionally.

achilleas-k · 2026-01-21T11:31:51Z

Here we go: osbuild/blueprint#43

See osbuild/image-builder#2146

This bumps the osbuild/images to the version that uses depsolver V2 API. Also bump the minimum required osbuild version and pin it in the Schutzfile. Changes with 0.235.0 ---------------- - Align the bootc distro package with the generic one (osbuild#2136) - Author: Achilleas Koutsou, Reviewers: Lukáš Zapletal, Tomáš Hozza - Ensure pinned osbuild version is used consistently in CI and build command. (HMS-10070) (osbuild#2145) - Author: Tomáš Hozza, Reviewers: Achilleas Koutsou, Simon de Vlieger - GHA: bump used golangci-lint version to 2.8 (HMS-10069) (osbuild#2144) - Author: Tomáš Hozza, Reviewers: Achilleas Koutsou, Lukáš Zapletal - Update osbuild dependency commit ID (osbuild#2141) - Author: SchutzBot, Reviewers: Achilleas Koutsou, Tomáš Hozza - Use the correct libvirt pool instead of hardcoded default (osbuild#2147) - Author: Jakub Kadlčík, Reviewers: Achilleas Koutsou, Simon de Vlieger - boot-image: add make_check_host_config to boot-aws (osbuild#2143) - Author: Lukáš Zapletal, Reviewers: Simon de Vlieger, Tomáš Hozza - osbuild: add force option to org.osbuild.groups and always enable [HMS-9825] (osbuild#2146) - Author: Achilleas Koutsou, Reviewers: Brian C. Lane, Lukáš Zapletal, Tomáš Hozza — Somewhere on the Internet, 2026-01-26 --- Changes with 0.236.0 ---------------- - Add V2 depsolver API support and make it the default (HMS-10029) (osbuild#2139) - Author: Tomáš Hozza, Reviewers: Lukáš Zapletal, Simon de Vlieger — Somewhere on the Internet, 2026-01-26 Signed-off-by: Tomáš Hozza <thozza@redhat.com>

This comment was marked as outdated.

Sign in to view

achilleas-k force-pushed the stages/groups/force branch from 4df7153 to ba4f47e Compare January 19, 2026 14:33

achilleas-k marked this pull request as ready for review January 19, 2026 14:33

achilleas-k requested a review from a team as a code owner January 19, 2026 14:33

achilleas-k requested review from bcl, lzap and thozza January 19, 2026 14:33

achilleas-k added a commit to osbuild/osbuild.github.io that referenced this pull request Jan 19, 2026

blueprint-reference: add note describing new groups behaviour

a95da2f

See osbuild/image-builder#2146

achilleas-k mentioned this pull request Jan 19, 2026

blueprint-reference: add note describing new groups behaviour osbuild/osbuild.github.io#188

Merged

bcl reviewed Jan 19, 2026

View reviewed changes

osbuild: add test for NewGroupsStageOptions()

84cc558

thozza force-pushed the stages/groups/force branch from ba4f47e to 2d14832 Compare January 19, 2026 18:20

bcl approved these changes Jan 19, 2026

View reviewed changes

thozza approved these changes Jan 20, 2026

View reviewed changes

achilleas-k added 3 commits January 20, 2026 12:39

deps: set required osbuild version to 169

219b7dc

This version introduced the 'force' option in org.osbuild.groups. It's also the current latest release.

test: add "wheel" group in all-customizations config

e5f415e

The wheel group is created by the setup package on all systems by default. Before our use of the force option, this would fail. This new config now tests that the build doesn't fail since we enable the force option unconditionally.

achilleas-k force-pushed the stages/groups/force branch from 2d14832 to e5f415e Compare January 20, 2026 11:39

lzap approved these changes Jan 20, 2026

View reviewed changes

supakeen added this pull request to the merge queue Jan 20, 2026

Merged via the queue into osbuild:main with commit 273037a Jan 20, 2026
25 checks passed

achilleas-k deleted the stages/groups/force branch January 21, 2026 10:18

achilleas-k mentioned this pull request Jan 21, 2026

Add validation for group customization: Check for duplicate names and GIDs osbuild/blueprint#43

Merged

achilleas-k added a commit to osbuild/osbuild.github.io that referenced this pull request Feb 4, 2026

blueprint-reference: add note describing new groups behaviour

7619b3a

See osbuild/image-builder#2146

supakeen pushed a commit to osbuild/osbuild.github.io that referenced this pull request Feb 4, 2026

blueprint-reference: add note describing new groups behaviour

fa98dd8

See osbuild/image-builder#2146

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

osbuild: add force option to org.osbuild.groups and always enable [HMS-9825]#2146

osbuild: add force option to org.osbuild.groups and always enable [HMS-9825]#2146
supakeen merged 4 commits into
osbuild:mainfrom
achilleas-k:stages/groups/force

achilleas-k commented Jan 19, 2026 •

edited

Loading

Uh oh!

This comment was marked as outdated.

achilleas-k commented Jan 19, 2026

Uh oh!

bcl Jan 19, 2026

Uh oh!

bcl left a comment

Uh oh!

achilleas-k commented Jan 19, 2026

Uh oh!

thozza left a comment

Uh oh!

thozza Jan 20, 2026

Uh oh!

achilleas-k Jan 20, 2026

Uh oh!

thozza Jan 20, 2026

Uh oh!

Uh oh!

Uh oh!

achilleas-k commented Jan 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

achilleas-k commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

achilleas-k commented Jan 19, 2026

Uh oh!

bcl Jan 19, 2026

Choose a reason for hiding this comment

Uh oh!

bcl left a comment

Choose a reason for hiding this comment

Uh oh!

achilleas-k commented Jan 19, 2026

Uh oh!

thozza left a comment

Choose a reason for hiding this comment

Uh oh!

thozza Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

achilleas-k Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

thozza Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

achilleas-k commented Jan 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

achilleas-k commented Jan 19, 2026 •

edited

Loading