Sending from my phone, so I apologize for the top posting.
Last night I did a real install on a spare laptop using this ISO. It was ordinary and vanilla, but everything was happy and nice.
My biggest issues were with regard to wireless.
A) There's nothing for wireless networking in the network section. That'd be nice B) wpa_supplicant.conf would be a good config to add to the list, considering we're trying to enforce using that C) Auto configuring of rc.conf treats wireless interfaces as ethernet.
None of these are really bugs. More like feature requests, I guess.
And one other thing unrelated to wireless: If I didn't edit mkinitcpio.conf, there's no need to generate the initramfs again in the config section. Perhaps md5sum the config files before and after editing to see if a given action is necessary?
Cheers, and sorry again for the top post, Aaron
On Apr 5, 2010 10:43 AM, "Dieter Plaetinck" dieter@plaetinck.be wrote:
Hello all, please find new testing images @ http://build.archlinux.org/isos/
This time, there are no big known issues! [1] I just did an installation myself and it worked, but of course images require a lot more testing, especially for the exotic things (lvm, encryption, automatic installs, all new features such as pxe booting, etc). So please give these images a spin. They can't be much worse then the last official release ;-) If you tested the image and it worked fine, be sure to let us know and briefly describe which special thingies (if any) worked fine for you.
http://build.archlinux.org/isos/Changelog http://build.archlinux.org/isos/README
The more feedback I get from the community, the faster a new official release will happen.
Dieter
[1] (I did not figure out the issue i had earlier - http://mailman.archlinux.org/pipermail/arch-releng/2010-April/000941.html, but I re-setup the build chroots and now it's magically fixed.
Am 16.04.2010 01:19, schrieb Aaron Griffin:
Sending from my phone, so I apologize for the top posting.
Last night I did a real install on a spare laptop using this ISO. It was ordinary and vanilla, but everything was happy and nice.
My biggest issues were with regard to wireless.
A) There's nothing for wireless networking in the network section. That'd be nice B) wpa_supplicant.conf would be a good config to add to the list, considering we're trying to enforce using that C) Auto configuring of rc.conf treats wireless interfaces as ethernet.
None of these are really bugs. More like feature requests, I guess.
A dialog-based configuration tool that generates a netcfg profile would be very nice here, it would allow all kinds of configurations, including different wireless modes.
And one other thing unrelated to wireless: If I didn't edit mkinitcpio.conf, there's no need to generate the initramfs again in the config section. Perhaps md5sum the config files before and after editing to see if a given action is necessary?
Good idea I guess.
On Fri, 16 Apr 2010 09:35:21 +0200 Thomas Bächler thomas@archlinux.org wrote:
Am 16.04.2010 01:19, schrieb Aaron Griffin:
Sending from my phone, so I apologize for the top posting.
Last night I did a real install on a spare laptop using this ISO. It was ordinary and vanilla, but everything was happy and nice.
My biggest issues were with regard to wireless.
A) There's nothing for wireless networking in the network section. That'd be nice B) wpa_supplicant.conf would be a good config to add to the list, considering we're trying to enforce using that C) Auto configuring of rc.conf treats wireless interfaces as ethernet.
None of these are really bugs. More like feature requests, I guess.
A dialog-based configuration tool that generates a netcfg profile would be very nice here, it would allow all kinds of configurations, including different wireless modes.
I rarely use wireless so forgive my ignorance. 1) wpa_supplicant is in base. is this needed? or should it be added to the list @ http://bugs.archlinux.org/task/18495 2) what's wrong with C) ? network settings in rc.conf are IP stuff, so wlan and eth interfaces can be treated the same, no? 3) maybe i should grep all interfaces in /etc/rc.conf, check if they are wireless ones with iwconfig, and if so add /etc/wpa_supplicant.conf to the list? (or: if wpa_supplicant gets installed if it gets out of base)
Basically, you need to tell me what the best practices are to set up wireless networking, how i should store that to the configs and what things that should change (such as adding wpa_supplicant.conf to the list of files to edit) Or maybe do it directly as feature requests on flyspray, as the chance that I'll do it anytime soon is small.
And one other thing unrelated to wireless: If I didn't edit mkinitcpio.conf, there's no need to generate the initramfs again in the config section. Perhaps md5sum the config files before and after editing to see if a given action is necessary?
Good idea I guess.
there's has been some discussion about why we do mkinitcpio and locale-gen twice http://bugs.archlinux.org/task/15680 does mkinitcpio *only* depend on /etc/mkinitcpio.conf, i.e. if that file is the same (but anything else can change) we don't need to regenerate mkinitcpio? AFAIK things are be a bit more complicated then that and may not be worth the extra hassle of implementing the needed checks and stuff.
Dieter
Am 16.04.2010 10:12, schrieb Dieter Plaetinck:
Last night I did a real install on a spare laptop using this ISO. It was ordinary and vanilla, but everything was happy and nice.
My biggest issues were with regard to wireless.
A) There's nothing for wireless networking in the network section. That'd be nice B) wpa_supplicant.conf would be a good config to add to the list, considering we're trying to enforce using that C) Auto configuring of rc.conf treats wireless interfaces as ethernet.
None of these are really bugs. More like feature requests, I guess.
A dialog-based configuration tool that generates a netcfg profile would be very nice here, it would allow all kinds of configurations, including different wireless modes.
I rarely use wireless so forgive my ignorance.
- wpa_supplicant is in base. is this needed? or should it be added to
the list @ http://bugs.archlinux.org/task/18495
Probably not, as none of the other wireless tools are in base. We should rather add it to the base-wireless group, which I wanted to create for some time now :) We could then list that base-wireless group in the installer and anyone will say "Hey, wireless, I want that" and select it.
- what's wrong with C) ? network settings in rc.conf are IP stuff, so
wlan and eth interfaces can be treated the same, no?
Wireless interfaces in rc.conf need extra configuration in /etc/conf.d/wireless. This configuration file uses the (deprecated) iwconfig tool and only supports open and WEP networks. In my eyes, wireless configuration through this mechanism is deprecated and shouldn't be supported at all. I even wanted to remove it from initscripts, but last time I brought it up, Aaron blocked me on it.
- maybe i should grep all interfaces in /etc/rc.conf, check if they
are wireless ones with iwconfig, and if so add /etc/wpa_supplicant.conf to the list? (or: if wpa_supplicant gets installed if it gets out of base)
Editing wpa_supplicant.conf directly is something only a very experienced user would do, and even then I don't think it's a good idea, because we have no tools in Arch that can use this configuration properly. We shouldn't encourage users to do this.
Basically, you need to tell me what the best practices are to set up wireless networking, how i should store that to the configs and what things that should change (such as adding wpa_supplicant.conf to the list of files to edit) Or maybe do it directly as feature requests on flyspray, as the chance that I'll do it anytime soon is small.
The recommended pratice in Arch to set up wireless is creating a netcfg profile (or several) and using the net-auto-wireless daemon. It's the most straight-forward and reliable way to use wireless on Arch and supports wireless roaming as well as automatic reconnection.
IMO, a tool to generate netcfg profiles dialog-based is something that should be added to netcfg and then may be used from AIF. In any case, we should encourage users to rely on netcfg for any network setup that is more complex than just running dhcp on an ethernet interface.
There are some ways that are supported through extra (networkmanager, wicd), but afaik they rely on GUI to work.
And one other thing unrelated to wireless: If I didn't edit mkinitcpio.conf, there's no need to generate the initramfs again in the config section. Perhaps md5sum the config files before and after editing to see if a given action is necessary?
Good idea I guess.
there's has been some discussion about why we do mkinitcpio and locale-gen twice http://bugs.archlinux.org/task/15680 does mkinitcpio *only* depend on /etc/mkinitcpio.conf, i.e. if that file is the same (but anything else can change) we don't need to regenerate mkinitcpio? AFAIK things are be a bit more complicated then that and may not be worth the extra hassle of implementing the needed checks and stuff.
Everything that is necessary for a standard configuration is installed before mkinitcpio, so the image that is generated on 'pacman -S kernel26' should be fine. As soon as you add any extra hooks (which AIF does on its own, too), AIF must regenerate the image.
On Fri, Apr 16, 2010 at 3:12 AM, Dieter Plaetinck dieter@plaetinck.be wrote:
On Fri, 16 Apr 2010 09:35:21 +0200 Thomas Bächler thomas@archlinux.org wrote:
Am 16.04.2010 01:19, schrieb Aaron Griffin:
Sending from my phone, so I apologize for the top posting.
Last night I did a real install on a spare laptop using this ISO. It was ordinary and vanilla, but everything was happy and nice.
My biggest issues were with regard to wireless.
A) There's nothing for wireless networking in the network section. That'd be nice B) wpa_supplicant.conf would be a good config to add to the list, considering we're trying to enforce using that C) Auto configuring of rc.conf treats wireless interfaces as ethernet.
None of these are really bugs. More like feature requests, I guess.
A dialog-based configuration tool that generates a netcfg profile would be very nice here, it would allow all kinds of configurations, including different wireless modes.
I rarely use wireless so forgive my ignorance.
- wpa_supplicant is in base. is this needed? or should it be added to
the list @ http://bugs.archlinux.org/task/18495 2) what's wrong with C) ? network settings in rc.conf are IP stuff, so wlan and eth interfaces can be treated the same, no? 3) maybe i should grep all interfaces in /etc/rc.conf, check if they are wireless ones with iwconfig, and if so add /etc/wpa_supplicant.conf to the list? (or: if wpa_supplicant gets installed if it gets out of base)
Basically, you need to tell me what the best practices are to set up wireless networking, how i should store that to the configs and what things that should change (such as adding wpa_supplicant.conf to the list of files to edit) Or maybe do it directly as feature requests on flyspray, as the chance that I'll do it anytime soon is small.
Well, a tool in netcfg for wireless configuration is necessary, but AIF shouldn't treat wireless interfaces the same as wired interfaces. I am unclear on the proper way to detect this in the days of deprecated iwconfig (Thomas? How would you list wired and wireless interfaces separately?) That covers #1 and #3.
Regarding direct editing of wpa_supplicant... I don't think that's "advanced" as Thomas suggests. It's heavily commented and not really that complex. Think about it this way: with wireless_tools being deprecated, wpa_supplicant is pretty much the defacto way to connect to wireless on linux. netcfg is an Arch specific tool. Users should know how to do this sort of thing in a distro-agnostic way.
As an aside, what about "iw". Where does that come from? Isn't it meant to replace iwconfig?
And one other thing unrelated to wireless: If I didn't edit mkinitcpio.conf, there's no need to generate the initramfs again in the config section. Perhaps md5sum the config files before and after editing to see if a given action is necessary?
Good idea I guess.
there's has been some discussion about why we do mkinitcpio and locale-gen twice http://bugs.archlinux.org/task/15680 does mkinitcpio *only* depend on /etc/mkinitcpio.conf, i.e. if that file is the same (but anything else can change) we don't need to regenerate mkinitcpio? AFAIK things are be a bit more complicated then that and may not be worth the extra hassle of implementing the needed checks and stuff.
Actually, from the installer's perspective, locale.gen and mkinitcpio.conf are the only reasons to re-run either generation script. If other things change, the user had to do them *outside* the installer. From within the installer, the only thing you can do is change the config files. If those are unchanged, you're going to generate the exact same output as they did on install.
Am 16.04.2010 14:14, schrieb Aaron Griffin:
Well, a tool in netcfg for wireless configuration is necessary, but AIF shouldn't treat wireless interfaces the same as wired interfaces. I am unclear on the proper way to detect this in the days of deprecated iwconfig (Thomas? How would you list wired and wireless interfaces separately?) That covers #1 and #3.
See below.
Regarding direct editing of wpa_supplicant... I don't think that's "advanced" as Thomas suggests. It's heavily commented and not really that complex.
We still have no way in Arch to use "plain" wpa_supplicant, as it will never perform any IP configuration on its own. That's why we have net-auto-wireless.
Think about it this way: with wireless_tools being deprecated, wpa_supplicant is pretty much the defacto way to connect to wireless on linux. netcfg is an Arch specific tool. Users should know how to do this sort of thing in a distro-agnostic way.
netcfg is intuitive and self-explanatory. As mentioned above, messing with wpa_supplicant directly is not that useful on Arch.
As an aside, what about "iw". Where does that come from? Isn't it meant to replace iwconfig?
iw is the "new iwconfig" based on cfg80211. Basically, wireless extensions is deprecated, and thus all of wireless_tools. However, some old drivers (ipw2100, ipw2200) only have rudimentary cfg80211 support, so you still need wireless extensions for them. It's all a bit unfinished. In any case, all configuration should be done via wpa_supplicant, even for open networks, as that will work for both cfg80211 and wireless extensions with the same configuration.
I suggest netcfg because it is very convenient and flexible - and you can specifiy your own wpa_supplicant configuration sections if you need something that netcfg doesn't support, so it supports anything. A dialog-driven netcfg profile generator has been on my imaginary TODO-list for some time. It would be great for new Arch users.
Actually, from the installer's perspective, locale.gen and mkinitcpio.conf are the only reasons to re-run either generation script. If other things change, the user had to do them *outside* the installer. From within the installer, the only thing you can do is change the config files. If those are unchanged, you're going to generate the exact same output as they did on install.
Assuming pacman does everything in the order we expect it to, yes.
Am Fri, 16 Apr 2010 07:14:48 -0500 schrieb Aaron Griffin aaronmgriffin@gmail.com:
Well, a tool in netcfg for wireless configuration is necessary, but AIF shouldn't treat wireless interfaces the same as wired interfaces.
And what about people, who haven't got a wired internet connection but only a wireless one? They rely on the possibility to configure a wireless network connection during installation.
Wireless tools probably don't need to be in the base group but it must be possible to install and configure them during installation and preferably in AIF.
And consider that there are as far as I know different WLAN chips which need different drivers and tools.
Heiko
Am 16.04.2010 15:29, schrieb Heiko Baums:
Well, a tool in netcfg for wireless configuration is necessary, but AIF shouldn't treat wireless interfaces the same as wired interfaces.
And what about people, who haven't got a wired internet connection but only a wireless one? They rely on the possibility to configure a wireless network connection during installation.
Wireless tools probably don't need to be in the base group but it must be possible to install and configure them during installation and preferably in AIF.
All necessary tools are contained in the live environment, regardless of them being in the base group or not.
And consider that there are as far as I know different WLAN chips which need different drivers and tools.
No. wpa_supplicant covers all of them, except for very ancient and broken drivers that can be considered "unsupported" anyway. Everything should thus work fine with netcfg profiles - that's why I suggest a netcfg profile generator that can be used from AIF.
On Fri, Apr 16, 2010 at 7:53 AM, Thomas Bächler thomas@archlinux.org wrote:
Am 16.04.2010 14:14, schrieb Aaron Griffin:
Well, a tool in netcfg for wireless configuration is necessary, but AIF shouldn't treat wireless interfaces the same as wired interfaces. I am unclear on the proper way to detect this in the days of deprecated iwconfig (Thomas? How would you list wired and wireless interfaces separately?) That covers #1 and #3.
See below.
Regarding direct editing of wpa_supplicant... I don't think that's "advanced" as Thomas suggests. It's heavily commented and not really that complex.
We still have no way in Arch to use "plain" wpa_supplicant, as it will never perform any IP configuration on its own. That's why we have net-auto-wireless.
Hm? I added my network to /etc/wpa_supplicant.conf, and ran wpa_supplicant -Dwext -something something something and the dhcpcd wlan0, and everything worked as expected. I'm not sure what you're talking about here
On Fri, 16 Apr 2010 09:53:36 -0500 Aaron Griffin aaronmgriffin@gmail.com wrote:
Hm? I added my network to /etc/wpa_supplicant.conf, and ran wpa_supplicant -Dwext -something something something and the dhcpcd wlan0, and everything worked as expected. I'm not sure what you're talking about here
yep that's also what I do in those rare cases that i use wireless. although i've had it with a certain wireless setup, that i could not get it to work (i always got 'no carrier detected', even after associating to the base station, or something. don't remember the specifics)
Dieter
Am 16.04.2010 16:53, schrieb Aaron Griffin:
Hm? I added my network to /etc/wpa_supplicant.conf, and ran wpa_supplicant -Dwext -something something something and the dhcpcd wlan0, and everything worked as expected. I'm not sure what you're talking about here
You did so _manually_. So basically you launched wpa_supplicant, waited until it associated (or waited some time in the hope association would be quick) and then ran dhcpcd.
If you want to use wireless on a daily basis, automating that process is a necesity. I worked on that with autowifi and recently ported everything I did over to netcfg-auto-wireless.
Autowifi actually works by configuring wpa_supplicant manually like you suggest, but I deprecated that in favor of the more intuitive configuration via network profiles that is now used in net-auto-wireless.
What I am saying is, you cannot just launch wpa_supplicant and then dhcpcd and expect it to work without further regard for connections being established and lost, wireless networks being changed and so on. We should encourage users to use these mechanisms implemented in netcfg already during the installation - that is why I want to encourage them to create netcfg profiles during installation. If a user insists on messing with wpa_supplicant and dhcpcd manually, then (s)he can do so, but it's not necessary to add this to the installer as a recommendation when there's a superior method available.
On Fri, Apr 16, 2010 at 10:05 AM, Thomas Bächler thomas@archlinux.org wrote:
Am 16.04.2010 16:53, schrieb Aaron Griffin:
Hm? I added my network to /etc/wpa_supplicant.conf, and ran wpa_supplicant -Dwext -something something something and the dhcpcd wlan0, and everything worked as expected. I'm not sure what you're talking about here
You did so _manually_. So basically you launched wpa_supplicant, waited until it associated (or waited some time in the hope association would be quick) and then ran dhcpcd.
If you want to use wireless on a daily basis, automating that process is a necesity. I worked on that with autowifi and recently ported everything I did over to netcfg-auto-wireless.
Autowifi actually works by configuring wpa_supplicant manually like you suggest, but I deprecated that in favor of the more intuitive configuration via network profiles that is now used in net-auto-wireless.
What I am saying is, you cannot just launch wpa_supplicant and then dhcpcd and expect it to work without further regard for connections being established and lost, wireless networks being changed and so on. We should encourage users to use these mechanisms implemented in netcfg already during the installation - that is why I want to encourage them to create netcfg profiles during installation. If a user insists on messing with wpa_supplicant and dhcpcd manually, then (s)he can do so, but it's not necessary to add this to the installer as a recommendation when there's a superior method available.
Ok, I'll give you that. But I still fear an over-reliance on netcfg. The reason is that it is not "portable knowledge" and is only useful on Arch systems. This is one of the things is dislike about Debian/Ubuntu - a lot of the configuration stuff they do is unique to the system and that knowledge doesn't transcend operating systems.
Still, in the context of AIF, using netcfg isn't too bad of an issue. I wonder how much word it'd be to cobble together a netcfg "profile maker" app that AIF could then use....
On Fri, 16 Apr 2010 10:46:55 -0500 Aaron Griffin aaronmgriffin@gmail.com wrote:
On Fri, Apr 16, 2010 at 10:05 AM, Thomas Bächler thomas@archlinux.org wrote:
Am 16.04.2010 16:53, schrieb Aaron Griffin:
Hm? I added my network to /etc/wpa_supplicant.conf, and ran wpa_supplicant -Dwext -something something something and the dhcpcd wlan0, and everything worked as expected. I'm not sure what you're talking about here
You did so _manually_. So basically you launched wpa_supplicant, waited until it associated (or waited some time in the hope association would be quick) and then ran dhcpcd.
If you want to use wireless on a daily basis, automating that process is a necesity. I worked on that with autowifi and recently ported everything I did over to netcfg-auto-wireless.
Autowifi actually works by configuring wpa_supplicant manually like you suggest, but I deprecated that in favor of the more intuitive configuration via network profiles that is now used in net-auto-wireless.
What I am saying is, you cannot just launch wpa_supplicant and then dhcpcd and expect it to work without further regard for connections being established and lost, wireless networks being changed and so on. We should encourage users to use these mechanisms implemented in netcfg already during the installation - that is why I want to encourage them to create netcfg profiles during installation. If a user insists on messing with wpa_supplicant and dhcpcd manually, then (s)he can do so, but it's not necessary to add this to the installer as a recommendation when there's a superior method available.
Ok, I'll give you that. But I still fear an over-reliance on netcfg. The reason is that it is not "portable knowledge" and is only useful on Arch systems. This is one of the things is dislike about Debian/Ubuntu - a lot of the configuration stuff they do is unique to the system and that knowledge doesn't transcend operating systems.
i don't really use netcfg myself, but the explanation Thomas has given above doesn't seem too arch specific; and from a quick glance at http://wiki.archlinux.org/index.php/Netcfg it seems netcfg is not - or at least should not have to be - very arch-specific. maybe we should treat it more as a separate project (like pacman or libui-sh) and integrate it into our initscripts like we already do.
Also there's this duality for a while that our networking initscripts are really basic and limited, and netcfg should fix all that, but it's not very "official" or "recommended" or whatever. maybe it's time to unify things into 1 networking configuration utility (which, still doesn't need to be bound to arch linux), it will make things easier for everyone. so we could only use netcfg and drop the other limited stuff.
Dieter
Am 16.04.2010 18:28, schrieb Dieter Plaetinck:
i don't really use netcfg myself, but the explanation Thomas has given above doesn't seem too arch specific; and from a quick glance at http://wiki.archlinux.org/index.php/Netcfg it seems netcfg is not - or at least should not have to be - very arch-specific. maybe we should treat it more as a separate project (like pacman or libui-sh) and integrate it into our initscripts like we already do.
I would want to integrate such a script into netcfg itself. It would be a great tool for beginners to create an initial set of netcfg profiles. Nobody has to use it though, but everyone can.
arch-releng@lists.archlinux.org