Bug 2378660

Summary: Kickstart domain enrolment during install fails since anaconda-43.25-1.fc43
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: anacondaAssignee: anaconda-maint
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: anaconda-maint, kkoukiou, mkolman, pboy, w
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: openqa
Fixed In Version: anaconda-43.32-1.fc43 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-07-30 06:31:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2324223    
Attachments:
Description Flags
/var/log tarball from affected test none

Description Adam Williamson 2025-07-08 16:19:26 UTC
Since anaconda-43.25-1.fc43 landed in Fedora-Rawhide-20250625.n.0, domain enrolment (to FreeIPA or AD) during install fails. There's not a whole lot in the logs, only this:

16:06:52,201 WARNING org.fedoraproject.Anaconda.Modules.Security:INFO:anaconda.modules.common.task.task:Join a realm
16:06:52,201 WARNING org.fedoraproject.Anaconda.Modules.Security:DEBUG:anaconda.modules.security.installation:No realm has been discovered, so not joining any realm.
16:06:52,201 WARNING org.fedoraproject.Anaconda.Modules.Security:INFO:anaconda.core.threads:Thread Done: AnaTaskThread-RealmJoinTask-1 (139978232313536)

but this was working fine up until Fedora-Rawhide-20250623.n.0 and has failed in Fedora-Rawhide-20250625.n.0 and every subsequent compose. I assume "Enable all steps of the installation queue" might be relevant here?

The openQA test config here has not changed, and all other enrolment tests against the same servers worked fine, only the kickstart enrolments fail.

Comment 1 Adam Williamson 2025-07-08 16:20:13 UTC
Proposing as an F43 Beta blocker per Basic criterion "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install..." - https://fedoraproject.org/wiki/Basic_Release_Criteria#Remote_authentication

Comment 2 Martin Kolman 2025-07-25 11:27:07 UTC
(In reply to Adam Williamson from comment #0)
> Since anaconda-43.25-1.fc43 landed in Fedora-Rawhide-20250625.n.0, domain
> enrolment (to FreeIPA or AD) during install fails. There's not a whole lot
> in the logs, only this:
> 
> 16:06:52,201 WARNING
> org.fedoraproject.Anaconda.Modules.Security:INFO:anaconda.modules.common.
> task.task:Join a realm
> 16:06:52,201 WARNING
> org.fedoraproject.Anaconda.Modules.Security:DEBUG:anaconda.modules.security.
> installation:No realm has been discovered, so not joining any realm.
> 16:06:52,201 WARNING
> org.fedoraproject.Anaconda.Modules.Security:INFO:anaconda.core.threads:
> Thread Done: AnaTaskThread-RealmJoinTask-1 (139978232313536)
> 
> but this was working fine up until Fedora-Rawhide-20250623.n.0 and has
> failed in Fedora-Rawhide-20250625.n.0 and every subsequent compose. I assume
> "Enable all steps of the installation queue" might be relevant here?
> 
> The openQA test config here has not changed, and all other enrolment tests
> against the same servers worked fine, only the kickstart enrolments fail.

Looking at the log snippet the join operation is running - but the IIRC necessary discover operation that needs to run before the join operation either failed or we somehow skipped running it (oops ?). Could you attach/link to a full log from this test so I can check if there is something about the realm discover operation ?

Comment 3 Adam Williamson 2025-07-25 15:05:32 UTC
Created attachment 2098232 [details]
/var/log tarball from affected test

I'm pretty sure I didn't see anything like that, but here. It's a /var/log tarball of a recent failure. It's post-install, so the anaconda logs are in /var/log/anaconda.

Comment 4 Adam Williamson 2025-07-30 21:01:22 UTC
Fix confirmed, thanks!