Launchpad has imported 58 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=570073.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2010-03-03T08:12:26+00:00 sassmann wrote:

Description of problem:
On my lenovo t500 bluetooth is always enabled after reboot, regardless if it 
was turned off before the reboot or not. Not sure why this happens but someway 
during initrd run I see the bluetooth LED turning on.

Version-Release number of selected component (if applicable):
gnome-bluetooth-2.28.6-2.fc12.x86_64

How reproducible:
always

Steps to Reproduce:
1. turn off bluetooth in gnome-bluetooth applet
2. reboot
3.
  
Actual results:
bluetooth is always turned on

Expected results:
bluetooth setting is the same as before the reboot

Additional info:

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/27

------------------------------------------------------------------------
On 2010-06-30T08:16:46+00:00 jpazdziora wrote:

The same problem on Fedora 13 with gnome-bluetooth-2.30.0-1.fc13.i686 on
T61. Bastien, please, let us know if some other package might be causing
this and you'd need more detailed version info, or if it is configurable
somewhere.

I am pretty sure that on Fedora 11 my bluetooth was off after reboot
(and I had the option to turn it on with the applet on my panel). That's
why I'd consider this a regression.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/44

------------------------------------------------------------------------
On 2010-06-30T08:41:22+00:00 jpazdziora wrote:

Funny thing: if I change in /etc/bluetooth/main.conf InitiallyPowered =
true to false, and reboot, the applet will show that white x in red on
its icon, to say that bluetooth is off. However, the bluetooth LED is
still on, so in that case the applet shows incorrect information.

So maybe this is a bug in bluez (which owns that
/etc/bluetooth/main.conf), that it does not honor the setting (and
provides bad info to the applet as well)? But I don't see a component
bluez in bugzilla to report it ...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/45

------------------------------------------------------------------------
On 2010-06-30T08:43:40+00:00 jpazdziora wrote:

(In reply to comment #2)
> Funny thing: if I change in /etc/bluetooth/main.conf InitiallyPowered = true 
> to
> false, and reboot, the applet will show that white x in red on its icon, to 
> say
> that bluetooth is off. However, the bluetooth LED is still on, so in that case
> the applet shows incorrect information.

Another finding: even if the icon of the applet shows that bluetooth is
off, when I click it, the status is shown as On, and I have the option
to "Turn Off Bluetooth". When I turn if off, the LED goes off as well.
When I then turn in on again, the LED goes on, but the icon on the panel
still shows that red/white "off" sign.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/46

------------------------------------------------------------------------
On 2010-08-03T14:47:21+00:00 bnocera wrote:

(In reply to comment #1)
> The same problem on Fedora 13 with gnome-bluetooth-2.30.0-1.fc13.i686 on T61.
> Bastien, please, let us know if some other package might be causing this and
> you'd need more detailed version info, or if it is configurable somewhere.
> 
> I am pretty sure that on Fedora 11 my bluetooth was off after reboot (and I 
> had
> the option to turn it on with the applet on my panel). That's why I'd consider
> this a regression.    

Definitely not a regression, if anything, it's a kernel one. The ibm-
laptop (or whatever the kernel module is called for Thinkpads) module
changed behaviour.

(In reply to comment #2)
> Funny thing: if I change in /etc/bluetooth/main.conf InitiallyPowered = true 
> to
> false, and reboot, the applet will show that white x in red on its icon, to 
> say
> that bluetooth is off. However, the bluetooth LED is still on, so in that case
> the applet shows incorrect information.

Nope. Check the output of "hciconfig hci0", you'll see that the device
is enabled, just not powered. The hardware has no ways to know that...

> So maybe this is a bug in bluez (which owns that /etc/bluetooth/main.conf),
> that it does not honor the setting (and provides bad info to the applet as
> well)? But I don't see a component bluez in bugzilla to report it ...    

This is a BIOS bug. gnome-bluetooth doesn't hold *any* information as to
the state of Bluetooth, and bluetoothd (somewhat) remembers the state of
the device. The problem is that when it's hard-blocked, eg. disabled in
hardware, bluetoothd has no Bluetooth devices to remember the setting
of.

With a good BIOS, the BIOS should remember the previous state, and use
that.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/49

------------------------------------------------------------------------
On 2010-08-03T15:01:55+00:00 sassmann wrote:

Actually when I observe the bluetooth LED on the Thinkpad it is off during BIOS 
init and just turns on sometime while executing the initrd. So I guess some 
module in the initrd is actually activating bluetooth.
Maybe it's thinkpad_acpi but not sure.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/50

------------------------------------------------------------------------
On 2010-08-03T17:31:05+00:00 jpazdziora wrote:

(In reply to comment #4)
> > this a regression.    
> 
> Definitely not a regression, if anything, it's a kernel one. The ibm-laptop 
> (or
> whatever the kernel module is called for Thinkpads) module changed behaviour.

I am not qualified to pinpoint the component which caused the change in
behaviour -- I've just pointed out that something which used to work in
Fedora 11 now behaves in a less desirable way.

> With a good BIOS, the BIOS should remember the previous state, and use
that.

The BIOS hasn't been updated/changed since I used Fedora 11 on this
machine. So it has to be something between F11 and F13 (well, F12 and
F13, even though I am not 100 % sure what the behaviour on F12 was) that
changed in an undesirable way. And I'd like to find the cause and bring
back the pre-F13 behaviour.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/51

------------------------------------------------------------------------
On 2010-11-03T20:54:08+00:00 triage wrote:


This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/54

------------------------------------------------------------------------
On 2010-11-04T16:07:55+00:00 jpazdziora wrote:

Flipping version to Fedora 13.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/55

------------------------------------------------------------------------
On 2011-05-20T18:14:23+00:00 marbolangos wrote:

Same in F15!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/57

------------------------------------------------------------------------
On 2011-05-23T07:22:32+00:00 jpazdziora wrote:

Flipping the version to Fedora 15 so that this bug does not get
autoclosed.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/58

------------------------------------------------------------------------
On 2012-01-29T16:54:13+00:00 boris.nadezhdin wrote:

The same issue in F16 on Sony Vaio VPCEB3B4R

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/65

------------------------------------------------------------------------
On 2012-03-15T21:55:17+00:00 daniel wrote:

I'm also having the same issue on a Sony Vaio VPCSA3.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/67

------------------------------------------------------------------------
On 2012-03-25T16:47:54+00:00 dbraunwarth wrote:

Same here on 3.3.0-4.fc16.x86_64

But systemctl status bluetooth.service returns:

bluetooth.service - Bluetooth service
          Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled)
          Active: inactive (dead)
          CGroup: name=systemd:/system/bluetooth.service

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/68

------------------------------------------------------------------------
On 2012-08-07T19:28:07+00:00 bcotton wrote:

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/76

------------------------------------------------------------------------
On 2012-08-08T08:23:10+00:00 jpazdziora wrote:

Reopening as I feel the problem is still present in Fedora 17.

On the other hand, I am not completely sure that gnome-bluetooth is the
right component as I can see the same behaviour on XFCE desktop.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/77

------------------------------------------------------------------------
On 2012-08-12T00:38:21+00:00 jamilo wrote:

I am also having the same issue on Fedora 17 (64bit Gnome). I am
surprised this bug has been there for so long. Is this applicable to
only very specific systems?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/78

------------------------------------------------------------------------
On 2012-10-29T14:43:04+00:00 mattdm wrote:

Still the case in F18 beta.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/81

------------------------------------------------------------------------
On 2012-11-17T05:57:48+00:00 draeath wrote:

This happens for me on an eeepc 1000 (Fedora 17, XFCE).

For this device, the adapter is attached to the USB bus internally.

>From lsusb:
Bus 005 Device 002: ID 0b05:b700 ASUSTek Computer, Inc. Broadcom Bluetooth 2.1

I don't have a hardware indicator to tell me if it's actually on or not,
but regardless of whether I tell it to turn off or not, it's back up on
the next boot.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/84

------------------------------------------------------------------------
On 2013-01-19T17:21:14+00:00 tommy wrote:

I have same problem, after disable bluetooth using command

systemctl disable bluetooth.service

bluetooth still shown after restart. I've to kill blueman-applet every
time I boot my system.

I'm using Fedora 18 XFCE.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/85

------------------------------------------------------------------------
On 2013-02-10T11:42:54+00:00 grawert wrote:

I had the same issue on a Lenovo X1. The problem seems not to be gnome-
bluetooth or any bluetooth daemon. For Lenovo laptops there is the
thinkpad-acpi kernel module. That module is activating bluetooth. I did
the following:

# modprobe -r thinkpad_acpi
# modprobe -v thinkpad_acpi
insmod 
/lib/modules/3.7.6-201.fc18.x86_64/kernel/drivers/platform/x86/thinkpad_acpi.ko 
fan_control=1

Bluetooth is actived now! There is a module parameter bluetooth=0, but
it is not recognized as of thinkpad_acpi module version 0.24. The
documentation is also mentioning that many paramters are deprecated, and
rfkill shall be used. When examining with rfkill, the following blocked
states are set after module loading:

# rfkill list bluetooth
3: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: no
        Hard blocked: no
4: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

As soon as I turn on "soft blocking" for bluetooth, it gets disabled:

# rfkill block bluetooth
# rfkill list bluetooth
3: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: yes
        Hard blocked: no

Bluetooth is deactivated now.

I added "rfkill block bluetooth" to /etc/rc.d/rc.local. During boot the
bluetooth LED is active when the thinkpad_acpi module is loaded, but
turns off, as soon as rc-local.service unit has been reached.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/86

------------------------------------------------------------------------
On 2013-02-20T18:18:34+00:00 beland wrote:

*** Bug 911093 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/88

------------------------------------------------------------------------
On 2013-07-03T23:43:22+00:00 mwp.junk wrote:

I have two laptops running F18 and F19, complete installs, and both
exhibit the same issue. The F18 laptop is a Dell XPS 17 (LX720x) with a
3.9.6 kernel and the F19 is a Dell Latitude D830 with 3.9.8 kernel.

Interacting with the top-bar bluetooth applet doesn't have any affect on
the bluetooth led.

'sudo systemctl stop bluetooth.service' && 'sudo systemctl disable
bluetooth.service' won't turn it off either despite 'sudo systemctl
status bluetooth.service' saying it's dead (inactive) and the systemd
journal showing bluetoothhd was stopped.

'sudo chkconfig --list | grep bluetooth' doesn't show it running and
'chkconfig bluetooth off' just forwards to systemctl disable
bluetooth.service.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/96

------------------------------------------------------------------------
On 2013-07-31T15:39:39+00:00 hub+rhbz wrote:

You might want to refer to this upstream bug:

https://bugzilla.gnome.org/show_bug.cgi?id=638117

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/97

------------------------------------------------------------------------
On 2013-12-21T14:52:34+00:00 bcotton wrote:

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/98

------------------------------------------------------------------------
On 2013-12-22T08:15:40+00:00 jpazdziora wrote:

I currently have

#!/bin/bash
echo disable > /proc/acpi/ibm/bluetooth

in my /etc/rc.d/rc.local so I will no longer attempt to keep this
bugzilla open for proper resolution. Someone else who still cares might
want to pick up the flag.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/99

------------------------------------------------------------------------
On 2014-02-05T22:39:22+00:00 bcotton wrote:

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/100

------------------------------------------------------------------------
On 2014-05-28T20:23:53+00:00 jshubin wrote:

Still present on F20, and annoying hackers everywhere :)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/101

------------------------------------------------------------------------
On 2014-05-28T20:53:26+00:00 mskinner wrote:

I have a T530 - even though I have bluetooth disabled in the KDE
settings, the /proc/acpi/ibm/bluetooth had it enabled.

I am running the latest BIOS as well.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/102

------------------------------------------------------------------------
On 2014-05-28T20:54:09+00:00 mskinner wrote:

I have a T530 - even though I have bluetooth disabled in the KDE
settings, the /proc/acpi/ibm/bluetooth had it enabled.

I'm running F20.

I am running the latest BIOS as well.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/103

------------------------------------------------------------------------
On 2014-05-29T15:12:34+00:00 sbonazzo wrote:

Same here on F19 on T530.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/104

------------------------------------------------------------------------
On 2014-08-11T09:54:29+00:00 eminguez wrote:

Systemctl workaround:

echo "w /proc/acpi/ibm/bluetooth - - - - disable" >> /etc/tmpfiles.d
/disable-bluetooth.conf

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/106

------------------------------------------------------------------------
On 2014-08-13T10:46:01+00:00 bnocera wrote:

systemd is supposed to remember and restore rfkill status. If that
doesn't work, it could be a problem with systemd's implementation, or
with the kernel implementation of the device specific rfkill (the
thinkpad_acpi module is known to be problematic).

Punting to systemd.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/107

------------------------------------------------------------------------
On 2014-11-09T20:23:25+00:00 htl10 wrote:

(In reply to Bastien Nocera from comment #32)
> systemd is supposed to remember and restore rfkill status. If that doesn't
> work, it could be a problem with systemd's implementation, or with the
> kernel implementation of the device specific rfkill (the thinkpad_acpi
> module is known to be problematic).
> 
> Punting to systemd.

It is certainly not being remembered. FWIW, I have toshiba_bluetooth
module; and I keep having to turn it off at the user-settings; it seems
to be forgotten whenever reboot/logout.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/109

------------------------------------------------------------------------
On 2014-11-25T22:36:57+00:00 pspacek wrote:

I confirm the same issue on T540 running latest Fedora 21.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/110

------------------------------------------------------------------------
On 2015-01-15T03:38:59+00:00 wgqiwt wrote:

Same on lenovo w530 centos 6

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/113

------------------------------------------------------------------------
On 2015-01-17T08:40:53+00:00 jshubin wrote:

On Fedora 21.
Bluetooth is off.
Turn wifi switch off, then on.
Bluetooth turns itself on again!

Argghhh...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/114

------------------------------------------------------------------------
On 2015-05-07T19:54:41+00:00 beland wrote:

According to https://bugzilla.gnome.org/show_bug.cgi?id=638117 systemd
209 fixes this for at least some hardware.

I can confirm this fix on Fedora 21 with my Macbook Air running
systemd-216-24.fc21.x86_64; Bluetooth stays off after reboot if set that
way.  Also according to that external bug, there may be additional bugs
in the hardware-specific kernel bluetooth drivers.

It sounds like if we want this fixed, then, we should report new
hardware-specific bugs against the kernel.  On my MacBook, "lsmod | grep
rfkill" reports:


rfkill                 21980  5 cfg80211,bluetooth

I also have a Lenovo ThinkPad running Fedora 19, and it lists users of
rfkill as cfg80211,thinkpad_acpi,bluetooth.  For those that are running
Fedora 21 and seeing this problem still, what modules do you see there?

The upstream bug also mentions this as a manual workaround:

/etc/modprobe.d/rfkill.conf:

options rfkill master_switch_mode=0

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/115

------------------------------------------------------------------------
On 2015-06-25T22:55:15+00:00 ledufff wrote:

(In reply to James (purpleidea) from comment #36)
> On Fedora 21.
> Bluetooth is off.
> Turn wifi switch off, then on.
> Bluetooth turns itself on again!
> 
> Argghhh...

I can reply this too in Fedora 22 (Cinnamon)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/116

------------------------------------------------------------------------
On 2015-06-26T07:38:40+00:00 jpazdziora wrote:

Updating version based on comment 38.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/117

------------------------------------------------------------------------
On 2015-07-07T07:10:10+00:00 leigh123linux wrote:

*** Bug 1240476 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/118

------------------------------------------------------------------------
On 2015-10-22T08:02:47+00:00 jsynacek wrote:

*** Bug 1231423 has been marked as a duplicate of this bug. ***

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/119

------------------------------------------------------------------------
On 2015-12-02T16:57:42+00:00 josephpfidler wrote:

Just noticed this bug with Fedora 23 - Gnome 3.18.2.

Set Bluetooth to off in the Gnome Settings Bluetooth dialogue - reboot
and that setting is forgotten and Bluetooth is turned on again. Same is
true for the Bluetooth setting in the power settings dialog.

For me this creates an necessary power drain by having Bluetooth enabled
when its not needed, and more importantly a potential security problem.
Hardware is an Asus UX305LA laptop.

Cheers, Joe.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/120

------------------------------------------------------------------------
On 2016-03-12T21:18:59+00:00 mbrancaleoni wrote:

same on fedora 24, branched release (updated as now).

calling it an Enhancement is a bit.... meh, but well.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/121

------------------------------------------------------------------------
On 2016-03-13T01:38:24+00:00 josephpfidler wrote:

Yep - Not honoring a very noticeable user setting seems like a straight
forward bug to me. And its now six year old.

I am happy to test fixes for this if it helps...

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/122

------------------------------------------------------------------------
On 2016-03-17T20:00:01+00:00 mbrancaleoni wrote:

right now issue bypassed with tlp and by setting

DEVICES_TO_DISABLE_ON_STARTUP="bluetooth"

in /etc/default/tlp

not elegant, but 99.999% of time bluetooth is not really needed here.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/123

------------------------------------------------------------------------
On 2016-03-17T22:08:03+00:00 josephpfidler wrote:

Its more elegant the the "rfkill block bluetooth" command I currently have in a 
startup script.
Thanks Matteo for your help.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/124

------------------------------------------------------------------------
On 2016-03-29T12:02:55+00:00 jsynacek wrote:

On Fedora 24, I can't reproduce this anymore.

$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: no
        Hard blocked: no
2: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
3: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

After turning off bluetooth from the gnome menu:

$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: yes
        Hard blocked: no
2: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

After rebooting the machine, bluetooth is still soft blocked and appears
as Off in the menu and bluetooth settings.

$ rpm -q gnome-shell bluez kernel
gnome-shell-3.20.0-1.fc24.x86_64
bluez-5.37-3.fc24.x86_64
kernel-4.5.0-301.fc24.x86_64

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/125

------------------------------------------------------------------------
On 2016-03-31T17:22:31+00:00 josephpfidler wrote:

Just re-tested this bug against my current setup - Fedora 23 with
current updates. I do not see the issue as originally described - my
Blutooth is staying off after a power-off. I am still working to see if
I applied any of the work arounds, so that I can confirm if this is a
valid result. I do see the issue after a suspend-resume event, but do
know if that is relevant to this bug.

To re-create using suspend-resume I ...

1] Turn-off Blu-tooth using the Gnome menu (if its not already off).
rfkill list shows:

1: asus-wlan: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: asus-bluetooth: Bluetooth
        Soft blocked: yes
        Hard blocked: no
3: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no


2] suspend the machine - sudo systemctl suspend

3] Resume. Gnome indicator shows Blutooth enabled and I can see the
laptop's blutooth from other devices. Rfkill list still shows:

1: asus-wlan: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: asus-bluetooth: Bluetooth
        Soft blocked: yes
        Hard blocked: no
3: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
4: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no


rpm -q gnome-shell bluez kernel
gnome-shell-3.18.4-1.fc23.x86_64
bluez-5.36-1.fc23.x86_64
kernel-4.4.4-301.fc23.x86_64
kernel-4.4.5-300.fc23.x86_64
kernel-4.4.6-300.fc23.x86_64


So after the resume Blutooth has activated itself despite being configured not 
too. I noticed the second Blutooth device (hci0) that has appeared in the list 
and wonder if this is part the cause of the problem. I am out of the office 
next week - will try to load the F24 Alpha then and re-test against that.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/126

------------------------------------------------------------------------
On 2016-07-19T20:49:41+00:00 bcotton wrote:

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/128

------------------------------------------------------------------------
On 2016-07-20T14:18:54+00:00 bugzilla wrote:

Same for F23

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/129

------------------------------------------------------------------------
On 2016-11-24T10:26:35+00:00 bcotton wrote:

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/131

------------------------------------------------------------------------
On 2016-11-24T12:55:28+00:00 hub+rhbz wrote:

Good news.
I haven't seen the problem is F24 and F25. Possibly fixed upstream.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/132

------------------------------------------------------------------------
On 2016-11-27T11:08:19+00:00 woiling wrote:

I still experience this behaviour on Fedora 24.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/133

------------------------------------------------------------------------
On 2016-11-27T22:45:57+00:00 htl10 wrote:

Argh, in my rc.local, I had it blocked by default:

/etc/rc.d/rc.local

rfkill block bluetooth

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/134

------------------------------------------------------------------------
On 2017-02-10T19:36:11+00:00 woiling wrote:

It also still happens on Fedora 25 for me.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/135

------------------------------------------------------------------------
On 2017-02-10T20:31:18+00:00 josephpfidler wrote:

Yep its still there. Just retested under F25 with current updates.

Turn off Bluetooth in the Gnome settings panel. Either a suspend-resume
or power-off power-on will result in Bluetooth active.

I did see an error related to communication with my Bluetooth device
(hci0) but have no idea if this is related to this error:

sudo dmesg | grep hci0
[    3.692511] Bluetooth: hci0: read Intel version: 370810011003110e00
[    3.694466] Bluetooth: hci0: Intel Bluetooth firmware file: 
intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[    3.830043] Bluetooth: hci0 sending frame failed (-19)
[    5.865638] Bluetooth: hci0 command 0xfc8e tx timeout
[   14.313764] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed 
(-110)
[   14.313889] Bluetooth: hci0 sending frame failed (-19)
[   16.361767] Bluetooth: hci0 command 0xfc11 tx timeout
[   16.361772] Bluetooth: hci0: Exiting manufacturer mode failed (-110)
[   23.495554] Bluetooth: hci0: read Intel version: 370810011003110e00
[   23.495766] Bluetooth: hci0: Intel Bluetooth firmware file: 
intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[   23.804611] Bluetooth: hci0: Intel Bluetooth firmware patch completed and 
activated

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/136

------------------------------------------------------------------------
On 2020-04-12T07:14:02+00:00 devidd05 wrote:

I am experiencing the same thing again in Fedora 31 in Dell XPS 13 9350.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/446657/comments/138


** Bug watch added: bugzilla.gnome.org/ #638117
   https://bugzilla.gnome.org/show_bug.cgi?id=638117

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bluez in Ubuntu.
https://bugs.launchpad.net/bugs/446657

Title:
  Bluetooth's on/off status doesn't update from the SetProperty D-Bus
  method that bluetoothd sends

Status in GNOME Bluetooth:
  Unknown
Status in The Ubuntu Power Consumption Project:
  New
Status in bluez package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in bluez package in Fedora:
  Confirmed

Bug description:
  Binary package hint: gnome-bluetooth

  Gnome's bluetooth applet should get a bluetooth device's on/off status
  through dbus from SetProperty setting sent by bluetoothd. This
  information was given in
  http://permalink.gmane.org/gmane.linux.bluez.kernel/4302 There is a
  setting controlling this feature: RememberPowered=true in
  /etc/bluetooth/main.conf

  Questions:
  Is the dbus message is even sent? If it is sent, why gnome-bluetooth doesn't 
do anything for it? Does bluez's SetProperty actually find the last (if even 
saved) bluetooth status?

  ProblemType: Bug
  Architecture: i386
  Date: Thu Oct  8 20:54:15 2009
  DistroRelease: Ubuntu 9.10
  NonfreeKernelModules: wl
  Package: gnome-bluetooth 2.28.1-0ubuntu1
  ProcEnviron:
   PATH=(custom, user)
   LANG=es_ES.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 2.6.31-12.41-generic
  SourcePackage: gnome-bluetooth
  Uname: Linux 2.6.31-12-generic i686

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-bluetooth/+bug/446657/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to