It seems the function wpa_supplicant_exists in /lib64/rcscripts/net/wpa_supplicant.sh fails to recognize that the interface is a wireless interface because neither ${iface}/wiphy nor ${interface}/wireless exist. Relevant kernel options should be CFG80211_WEXT and WIRELESS_EXT_SYSFS. I am currently recompiling the kernel with compatibility options set and will report if the init script starts wpa_supplicant. wpa_supplicant version is 0.7.1, baselayout is 1.12.13, kernel version is vanilla-sources-2.6.33. Reproducible: Always Portage 2.1.7.17 (default/linux/amd64/10.0/server, gcc-4.3.4, glibc-2.10.1-r1, 2.6.33 x86_64) ================================================================= System uname: Linux-2.6.33-x86_64-Intel-R-_Core-TM-2_Duo_CPU_P9500_@_2.53GHz-with-gentoo-1.12.13 Timestamp of tree: Sun, 28 Feb 2010 11:30:01 +0000 app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=nocona" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.mneisen.org/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="de_DE.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="de en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/tmp/" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/pd-overlay /usr/local/portage/layman/sunrise /usr/portage/local/ownbuilds" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa amd64 berkdb bzip2 cli consolekit cracklib crypt cups cxx dbus dell dri emacs fam fortran gdbm gpm gtk hal iconv ipv6 jpeg laptop mmx modules mudflap multilib ncurses nls nptl nptlonly opengl openmp pam pch pcre perl pppd python qt3support qt4 readline reflection session snmp spl sse sse2 ssl sysfs tcpd truetype unicode xinerama xorg xv zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="canon ptp2" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Indeed, setting CFG80211_WEXT and WIRELESS_EXT_SYSFS starts wpa_supplicant. I don't know which files need to be checked instead of ${iface}/wiphy or ${iface}/wireless
I stumbled into this yesterday. The problem is in line 50: - [[ -L /sys/class/net/$1/wiphy || -d /sys/class/net/$1/wireless ]] \ + [[ -L /sys/class/net/$1/phy80211 || -d /sys/class/net/$1/wireless ]] \ FF, Daniel
There are no plans to fix this in baselayout 1. Please upgrade your system to openrc/baselayout-2 and feel free to re-open this bug if the issue still occurs. Thanks much, William
Hi William. Why can't this be fixed when the solution is so easy? This bug will be an ongoing headache for stable users and new installations, as evidenced by the fact that there are two duplicates already: #321663 and #336082. This is a trivial fix compared to the dhcpcd bug that we successfully backported recently. I really hope that we can release a fixed baselayout-1 soon.
*** Bug 321663 has been marked as a duplicate of this bug. ***
What does test-request mean?(In reply to comment #4) > Hi William. Why can't this be fixed when the solution is so easy? > This bug > will be an ongoing headache for stable users and new installations, as > evidenced by the fact that there are two duplicates already: #321663 and > #336082. This is a trivial fix compared to the dhcpcd bug that we successfully > backported recently. I really hope that we can release a fixed baselayout-1 > soon. > Yes, I have the same opinion. This should be fixed! What does "resolved test-request" mean? This was the reason I did not found this bug with the bugzilla search and opend the dublicate 321663.
TEST-REQUEST means that the fix should be commited and tried out by the original submitter (which is me). I'll test for this on my next kernel update if nobody beats me to it...
(In reply to comment #2) > I stumbled into this yesterday. The problem is in line 50: > - [[ -L /sys/class/net/$1/wiphy || -d /sys/class/net/$1/wireless ]] \ > + [[ -L /sys/class/net/$1/phy80211 || -d /sys/class/net/$1/wireless ]] \ > > FF, > > Daniel > Well, I had already tested it yesterday, so can confirm that this solution works for me. :)
Indeed, the fix works for me too from bug 321663. However what kind of utter nonsense is it that William Hubbs states the Gentoo maintainers won't fix it for stable?!? And as for upgrading to _unstable_ baselayout-2 instead, no. Only if baselayout-2 were to be actually stabilised but that comment was 6 months ago and it certainly still doesn't look like happening anytime soon.
I spoke with the base system lead about this bug. He said that if someone will attach a patch that doesn't break things for other stable users he will apply it. Also, be aware that he isn't in a position that will allow him to test wireless in baselayout-1. This is true for myself as well, and I do not intend to downgrade my laptop to baselayout-1 to test, so please make sure that your patch doesn't break things for any other stable users. WRT the question about what test-request means, comment #4 was my comment when I resolved this bug, so I was asking the original submitter to upgrade to openrc/baselayout-2 and let us know if this bug still occurs.
Created attachment 263735 [details, diff] "wiphy" -> "phy80211" Hi William, thanks for following up and reopening this bug. Daniel provided the fix in comment #2, so this is just putting it into a diff file. So, we need to make sure that our arch testing teams have some nl80211 wireless devices amongst them AND that they turn WE compatibility off when they are testing.
The patch is working for me (amd64, ath5k). HUjuice
openrc is stable and my understanding is that it doesnt have this problem
*** Bug 307703 has been marked as a duplicate of this bug. ***
