I installed in expert mode over a wireless link from
Debian GNU/Linux testing "Wheezy" - Official Snapshot i386 NETINST Binary-1 20121122-21:21
This ISO has netcfg_1.102. Only "Standard system utilities" was selected
as a task. Re-booted as instructed. No network! Checked the contents of
/etc/network/interfaces. The only interface available is lo. I'm still
in a state of shock. :)
From the netcfg changelog:
* On Linux: Write a network-manager configuration file in perference
to ifupdown if network-manager is found in the installed system.
Configure wired networking with ifupdown if not. Do not configure
wireless networking through ifupdown.
and
* Reword target_network_config template; do not ask the question.
Not only am I deprived of network connectivity because I did not install
network-manager or use a network cable, but this is done silently.
The machine that Debian was put on is a desktop model and isn't going
anywhere. Now I have try to recollect what to put in /e/n/i to restore
the network connection. Also, the WPA passphrase is a machine generated
63 random characters. With gpm it's a snap to copy and paste. Except....
If I'd installed to a laptop I might have wanted wpagui to deal with any
roaming. Or network-manager for that matter. Having to start from
scratch is tiresome.
Anyone who used a network during an install would, in my opinion, most
likely want it available afterwards. Please consider leaving it set up
as configured by ifupdown when the install takes place as described
above.
Some discussion of the issue is in the thread starting at
http://lists.debian.org/debian-boot/2012/09/msg00252.html
Hello, For most cases, I think not adding configuration for wireless in /e/n/i is good, however for the kind a situations you described I think the best solution would be to have the question asked, at least with a low priority. If that would be the case, changing the permissions of /e/n/i to 600 should also be considered. Sorina
On Sun 25 Nov 2012 at 17:30:28 +0200, Sorina - Gabriela Sandu wrote: Hello Sorina. Having the question asked in *all* cases would be far preferable to having something you may not want forced on you. I still do not understand "For most cases . . .". Without a handful of CDs available there is only one way to restore the disallowed connection to a network - ifupdown. Set it up, pull it down, set it up again isn't my idea of what Debian should do. Because the opportunity may not arise again: I have been following the development of wireless connectivity in D-I for the past year. The implementation (from the point of view of whether it works) is very good. I would like to thank you and everybody else for the work which has been done. The quality of the emerging end result is a credit to the Debian Project and shows what can be achieved with Free software and a team of committed developers.
Hello, Yes, the question should be asked for all installs, but with a low priority. I can't think of a criterion on which to decide whether to ask it or not and I also don't believe that having such criterion would be useful. What I wanted to say by "For most cases" is that I believe that having the _default_ to not write wireless config in /e/n/i is good, and this would work for most installs (but obviously not for the case you mentioned). I wasn't thinking of asking the questions is "some cases" and not in others. I hope it's more clear now :) Thanks, Sorina
A low priority wouldn't really help, given that it would only be shown in expert mode. I'm not sure if there's a sane default here and would appreciate if others could chime in with their opinion. Things like "would we need to chmod 0600 /e/n/i?", "would all tools cope with /e/n/i being 0600 if so" and "should we write an entry that might prevent later installations of network connection management tools to work correctly?". Kind regards Philipp Kern
A low priority wouldn't really help, given that it would only be shown in expert mode. I'm not sure if there's a sane default here and would appreciate if others could chime in with their opinion. Things like "would we need to chmod 0600 /e/n/i?", "would all tools cope with /e/n/i being 0600 if so" and "should we write an entry that might prevent later installations of network connection management tools to work correctly?". Kind regards Philipp Kern
I bumped into this issue when I recently installed Debian on my new laptop. I only installed the "Standard system utilities", thus no network-manager and while wpasupplicant was installed the wireless connection config I used during installation wasn't written to a/the wpa_supplicant.conf file and neither was there anything configured/written to /e/n/i related to my wireless card. Due to 'predicable' network naming this becomes even more of a hassle to do manually. While the above quote is from 25 Nov 2012 and I haven't checked whether the changelog would now tell sth different, it looks like wireless networking through ifupdown is not configured, regardless whether network-manager is present or not. Why not configure wireless networking through ifupdown when network-manager *isn't* installed? I have to give you kudos for (manually?) copying an .ucode file which I provided through a workaround [1], but that added to my surprise that wireless networking still wouldn't work due to the above described problem. Cheers, Diederik [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808792#47
[...] The number of users affected by this issue over the years is not insignificant. Not a single one has written in support of the situation. https://lists.debian.org/debian-user/2018/03/msg00066.html has the latest experiences of three users. Regards, Brian.
Brian Potkin wrote:
This issue has bitten me at least twice so far.
This issue's history seems to be bogged down on whether interfaces(5) can be mode 0600 (to hide the cleartext passphrase).
This is not necessary; the passphrase can go in a separate file.
Here is a minimal config, assuming WPA2 PSK (not Enterprise) and DHCP (not static) for all SSIDs:
cat >/etc/network/interfaces <<EOF
allow-auto lo $iface
iface lo inet loopback
iface default inet dhcp
iface $iface inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant-$iface.conf
EOF
wpa_passphrase "$ssid" "$passphrase" >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
If you don't want to udebify wpa_passphrase, you can do it by hand:
cat >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" <<EOF
network={
ssid="$ssid"
psk="$passphrase"
}
EOF
If you really hate ifupdown, you can use systemd instead (not fully tested):
cat >/etc/systemd/network/$iface.network <<EOF
[Match]
iface=$iface
[Network]
DHCP=yes
EOF
systemctl enable wpa_supplicant@$iface.service
wpa_passphrase "$ssid" "$passphrase" >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
If even these things are too much, can you AT LEAST install wpasupplicant?
Writing config files is much easier than ferrying .debs between computers by USB key.
If this bug is going to be kept ANOTHER Debian release,
can you at least warn people about it in the buster Installation Guide?
bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
If installing a desktop environment, after putting the wireless in
/e/n/i, does not work, then that is a bug in the desktop environment,
surely ?
In practice I would expect the config in /e/n/i to keep working
because nowadays network-manager will ignore things in /e/n/i. The
difficulty would only come if you
- used the installer to install a bare system over wifi
- later install network-manager or wicd
- then expect the system to give you a gui prompt for new wifi
networks, rather than expect to have to edit /e/n/i
It would be possible for the n-m and wicd packages to spot when this
is happening and offer to take over the interface. And I do think
that in the absence of code to do that, it would be more important to
make the barebones system work in the first place, than to improve the
behaviour you later install n-m.
(I'm not sure if what I say about wicd is right. I use n-m on
machines I have where the user needs to switch between various network
connections, wifi networks, etc.)
The bug tyracker is precisely the right place to discuss how to solve
a particular bug. So I have CC'd it.
Ian.
Most probably. But desktop environments were not the subject of this thread. (Sorry for trying to keep on-topic). That difficulty is exactly the subject of this thread. The rest of this post is snipped because it side-steps addressing the issue. What is put in /e/n/i ceases to work because it is obliterated by the installer for reasons unknown. One user calls it a "sick joke". After five years and with no attempt to rectify the situation, I'm beginning to have sympathy with that view. (Yes, I know we are all volunteers).
Mode 0600 wasn't intially given as a reason: https://lists.debian.org/debian-boot/2012/09/msg00282.html > 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). Later in the thread: https://lists.debian.org/debian-boot/2012/09/msg00313.html > On the other hand, we have users who chose not to install a desktop > environment but want their machine to migrate between networks when it's > moved. These users are going to need to do some form of sysadmin work > post-install, whether it's installing a desktop environment and wicd, or > editing /etc/network/interfaces on each fresh network, or bringing up > wifi connections by hand. So I can't see locking a default into > /etc/network/interfaces causing them much bother. 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. The default (loopback only for wireless) was added without considering mode 0600. At this stage in the history there appears to be a willingness to use ifupdown and not loopback. Or dispense with loopback for an installation over wireless (an easy enough change) and warn about 0600 in the Release Notes.
Having just swatted away this bug while installing bullseye on a laptop that has 1xUSB3, 2xUSB-C and no ethernet, I thought I should share the workaround here. This is only necessary, I'm led to believe, when installing by WiFi without the installation of a Desktop. Before tearing down the WiFi interface at the very end of the installation, the d-i should simply copy the existing /target/etc/network/interfaces file to /target/root/, perhaps named as etc-network-interfaces-at-installation, with its permissions set to 600. When the machine is rebooted, it is now straightforward for the sysadmin to login and simply: # mv /root/etc-network-interfaces-at-installation /etc/network/interfaces # ifup w<TAB><RETURN> to give themselves WiFi connectivity (using sudo if necessary). This workaround has the benefit of being fail-safe: the file has no effect on the system if the sysadmin ignores it and leaves it in /root, but if they do move it as above, then they've taken responsibility for its effects on any software they install later. Naturally, it would require a note in the Installation Guide for this method to be useful if the sysadmin is not one to make use of root's home directory. Cheers, David.
Bună seara, vă rog să mă sunați acum sau să răspundeți la mailul pe care vi l-am trimis de ieri.
Just hit this will bookworm too: https://bugs.debian.org/1027692 Not too bad, given not great options! :) ... or even /etc/network/interfaces.with-wifi and chmod 0600 it for the previously discussed security reasons. I would be more likely to notice a file sitting next to /etc/network/interfaces rather than rummaging around in /root. live well, vagrant