Summary
The /var/home relabel workaround added to the compat RPMs did not solve the reused-disk / preserved-/var gnome-initial-setup failure on TunaOS bootc installs, so we should stop treating that as the fix for the user-creation bug and consider dropping the COPR-side workaround if it is no longer needed for any other path.
What was tried
We added compose-time %post relabeling in:
e43cc6c — compat: restorecon /var/home in %post to fix useradd exit 12gnome49-el10-compatgnome50-el10-compat
That was intended to address the useradd exit 12 failure seen during gnome-initial-setup.
Why it did not actually fix the real-world TunaOS case
On TunaOS/bootc installs, the failing scenario is a reused target disk where /var is preserved on the deployed system (for example, boot drive attached via USB enclosure, reinstall onto same disk, existing /var/home tree carried forward).
In that case, an RPM %post scriptlet executed during image compose cannot reliably relabel the deployed machine's preserved /var/home, because that filesystem content is not the same runtime /var tree that GIS later operates on.
So the COPR workaround may help a narrow labeling case inside the compose/rootfs environment, but it does not solve the deployed-system regression users are still hitting.
Current understanding
There are two separate problems that got conflated:
- SELinux labeling issue on
/var/home
- shadow-utils 4.15
useradd -m failure when the target home already exists (EEXIST -> exit 12 / E_HOMEDIR)
The compose-time compat %post only attempted to help with #1, and only in a limited context.
The persistent reused-disk failure is still better explained by issue #17: existing home / preserved /var on the deployed system.
Proposed cleanup
- Stop referring to the compat
%post restorecon /var/home change as the fix for the GIS/useradd bug.
- Reevaluate whether the
%post restorecon -RF /var/home lines in gnome49-el10-compat and gnome50-el10-compat should be removed entirely.
- Keep the actual durable fix on the image/runtime side (TunaOS first-boot/deployed-system relabel before GDM), or alternatively patch
accountsservice / gnome-initial-setup / shadow-utils for the existing-home case.
Related
This issue is specifically about dropping the workaround that didn't solve the deployed TunaOS case, to avoid future confusion.
Summary
The
/var/homerelabel workaround added to the compat RPMs did not solve the reused-disk / preserved-/vargnome-initial-setupfailure on TunaOS bootc installs, so we should stop treating that as the fix for the user-creation bug and consider dropping the COPR-side workaround if it is no longer needed for any other path.What was tried
We added compose-time
%postrelabeling in:e43cc6c—compat: restorecon /var/home in %post to fix useradd exit 12gnome49-el10-compatgnome50-el10-compatThat was intended to address the
useraddexit 12 failure seen duringgnome-initial-setup.Why it did not actually fix the real-world TunaOS case
On TunaOS/bootc installs, the failing scenario is a reused target disk where
/varis preserved on the deployed system (for example, boot drive attached via USB enclosure, reinstall onto same disk, existing/var/hometree carried forward).In that case, an RPM
%postscriptlet executed during image compose cannot reliably relabel the deployed machine's preserved/var/home, because that filesystem content is not the same runtime/vartree that GIS later operates on.So the COPR workaround may help a narrow labeling case inside the compose/rootfs environment, but it does not solve the deployed-system regression users are still hitting.
Current understanding
There are two separate problems that got conflated:
/var/homeuseradd -mfailure when the target home already exists (EEXIST-> exit 12 /E_HOMEDIR)The compose-time compat
%postonly attempted to help with #1, and only in a limited context.The persistent reused-disk failure is still better explained by issue #17: existing home / preserved
/varon the deployed system.Proposed cleanup
%post restorecon /var/homechange as the fix for the GIS/useradd bug.%post restorecon -RF /var/homelines ingnome49-el10-compatandgnome50-el10-compatshould be removed entirely.accountsservice/gnome-initial-setup/shadow-utilsfor the existing-home case.Related
e43cc6cThis issue is specifically about dropping the workaround that didn't solve the deployed TunaOS case, to avoid future confusion.