Welcome to the Linux Foundation Forum!

BT module in Slackware

chekkizhar
chekkizhar Posts: 182

How to enable bluetooth in slackware?

Comments

  • marc
    marc Posts: 647
    linustorvalds wrote:
    How to enable bluetooth in slackware?

    Install bluez and bluez-utils

    modprobe bluetooth

    /etc/init.d/bluetooth start (or service bluetooth start)

    hcitool scan

    There you go.

    You could as well have a look at installing gnome-bluetooth or bluedevil (for kde)

    Regards
  • mfillpot
    mfillpot Posts: 2,177
    if you performed a full installation then the bluetooth libraries and applications are installed, you will only need to start the service by running (as root) "sh /etc/rc.d/rc.bluetooth" and if you want the service to start on boot you need to set /etc/rc.d/rc.bluetooth to be executable. The blueman gui configuration tool is also installed in a full slackware installation for simplified configuration.
  • chekkizhar
    chekkizhar Posts: 182
    I installed Slackware almost with default settings. Is there any way to find out whether the installation is full one?

    When i tried "sh /etc/rc/d/rc/bluetooth" i got "Usage: { start|stop|restart}
    I append start with that command. Simply the terminal promt came without any success/failed messge

    when I tried "/etc/rc/d/rc/bluetooth" alone, I got "Permission Denied". But, I ran as root only.

    With gui, If i click bluetooth manager, its saying, "Bluez deamon is not running,blueman manager can not continue"


    "/etc/rc.d/rc.bluetooth executable?" No, when I checked the mode, there was no execute permission for anyone.

    Then I changed the permissions. Now, its working. Thank you very much.

    I tried so many forums and tried a lot. But, mathew, the word you told about, "executable" solved my problem. But, not for start on boot , even for manual start also, it should be executable, I think. you are GREAT:lol:

    thank you marc , since bluetooth installed already with distro, I finished with simple mode changing. thanks man:laugh:
  • chekkizhar
    chekkizhar Posts: 182
    thank you marc , since bluetooth installed already with distro, I finished with simple mode changing. thanks man
  • chekkizhar
    chekkizhar Posts: 182
    I hope, I almost know who is the 2012 Linux Guru?. any guess mathew ? :-)

    and why there is no default permission to execute "/etc/rc.d/rc.bluetooth", even for root ? what reason ?
  • marc
    marc Posts: 647
    linustorvalds wrote:
    I hope, I almost know who is the 2012 Linux Guru?. any guess mathew ? :-)

    and why there is no default permission to execute "/etc/rc.d/rc.bluetooth", even for root ? what reason ?

    That looks like a bug.

    If you feel up to it, check the Slackware bugtracker and submit a bug report if it's not already there.

    Regards

    PS: in *nix like permission system execute bit is not for "root" rather than for the owner, group or everybody else ;)
  • chekkizhar
    chekkizhar Posts: 182
    "If you feel up to it, check the Slackware bugtracker and submit a bug report if it's not already there."

    ok

    " "in *nix like permission system execute bit is not for "root" rather than for the owner, group or everybody else"
    ya, its user-group-others.
    thanks man :-)
  • mfillpot
    mfillpot Posts: 2,177
    I am hoping that someone else gets ultimate guru this year, we have plenty of very knowledgeable and active people on the site that can easily take that title next year. Rather than focusing on the title, I try more to built an active community on the site with knowledgeable and helpful people. Marc and Eric Layton are my two top hopefuls for the top spot next year.

    Sorry, the correct command that you were to run on /etc/rc.d/rc.bluetooth was "/etc/rc.d/rc.bluetooth start", I guess I forgot to type a single word.

    The starting permissions of the files in /etc/rc.d were set by you in the initial installation, when it asked what services you want it changed each of the chosen files to executable, so you did not select to use the bluetooth service when you installed. That can be changed at any time in the terminal by tunning pkgtool, which will allow you to change most of the options that were chosen when you installed slackware.

    The way the slackware init system works is that, in most cases when a service setup script in /etc/rc.d is set to executable it will be launched by the system when it is booted. You must remember that slackware does not really use any defaults, most things that will effect you are chosen when you install the OS, in this case you skipped through the step about choosing which services to use.
  • mfillpot
    mfillpot Posts: 2,177
    marc wrote:
    linustorvalds wrote:
    I hope, I almost know who is the 2012 Linux Guru?. any guess mathew ? :-)

    and why there is no default permission to execute "/etc/rc.d/rc.bluetooth", even for root ? what reason ?

    That looks like a bug.

    If you feel up to it, check the Slackware bugtracker and submit a bug report if it's not already there.

    Regards

    PS: in *nix like permission system execute bit is not for "root" rather than for the owner, group or everybody else ;)

    As explained in my other post, not setting the script as executable by default is a feature, not a bug, the user forgot to choose to enable the Bluetooth service when it was installed. Plus, Slackware does not have a bug-tracker it only has Pat..lol

    You will find that the lack of assumptions and the different organization by the development team in Slackware defy what other distros do. These differences are considered strengths by many of their users, but tend to confused people who come from more user-friendly distros
  • chekkizhar
    chekkizhar Posts: 182
    " Rather than focusing on the title, I try more to built an active community on the site with knowledgeable and helpful people."

    Great :-)

    " Marc and Eric Layton are my two top hopefuls for the top spot next year. "

    we are also waiting. I feel like waiting for my school results

    " Sorry, the correct command that you were to run on /etc/rc.d/rc.bluetooth was "/etc/rc.d/rc.bluetooth start", I guess I forgot to type a single word. "

    No problem. It happens to everyone



    "you did not select to use the bluetooth service when you installed"

    may be. Next time, I will be more alert during installation.



    " slackware does not really use any defaults, most things that will effect you are chosen when you install the OS "

    thats why more people are afraid to use this beast. For the same reason, I want to use this lovely OS :-)

    thank you matt.
  • marc
    marc Posts: 647
    mfillpot wrote:
    The starting permissions of the files in /etc/rc.d were set by you in the initial installation, when it asked what services you want it changed each of the chosen files to executable, so you did not select to use the bluetooth service when you installed. That can be changed at any time in the terminal by tunning pkgtool, which will allow you to change most of the options that were chosen when you installed slackware.

    I don't think that's usefull. At all.

    It could sound correct from a security point of view but... it's not as you could always just
    sh /what/ever/script
    

    And you'd still be able to run the script.

    Therefore, removing the executable possibility from a script that is there for, well, be executed looks like nonsense to me.

    Regards
  • mfillpot
    mfillpot Posts: 2,177
    The installed system scripts work that way because there are scripts in rc.local and rc.M stating to check the specific system scripts for executable rights prior to launching them. People cannot just drop executable scripts into the folder and expect them to work, they must first add the correct initialization scripts to the correct files. I consider this a better method than what is used by distros that use the SystemV init method in which any executable script that is placed into a runlevel folder is executed without any further modifications.
  • marc
    marc Posts: 647
    mfillpot wrote:
    The installed system scripts work that way because there are scripts in rc.local and rc.M stating to check the specific system scripts for executable rights prior to launching them. People cannot just drop executable scripts into the folder and expect them to work, they must first add the correct initialization scripts to the correct files. I consider this a better method than what is used by distros that use the SystemV init method in which any executable script that is placed into a runlevel folder is executed without any further modifications.

    Regular users do not have access to those folders

    Anyway, I rather use Archlinux aproach with a line in rc.conf containing which scripts to run at startup ;)

    Using this you avoid the "problem" you were mentioning and selection of what to run or not is a matter of editing a text file. Ya know, KISS philosofy.

    Regards
  • mfillpot
    mfillpot Posts: 2,177
    The other benefit we get from that method is the ability to simply start, stop and restart a service for testing or loading of new configuration files without setting the service to launch on boot. I recommend checking out some of the script files to see what they can do to make life easier.

    As for the arch method, I am still trying to get used to all of the components of arch, it has some benefits but the dependency resolution still drives me crazy.
  • chekkizhar
    chekkizhar Posts: 182
    from you people, strong healthy technical discussion, I learnt/learning a lot. I am really enjoying this site like anything
  • marc
    marc Posts: 647
    mfillpot wrote:
    The other benefit we get from that method is the ability to simply start, stop and restart a service for testing or loading of new configuration files without setting the service to launch on boot. I recommend checking out some of the script files to see what they can do to make life easier.

    That's the thing, you can do just the same with the Arch method.

    The thing is that you achieve the same with both aproaches but I find the arch one much more human friendly than Slackware's.

    Regards
  • atreyu
    atreyu Posts: 216
    mfillpot wrote:
    The installed system scripts work that way because there are scripts in rc.local and rc.M stating to check the specific system scripts for executable rights prior to launching them. People cannot just drop executable scripts into the folder and expect them to work, they must first add the correct initialization scripts to the correct files. I consider this a better method than what is used by distros that use the SystemV init method in which any executable script that is placed into a runlevel folder is executed without any further modifications.
    At least with Fedora/RH-based Linux, system initscripts will not be run by the system unless the proper symlinks have been generated for them for the specific runlevels in which they are supposed to run. These runlevels are defined at the top of each initscript ( e.g., "# chkconfig: - 85 15" ). So you can drop an executable script in /etc/init.d/ but it won't run until you:

    a) put the proper "chkconfig" entry at the top of the script
    b) run a command to create the symlinks, e.g. "chkconfig --add myService" , or create them manually
  • marc
    marc Posts: 647
    atreyu wrote:
    mfillpot wrote:
    At least with Fedora/RH-based Linux, system initscripts will not be run by the system unless the proper symlinks have been generated for them for the specific runlevels in which they are supposed to run. These runlevels are defined at the top of each initscript ( e.g., "# chkconfig: - 85 15" ). So you can drop an executable script in /etc/init.d/ but it won't run until you:

    a) put the proper "chkconfig" entry at the top of the script
    b) run a command to create the symlinks, e.g. "chkconfig --add myService" , or create them manually


    In fact, this is how is defined in the standard ;)

    Regards
  • Hi, after some long time, I hardly need to open this thread again. I am facing problem with my blueman-manager. Actually, I re-installed Slackware due to some KDE problems and for past 2-3 months am trying to use the BT service. I strongly doubt that, the same problem may be a reason for my home wireless router is not getting listed in wicd.

    In my system, I need to move same physical button for BT as well as for wireless network.

    I can able to do the above both in Windows. So, in that way, there is no problem with actual device inside the system

    So, I want to get the BT to work and possibly try with wlan issue.

    This is what I am getting , when I ran "blueman-manager" from terminal,
    ########################################################################################################################
    bash-4.1$ blueman-manager
    Loading configuration plugins
    _________
    <module> (/usr/lib/python2.6/site-packages/blueman/main/Config.py:20)
    Skipping plugin Gconf
    No module named gconf
    Using file config backend
    _________
    Load (/usr/lib/python2.6/site-packages/blueman/main/PluginManager.py:68)

    _________
    Load (/usr/lib/python2.6/site-packages/blueman/main/PluginManager.py:68)
    Unable to load plugin module PulseAudioProfile
    PulseAudio applet plugin not loaded, nothing to do here
    _________
    __load_plugin (/usr/lib/python2.6/site-packages/blueman/main/PluginManager.py:142)
    loading <class 'blueman.plugins.manager.Services.Services'>
    blueman-manager version 1.22 starting
    _________
    on_bluez_name_owner_changed (/usr/bin/blueman-manager:110)
    org.bluez owner changed to :1.25
    Using file config backend
    _________
    SetAdapter (/usr/lib/python2.6/site-packages/blueman/gui/DeviceList.py:301)
    None
    Traceback (most recent call last):
    File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 586, in msg_reply_handler
    reply_handler(*message.get_args_list(**get_args_opts))
    File "/usr/bin/blueman-manager", line 162, in on_bluez_name_owner_changed
    self.List = ManagerDeviceList(adapter=self.Config.props.last_adapter, inst=self)
    File "/usr/lib/python2.6/site-packages/blueman/gui/manager/ManagerDeviceList.py", line 71, in __init__
    DeviceList.__init__(self, adapter, data)
    File "/usr/lib/python2.6/site-packages/blueman/gui/DeviceList.py", line 122, in __init__
    self.SetAdapter(adapter)
    File "/usr/lib/python2.6/site-packages/blueman/gui/DeviceList.py", line 332, in SetAdapter
    except dbus.DBusServiceUnknownError:
    AttributeError: 'module' object has no attribute 'DBusServiceUnknownError'
    ^CTraceback (most recent call last):
    File "/usr/bin/blueman-manager", line 301, in <module>
    Blueman()
    File "/usr/bin/blueman-manager", line 188, in __init__
    gtk.main()
    KeyboardInterrupt
    _________
    save (/usr/lib/python2.6/site-packages/blueman/plugins/config/File.py:117)
    Saving config
    Exception AttributeError: "'NoneType' object has no attribute 'Bus'" in <bound method File.__del__ of <File object at 0x84d198c (blueman+plugins+ConfigPlugin+ConfigPlugin at 0x82c4f30)>> ignored
    ########################################################################################################################
    Thanks,
  • mfillpot
    mfillpot Posts: 2,177
    Have you checked the proc directory to locate the files that controls your bluetooth and wifi radios? One you find those files and figure out the commands you can script the system to enable both on boot.

    As for the errors, I would be best to focus on both of those after the radios are activated.
  • thanks Mathew. I expected your reply.

    Can you please help me out to find out those two in /proc dir. I can not able to find anything related to radios in that dir.

    in iomem file I can not able to find any word "radio" or bluetooth"
    I can not understand and not fully aware of the error it is saying about , "Dbus"...
  • mfillpot
    mfillpot Posts: 2,177
    Sorry the trigger files are not in /proc, they are in sys. You can locate them by using "find /sys/ -name state" , this will output the state files (on/off) for all devices on your system, generally your wireless will be listed with 80211 such as "/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill0/state" and something similar will be listed for the bluetooth most likely citing the protocol.
  • thats ok and here is the output,
    ################################################################################################################
    /sys/devices/virtual/video_output/acpi_video0/state
    /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:0c/PNP0C09:00/VPC2004:00/rfkill/rfkill0/state
    /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:0c/PNP0C09:00/VPC2004:00/rfkill/rfkill1/state
    /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:0c/PNP0C09:00/VPC2004:00/rfkill/rfkill3/state
    /sys/devices/pci0000:00/0000:00:02.0/graphics/fb0/state
    /sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill2/state
    /sys/devices/pci0000:00/0000:00:1f.2/host2/scsi_host/host2/state
    /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/state
    /sys/devices/pci0000:00/0000:00:1f.2/host3/scsi_host/host3/state
    /sys/devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/state
    /sys/devices/pci0000:00/0000:00:1f.2/host4/scsi_host/host4/state
    /sys/devices/pci0000:00/0000:00:1f.2/host5/scsi_host/host5/state
    /sys/devices/pci0000:00/0000:00:1f.2/host6/scsi_host/host6/state
    /sys/power/state
    ################################################################################################################
    and I guess, the one we need is,
    /sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill2/state. then, what I need to do ?

    Thanks a lot matt
  • mfillpot
    mfillpot Posts: 2,177
    Now we have something to work with and can see that rfkill is enabled for multiple devices.

    You can cat /sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill2/stat to see if the wifi radio is on.

    But with rfkill it becomes easier, use "rfkill list" to see the states of each available device which may include your bluetooth adapter, once you figure out the names for each you can type "rfkill unblock {device}" to turn a radio on and "rfkill block {device}" to turn a radio off.

    After you test and confirm the rfkill command you can add a script into your rc.d scripts to start each radio on boot.
  • thanks Matthew. BT is still has problem. But, as of now, my goal is to use/access my wifi connection, and that is done by enabling the things using "rfkill".

Categories

Upcoming Training