Исправление intelfx, (текущая версия) :
Нет, ты не прав.
Действия systemd в этой связи ограничиваются лишь запоминанием состояний rfkill'ов при шатдауне и восстановлением их при следующем запуске. При этом известно, что BlueZ (вплоть до текущей версии, при том, что в дебиане очевидно не последняя) не умеет рулить связанным с адаптером rfkill'ом и всегда держит его включенным (а хотелось бы).
С первой проблемой (безусловное включение адаптера при старте системы) я тоже сталкивался. Насколько мне известно, в BlueZ 5 это никак не регулируется, а в BlueZ 4 смотри файл /etc/bluetooth/main.conf.
Ну а второе звучит как дистропроблема; в арче такого никогдав последние три года не было.
Исправление intelfx, :
Нет, ты не прав.
Действия systemd по управлению связью ограничиваются запоминанием состояний rfkill'ов при шатдауне и восстановлением их при следующем запуске. При этом известно, что BlueZ (вплоть до текущей версии, при том, что в дебиане очевидно не последняя) не умеет рулить связанным с адаптером rfkill'ом и всегда держит его включенным (а хотелось бы).
С первой проблемой (безусловное включение адаптера при старте системы) я тоже сталкивался. Насколько мне известно, в BlueZ 5 это никак не регулируется, а в BlueZ 4 смотри файл /etc/bluetooth/main.conf.
Ну а второе звучит как дистропроблема; в арче такого никогда не было.
Исходная версия intelfx, :
Нет, ты не прав.
Действия systemd по управлению связью ограничиваются запоминанием состояний rfkill'ов при шатдауне и восстановлением их при следующем запуске. При этом известно, что BlueZ (вплоть до текущей версии, при том, что в дебиане очевидно не последняя) не умеет рулить связанным с адаптером rfkill'ом и всегда держит его включенным (а хотелось бы).
С первой проблемой (безусловное включение адаптера при старте системы) я тоже сталкивался. Насколько мне известно, в BlueZ 5 это никак не регулируется, а в BlueZ 4 смотри файл /etc/bluetooth/main.conf.
Ну а второе звучит как дистропроблема.