[Some rampant snipping, I'm afraid. Hope that is ok.]
On Thu 01 Feb 2018 at 09:41:36 -0600, David Wright wrote:
> On Thu 01 Feb 2018 at 10:55:35 (+0000), Brian wrote:
> > >
> > > Intended to do what?
> >
> > To leave the user without network connectivity after first boot? There
> > are at least three bug reports against netcfg on the matter. My
> > recollection is that no deeper intention is revealed there.
>
> The two that seem most relevant are #694068 and #709017. Finding out
> that a udeb package called netcfg even exists does of course require
> examination of the logs and disection of the debian-installer.
>
> The considered opinion of Sorina - Gabriela Sandu <sandu.sor...@gmail.com> is
>
> Date: Sun, 25 Nov 2012 17:30:28 +0200
> "For most cases, I think not adding configuration for wireless in /e/n/i
> is good"
>
> which shows a lack of attention to important details like leaving the
> new installation with some sort of connectivity.
No reason given for the goodness is given, which makes it hard to judge.
> The considered opinion of Colin Watson <cjwat...@debian.org> Date:
> Thu, 28 Aug 2014 20:03:55 +0100
>
> "This is wrong, I'm afraid. /etc/network/interfaces will *always*
> exist at this stage, because it's copied by netcfg's
> base-installer hook. However, the finish-install hook is
> explicitly using "netcfg write_loopback" in some cases to make
> sure that /etc/network/interfaces contains only the loopback
> entry. Declining to copy this to the target system would break
> those cases.
>
> "What I'll do instead is copy /etc/network/interfaces only for the
> netcfg/target_network_config settings that require it. Then this
> may just work for you if you don't have network-manager
> installed,"
>
> This implies that "other cases" have been considered but forgotten.
>
> Yes, I don't think the intentions are deeper, but just that simple
> cases have been overlooked, and overlooked for several years.
This statement is from #709017, a closed report. Fixed with
* Don't copy /etc/network/interfaces to /target if
netcfg/target_network_config=ifupdown;
> > How connectivity is re-established on a machine with only a wireless
> > interface is left as an exercise for the user.
>
> This is some sort of sick joke.
Re-writing /e/n/i again for a wireless interface is expected.
> > You think it is required. I think it is required. Other users think it
> > is required. Perhaps the installer knows best? :)
>
> Obviously not. It appears that the debian-installer team isn't able to
> summon up the energy to debug one of their scripts and, because they
> never meet the users who run into the bug, they feel no pressure to fix it.
>
> > It does, however, give
> > a way to go against its wishes:
> >
> > Template: netcfg/target_network_config
> > Type: select
> > Choices-C: nm_config, ifupdown, loopback
> > Choices: Network Manager, ifupdown (/etc/network/interfaces), No network
> > configuration
> > Description: for internal use; can be preseeded
> > Specifies what kind of network connection management tool should be
> > configured post-installation if multiple are available. Automatic
> > selection is used in this order when not specified: network-manager if
> > available (on Linux only), ethernet configuration through ifupdown on wired
> > installation and loopback configuration through ifupdown on wireless
> > installations.
>
> If, by that, you mean preseeding, that's just a crummy workaround for
> not fixing the problem. Preseeding wasn't designed for that.
I'm not very sure I entirely agree with what you write but will not
argue the point. What I would say is that most users' thoughts would
not turn to preseeding as a solution, or leap to writing an /e/n/i if
they meet this issue.
> > No DE installed; therefore no network-manager. Installation was not over
> > a wired connection; therefore no ifupdown stanza in /e/n/i.
>
> I'm being sold a bill of goods here, then, as it's not clear how the
> system can perform as a server if it has no connectivity.
>
> So the final word is Sorina's:
> "For most cases, I think not adding configuration for wireless in /e/n/i is
> good"
>
> Considering events of the past year, I guess that's what now counts as
> policy. It just took the world a while to catch up with Debian.
I've written enough on this over the past five years, both in -user and
elsewhere. I can cope with the situation myself but dislike the jumping
through hoops aspect to get a simple thing like connectivity in d-i.
I've come to the conclusion that the present arrangement is as good as
its going to get. It's difficult to know where to go from here but
discussion on -user is unlikely to lead to any change.
Anyway, you jogged my memory:
https://lists.debian.org/debian-boot/2012/09/msg00252.html
Sorina - Gabriela Sandu:
> > I realise a default is only a default and the selection can be changed,
> > but I'm puzzled by the third option. Why treat a wireless install
> > differently from a wired install? It would expected that a user who has
> > chosen not to use a wired connection would still want connectivity after
> > booting into into the new system,
> The main reason for this is that as far as I know writing configs
> related to a wireless network to /e/n/i enforce using only that
> particular network later (of course if you don't modify the file) and
> also that the interface is unmanageable for other tools. The idea was
> to leave the network unconfigured, so that it can be managed later
> (perhaps via something else than NM).
Gaudenz Steinlin:
> The main reason for the question was to make it preseedable. So for
> example automated desktop installs could still choose ifupdown. Or if
> you know that your configuration management is going to install
> network-manager afterwards you can choose the network-manager
> configuration depsite it nm not being installed at the moment. Or you
> can choose to not configure anything because you have a complex post
> install script doing network configuration.
> IIRC we decided on this default before we added the code to change the
> access mode of /e/n/i if it contains a password. The main reason for
> defaulting to no configuration in this case was to avoid having
> passwords in there. If people think it should default to ifupdown in
> this case this can be changed.
I imagine my "...not aware of any comprehensive explanation..." should
be modified.
--
Brian.
