RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1978264 - auto-start a network connection
Summary: auto-start a network connection
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: anaconda
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: beta
: ---
Assignee: Radek Vykydal
QA Contact: Release Test Team
Eliane Ramos Pereira
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-01 12:18 UTC by Samantha N. Bueno
Modified: 2023-09-15 01:34 UTC (History)
7 users (show)

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.
Clone Of:
Environment:
Last Closed: 2021-12-07 21:20:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Samantha N. Bueno 2021-07-01 12:18:17 UTC 
There have been numerous bug reports over the years to request that anaconda automatically start a network connection, rather than forcing users to manually toggle it on.

This bz is to do exactly that, except in the cases of kickstart or when users specify network configuration as a boot parameter.
Comment 1 Radek Vykydal 2021-07-01 13:30:50 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.
Comment 2 Radek Vykydal 2021-07-01 13:32:59 UTC 
https://github.com/rhinstaller/anaconda/pull/3481
Comment 8 Radek Vykydal 2021-07-27 08:15:26 UTC 
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.
Comment 9 Marta Lewandowska 2021-08-17 10:01:40 UTC 
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.
Comment 10 Marta Lewandowska 2021-08-17 10:09:30 UTC 
Sorry! Moving back to ON_QA because of https://bugzilla.redhat.com/show_bug.cgi?id=1978264#c4
Comment 14 Radek Vykydal 2021-10-11 13:18:17 UTC 
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."
Comment 15 Radek Vykydal 2021-10-11 14:30:04 UTC 
@sdubewar - we might consider this change for "Considerations in adopting RHEL 9" document.
Comment 18 Radek Vykydal 2021-10-13 07:43:42 UTC 
Looks good to me, thank you.
Comment 23 Red Hat Bugzilla 2023-09-15 01:34:52 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days
Note You need to log in before you can comment on or make changes to this bug.