Re: [lfs-support] Using wpa_supplicant [Was: ifup--a really uninformed question]
Dan McGhee wrote:
On 11/02/2013 02:50 PM, Bruce Dubbs wrote:
Dan McGhee wrote:
(Received complaints about /run/var/bootlog all through the process.
They were right, it doesn't exist yet.)
Do you have /run/var?
I just discovered. No I don't. Nor do I have /run/lock. I looked in the
book Sections 6.5 and 6.6 to see where and how I missed these. I didn't
see their creation in either section. Would you please tell me where in
the book they get created? I've got to see if I missed anything else.
/etc/init.d/mountvirtfs
When I create them, just to double check, make sure the permissions are
0755?
Only /run/shm needs the permissions changed.
/run is mounted form fstab
tmpfs/run tmpfs defaults 0 0
in the very first boot boot script (mountvirtfs):
# Make sure /run/var is available before logging any messages
if ! mountpoint /run /dev/null; then
mount /run || failed=1
fi
mkdir -p /run/var /run/lock /run/shm
...
The scripts all use so the only reason that you would get this error
is iv /run is not mounted. Actually, even then the writing would be to
a standard directory so the issue would be permissions. These scripts
need to be run as root.
That's great info. Thanks. Referencing the paragraph above, the
directories /run/{var,lock} get created the first time the system boots?
I do have /run/shm. It got created in Section 6.2.
Since I'm operating in chroot, I need to mount /run. Again, to double
check, is the following command the one to use?
mount -v -t tmpfs tmpfs /run
That would probably work.
If the bootscripts are exiting, then it's no wonder that my efforts are
failing. I consider this one of the simple things that I miss. My
knowledge of the bootscripts is slowly coming back. I knew them well six
years ago. :)
The bootscripts were completely rewritten for LFS 7.0. That's why we
are at 7.x and not 6.x.
Before I forget. Once I get the directory thing straightened out, should
I, as root, touch /run/var/bootlog?
That wouldn't be needed if /ver/run has been created, but I don't
understand running the bootscripts in chroot. Why are you trying to do
that?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Using wpa_supplicant [Was: ifup--a really uninformed question]
On 11/03/2013 11:14 AM, Bruce Dubbs wrote: If the bootscripts are exiting, then it's no wonder that my efforts are failing. I consider this one of the simple things that I miss. My knowledge of the bootscripts is slowly coming back. I knew them well six years ago. :) The bootscripts were completely rewritten for LFS 7.0. That's why we are at 7.x and not 6.x. I had noticed some big differences from what I was used to. My last complete LFS build was 6.7. I was going to ask later, but you just let me know. Thanks. Before I forget. Once I get the directory thing straightened out, should I, as root, touch /run/var/bootlog? That wouldn't be needed if /ver/run has been created, but I don't understand running the bootscripts in chroot. Why are you trying to do that? -- Bruce The original situation got lost in the responses to a passing comment I made when I originally posted. The comment was that 'ifup' complained that /run/var/bootlog didn't exist. I want to build up through Xorg in chroot. I've done it before, but I used the host system to down load packages and patches and read the book. I thought that if I could get my wifi working in chroot then I could do what I wanted to and could download packages directly to the LFS tree without having to go through the host system to do that. Just an idea to make it easier for me. I posted in LFS because I didn't know if this was possible in chroot and knew that someone would tell me if it weren't. The problem I'm having is a BLFS one in that I've not configured either dhcpcd or wpa_supplicant correctly. I'm learning that it might be an Ubuntu phenomenon. Short version with no more info is that my card wlan0 authenticates and, then, immediately de-authenticates. I'm still trying to troubleshoot and learn. But.with the info about the bootscripts, I got rid of the error messages in chroot. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Using wpa_supplicant [Was: ifup--a really uninformed question]
I'm still on the trail of getting my wireless up in chroot. I have all the ifconfig files I need, and, except for the static stuff in Ch. 7 of the book, they are cut and paste from BLFS. This time in chroot, after I had turned off my card in the host system I used /etc/rc.d/init.d/network start for my command. The third set of screen output was: Starting wpa_supplicant on the wlan0 interface.../lib/lsb/init-functions: line 664: /run/var/bootlog: No such file or directory Could not set interface wlan0 flags (UP): Operation not possible due to RF-kill * [ OK ] (Received complaints about /run/var/bootlog all through the process. They were right, it doesn't exist yet.) The last line of screen output was: /lib/lsb/init-functions: line 586: /run/var/bootlog: No such file or directory RTNETLINK answers: Operation not possible due to RF-kill I don't know how, when or where the RF-kill generates, but based on the fact that it's a kernel message, I'm wondering if it didn't originate somewhere in the wpa_supplicant process because dmesg gave me the following when I checked it after I couldn't ping anything. [ 3547.476338] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 3554.073619] wlan0: authenticate with c4:3d:c7:70:07:e7 [ 3554.088957] wlan0: send auth to c4:3d:c7:70:07:e7 (try 1/3) [ 3554.090954] wlan0: authenticated [ 3554.092919] wlan0: associate with c4:3d:c7:70:07:e7 (try 1/3) [ 3554.096066] wlan0: RX AssocResp from c4:3d:c7:70:07:e7 (capab=0x411 status=0 aid=2) [ 3554.096156] wlan0: associated [ 3554.096256] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 4217.269801] wlan0: deauthenticating from c4:3d:c7:70:07:e7 by local choice (reason=3) Compare that output with this output when I awoke my laptop from sleep a little later. [ 4246.722109] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 4248.988116] wlan0: authenticate with c4:3d:c7:70:07:e7 [ 4249.003441] wlan0: send auth to c4:3d:c7:70:07:e7 (try 1/3) [ 4249.004987] wlan0: authenticated [ 4249.007303] wlan0: associate with c4:3d:c7:70:07:e7 (try 1/3) [ 4249.010487] wlan0: RX AssocResp from c4:3d:c7:70:07:e7 (capab=0x411 status=0 aid=2) [ 4249.010571] wlan0: associated (I accidently cut off the last line which stated that wlan0 link was ready.) They are both identical except for that last line in the first set. If I am correct, the authenticate/deauthenticate stuff comes from wpa_supplicant. I'm not sure what is happening. I checked after the failed attempt and all the right drivers were loaded. I think wpa_supplicant has everything it needs based on the config file and the arguments in its service script. The only other thing I can think of right now is d-bus. Because I ultimately want to run wpa_supplicant with Network Manager, I installed d-bus and built and configured wpa_supplicant with d-bus support. My question is, then, do I need to start the d-bus daemon as a result? Is wpa_supplicant not talking to whom it needs to speak. I've not used d-bus or wpa_supplicant on such an intimate level. I Ubuntu it just happens. The last current question I have is, in the service script for wpa_supplicant, it is called with the -q option for little debugging operation. If I add -d, for more debug info, in the ifconfig.wifi0 file under WPA_ARGS=, will that over ride the behavior of the service script? In the meantime, I'm trying to learn how to use wpa_cli so that I might get a better handle on what's happening. Obviously, I'm focusing on wpa_supplicant right now. Does anyone see another or different alternative to where the problem might be? Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Using wpa_supplicant [Was: ifup--a really uninformed question]
Dan McGhee wrote: (Received complaints about /run/var/bootlog all through the process. They were right, it doesn't exist yet.) Do you have /run/var? /run is mounted form fstab tmpfs/run tmpfs defaults 0 0 in the very first boot boot script (mountvirtfs): # Make sure /run/var is available before logging any messages if ! mountpoint /run /dev/null; then mount /run || failed=1 fi mkdir -p /run/var /run/lock /run/shm ... The scripts all use so the only reason that you would get this error is iv /run is not mounted. Actually, even then the writing would be to a standard directory so the issue would be permissions. These scripts need to be run as root. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Using wpa_supplicant [Was: ifup--a really uninformed question]
On 11/02/2013 02:50 PM, Bruce Dubbs wrote:
Dan McGhee wrote:
(Received complaints about /run/var/bootlog all through the process.
They were right, it doesn't exist yet.)
Do you have /run/var?
I just discovered. No I don't. Nor do I have /run/lock. I looked in the
book Sections 6.5 and 6.6 to see where and how I missed these. I didn't
see their creation in either section. Would you please tell me where in
the book they get created? I've got to see if I missed anything else.
When I create them, just to double check, make sure the permissions are
0755?
/run is mounted form fstab
tmpfs/run tmpfs defaults 0 0
in the very first boot boot script (mountvirtfs):
# Make sure /run/var is available before logging any messages
if ! mountpoint /run /dev/null; then
mount /run || failed=1
fi
mkdir -p /run/var /run/lock /run/shm
...
The scripts all use so the only reason that you would get this error
is iv /run is not mounted. Actually, even then the writing would be to
a standard directory so the issue would be permissions. These scripts
need to be run as root.
That's great info. Thanks. Referencing the paragraph above, the
directories /run/{var,lock} get created the first time the system boots?
I do have /run/shm. It got created in Section 6.2.
Since I'm operating in chroot, I need to mount /run. Again, to double
check, is the following command the one to use?
mount -v -t tmpfs tmpfs /run
If the bootscripts are exiting, then it's no wonder that my efforts are
failing. I consider this one of the simple things that I miss. My
knowledge of the bootscripts is slowly coming back. I knew them well six
years ago. :)
Before I forget. Once I get the directory thing straightened out, should
I, as root, touch /run/var/bootlog?
Thanks, Bruce,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Using wpa_supplicant [Was: ifup--a really uninformed question]
Le 02/11/2013 21:57, Dan McGhee a écrit :
On 11/02/2013 02:50 PM, Bruce Dubbs wrote:
Dan McGhee wrote:
(Received complaints about /run/var/bootlog all through the process.
They were right, it doesn't exist yet.)
Do you have /run/var?
I just discovered. No I don't. Nor do I have /run/lock. I looked in the
book Sections 6.5 and 6.6 to see where and how I missed these. I didn't
see their creation in either section. Would you please tell me where in
the book they get created? I've got to see if I missed anything else.
When I create them, just to double check, make sure the permissions are
0755?
/run is mounted form fstab
tmpfs/run tmpfs defaults 0 0
in the very first boot boot script (mountvirtfs):
# Make sure /run/var is available before logging any messages
if ! mountpoint /run /dev/null; then
mount /run || failed=1
fi
mkdir -p /run/var /run/lock /run/shm
...
The scripts all use so the only reason that you would get this error
is iv /run is not mounted. Actually, even then the writing would be to
a standard directory so the issue would be permissions. These scripts
need to be run as root.
That's great info. Thanks. Referencing the paragraph above, the
directories /run/{var,lock} get created the first time the system boots?
Since /run is mounted on a tmpfs, everything on it is lost once you reboot. So
actually /run/{var,lock,shm} get created at each boot.
I do have /run/shm. It got created in Section 6.2.
That static /run/shm will disappear once you mount /run.
Since I'm operating in chroot, I need to mount /run. Again, to double
check, is the following command the one to use?
mount -v -t tmpfs tmpfs /run
Seems OK.
If the bootscripts are exiting, then it's no wonder that my efforts are
failing. I consider this one of the simple things that I miss. My
knowledge of the bootscripts is slowly coming back. I knew them well six
years ago. :)
Before I forget. Once I get the directory thing straightened out, should
I, as root, touch /run/var/bootlog?
I think it is not needed. You need to mkdir /run/var (see script above)
Thanks, Bruce,
Dan
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
