Офигительная формулировка "шелл вешает юзверя".
Наверно проблема все-таки в конкретном скрипте, добавленном в автозагрузку, а не в самом шелле. Так что, я все еще жду пруф.
"Wolfenberg" написал:
У меня даже на "кривой Ubuntu 14.04" команда rfkill не сбрасывается при
каждой перезагрузке.
Одна маленькая деталь. С ноутбуками HP такая проблема бывает. Мне доводилось даже пользоваться моделью, где без вендовой утилиты от hp вообще нельзя было включить/выключить wifi. Но наверно и в том случае по вашей версии виновата была бы Mageia.
Одна маленькая деталь. С ноутбуками HP такая проблема бывает. Мне доводилось даже пользоваться моделью, где без вендовой утилиты от hp вообще нельзя было включить/выключить wifi. Но наверно и в том случае по вашей версии виновата была бы Mageia.
Отнюдь. Вообще-то команда rfkill как раз позволяет включать/отключать/перключать как программно, так и аппаратно.
А чем вы там захотите рулить потом - ваше дело. Или утилита от HP управляет kernel-blacklist?
Можно о ней тогда более подробно? Заодно ликбез устроите :)
Отнюдь. Вообще-то команда rfkill как раз позволяет включать/отключать/перключать как программно, так и аппаратно.
Ага. То-то форумы пестрят постами, когда в венде вырубили физически адаптер, поставили GNU/Linux, например, Ubuntu, и не могут включить wifi-адаптер. И никакой rfkill не спасает. Решается для большинства перезагрузкой в венду, включением адаптера там. Уже потом после обратной перезагрузки в Ubuntu адаптер как и положено и включается, и выключается. Ну не верите - введите в Google "wifi rfkill unblock all". Заголовки "rfkill - rf kill unblock all DOES NOT WORK! - Ask Ubuntu", "Wifi is hard blocked rfkill unblock all doesn't work" и им подобные как бы намекают, что проблемы-то возникают.
"Wolfenberg" написал:
Можно о ней тогда более подробно?
Можно. Сайт HP открыт для новых посетителей. Поисковые системы тоже.
xxblx, *SCRATCH* почитал. Как правило, везде пишут, что дело не в утилите, а в том, что BIOS
запоминает последнее состояние модуля.
Но вот про зависание шелла в автозапуске ни слова.
xxblx, bw почитал. Как правило, везде пишут, что дело не в утилите, а в том, что BIOS
запоминает последнее состояние модуля.
Серьезно. Это уже не смешно.
"Wolfenberg" написал:
Вообще-то команда rfkill как раз позволяет включать/отключать/перключать как программно, так и аппаратно.
Сами же и подтвердили, что не всегда с ходу rfkill позволяет переключать.
"Wolfenberg" написал:
Но вот про зависание шелла в автозапуске ни слова.
Вы видели лог, или может у вас доступ к тому ноуту есть, чтобы утверждать "шелл завис"? Если у человека из-за конкретного скрипта возникла проблема. В чем виноват шелл?
Сами же и подтвердили, что не всегда с ходу rfkill позволяет переключать.
?
"xxblx" написал:
Вы видели лог, или может у вас доступ к тому ноуту есть, чтобы утверждать "шелл завис"? Если у человека из-за конкретного скрипта возникла проблема. В чем виноват шелл?
Завис не шелл, не комп, а скрипт в автозагрузке. И завис он по вине производителя ноута, который пилит свое поделие исключительно под проприетарщину. У меня в ноуте все интеловское, и все работает. На ноуте, естественно, Slackware64 14.1. Ждите скриншотов, вечером покажу :) Забрал его наконец, теперь скоро включусь в работу над переводом ABS.
если правильно добавлю утилита HP (Security Manager вроде так она у меня называлась) делает настройки на уровне биоса, даже чтобы сканером отпечатков забить в биос новые пальцы нужно ух сначала утилитой сбросить... и т.п., блокировака беспроводных устройств происходила и при установке ubuntu, openSUSE 17, было ровно то же самое почему и решил не дистрибутивы менять а просто разобраться с настройкой. Скрипт повесил рабочий стол т.е. не реагировали ярлыки на запуск, открыл таки alt+F2 konsole и под рутом убил этот скрипт, все дальше заработало...
я до сих пор считал что Линуксоводам не свойственно плеваться на дистрибутивы друг друга, с Микрософтом это актуальнее... *DONT_KNOW*
