Bug 1978264
| Summary: | auto-start a network connection | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Samantha N. Bueno <sbueno> |
| Component: | anaconda | Assignee: | Radek Vykydal <rvykydal> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | unspecified | Docs Contact: | Eliane Ramos Pereira <elpereir> |
| Priority: | unspecified | ||
| Version: | 9.0 | CC: | elpereir, jstodola, mlewando, rvykydal, sdubewar, tgunders, zveleba |
| Target Milestone: | beta | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | anaconda-34.25.0.11-1.el9 | Doc Type: | Enhancement |
| Doc Text: |
.Anaconda activates network automatically for interactive installations
Previously, when performing an interactive installation without having the network activated by Kickstart or boot options, users had to activate the network manually in the network spoke. With this update, Anaconda activates the network automatically, without requiring users to visit the network spoke and activate it manually.
NOTE: This update does not change the installation experience for Kickstart installations and installations using the `ip=` boot option.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-12-07 21:20:54 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: | |||
|
Description
Samantha N. Bueno
2021-07-01 12:18:17 UTC
The main use case of this feature are interactive installations without network activated in initramfs (for example media installation from DVD, boot.iso). In this cases the network will be activated automatically (dhcp tried on all supported devices) after switch root. The mechanism used is enabling NM auto connections (which have always been disabled for RHEL in contrast to Fedora) via NM configuration so that NM creates and activates the auto connections upon its start. It should address bad GUI user experience regarding NTP configuration and Registering to RedHat which used to require extra step of vistiting of network spoke and activating of network. It introduces a change of behaviour so we are trying to limit it to cover the desired use cases. The autoconnections will not be enabled if: - inst.ks boot option is used: in majority of cases kickstart is fetched from network so the network would have been activated already in initramfs. Network can be also activated explicitly via kickstart. - ip= boot option is used: network is activated already in initramfs. The required lorax changes https://gitlab.com/redhat/centos-stream/rpms/lorax-templates-rhel/-/merge_requests/16 are present in lorax-templates-rhel-9.0-22.el9 which is in RHEL 9 Beta nightly compose since RHEL-9.0.0-20210724.2. So the feature should be ready for verification now. anaconda-34.25.0.11-1.el9 and lorax-templates-rhel-9.0-22.el9 are present in compose RHEL-9.0.0-20210816.3 Moving to Verified. Sorry! Moving back to ON_QA because of https://bugzilla.redhat.com/show_bug.cgi?id=1978264#c4 The change in this BZ is targeted at activation of network in installer environment (please see comment #1), not on installed system as the current DocText seems to suggest. I hope the difference would be clear from my proposed text (to be polished): "Anaconda activates network automatically for interactive installations Previously, when performing interactive installation without network activated by kickstart or boot options, users had to activate the network manually in the network spoke. With this update, Anaconda activates the network automatically, without requiring users to visit the network spoke. NOTE: This update does not change installation experience for kickstart installations and installations using `ip=` boot option." @sdubewar - we might consider this change for "Considerations in adopting RHEL 9" document. Looks good to me, thank you. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days |