#1039727 debian-installer configures ifupdown instead of NetworkManager even if a Desktop Environment is chosen #1039727
- Package:
- debian-installer
- Source:
- debian-installer
- Description:
- Debian Installer documentation
- Submitter:
- Austin Moss
- Date:
- 2023-06-28 22:09:02 UTC
- Severity:
- normal
Hello debian-installer maintainers,
When installing Debian with the graphical installer from the DVD ISO, one of
the steps during the installer prompts users to connect to a network to
retrieve up to date packages. Later in the installer, the user is prompted to
choose additional packages such as the GNOME desktop environment. Once the
install is complete, the user will boot in to the newly installed system and
GNOME's network indicator will show no network connectivity even though they
configured such during the install and the network is likely up.
This appears to be due to the installer configuring ifupdown and
placing the selected interface in /etc/network/interfaces. GNOME's graphical
settings application provides a front end for NetworkManager and as such, will
not display the interface used during the installer. To display the interface
in GNOME Settings, a user needs to remove the interface from
/etc/network/interfaces.
Without knowing why the network is not displayed in the graphical
interface, users will be confused as to why they can browse the web or perform
other network tasks even though the GUI does not indicate a network connection.
This may also present a problem especially for wireless cards if a user needs
to connect to a new wireless network but cannot see their wireless card from
the GUI.
One of the fixes may be to clean /etc/networks/interfaces after the
installation if a user has selected to install GNOME, KDE, or any desktop
environment which provides a graphical front end for NetworkManager.
Thank you for taking the time to read this bug report.
-Austin
Hi Austin, And thanks for your detailed report. Austin Moss <austin@themosses.org> (2023-06-28): netcfg is the component responsible for forwarding network settings from the installer's context to the installed system. A few bugs were fixed that led to having no /e/n/i configuration for wireless interfaces in the non-NetworkManager case, and I cannot exclude the possibility I might have introduced a regression for the NetworkManager case. It feels a little strange that such a big issue wouldn't have been spotted via the many tests that are run for the release, but maybe we aren't actively checking that particular point (yet)… Could you please share /var/log/installer/syslog (compressed) via reply-all? Cheers,
Hi Cyril, Thank you for taking a look at this. Attached an archive with /var/log/installer/syslog for you. -Austin
Austin Moss <austin@themosses.org> (2023-06-28):
The relevant parts of the log are likely the following:
Jun 27 22:03:08 netcfg[4939]: DEBUG: Network config complete
Jun 27 22:03:08 netcfg[4939]: DEBUG: No interface given; clearing /etc/network/interfaces
Jun 27 22:03:08 netcfg[4939]: DEBUG: Writing informative header
Jun 27 22:03:08 netcfg[4939]: DEBUG: Success!
Jun 27 22:03:08 netcfg[4939]: DEBUG: Writing loopback interface
Jun 27 22:03:08 netcfg[4939]: DEBUG: Success!
Jun 27 22:03:08 netcfg[4939]: DEBUG: Writing DHCP stanza for wlp4s0
Jun 27 22:03:08 netcfg[4939]: INFO: Detected wlp4s0 as a hotpluggable device
Jun 27 22:03:08 netcfg[4939]: DEBUG: Writing wireless options for wlp4s0
Jun 27 22:03:08 netcfg[4939]: DEBUG: Success!
Jun 27 22:03:09 netcfg[4939]: INFO: Unable to open file for writing network-manager configuration. The connection id (¯\_(ツ)_/¯) might not be set to a proper value.
And later:
Jun 28 03:20:31 finish-install: info: Running /usr/lib/finish-install.d/55netcfg-copy-config
Jun 28 03:20:31 netcfg: DEBUG: copy-config: /tmp/connection_type not found: netcfg did not complete or was compiled without network-manager support; exiting.
While I'm not familiar with all the details, it looks to me the funky
connection ID prevented some initial configuration, which led to a
missing file expected at the end of the installation, which in turn led
to a fallback /e/n/i configuration instead of the detected/desired NM
configuration. But seeing how the last DEBUG message leads to an early
exit in the finish-install script (responsible for copying things
around), I'm not sure why/how /e/n/i got copied from the installer's
context to the installed system…
In any case, this might not be a “big issue” as I feared, just
particular circumstances?
Cheers,
Perhaps you may be on to something - my SSID has caused some issues on systems that cannot handle some characters. Strange that it ended up in the network configuration regardless. I would agree, it is not a "BIG" issue from my perspective. More of a nuisance I suppose. I would have to test with my other "normal" SSID to see if it works as expected but again, don't believe it's a big issue, so I'm not sure that's really necessary. -Austin