| |
| |
| 2.6, llolik, 10:08, 01/02/2016 [^] [ответить] [смотреть все] [показать ветку]
| +33 +/– |
А что он сказал не так?
Если UEFI у некоторых производителей работает не так, как ему положено работать в спецификации (сбрасываться к заводским настройкам), а поступить по другому нельзя (будут проблемы с GRUB, например), то что прикажете делать?
|  | | |
| |
| |
| 4.17, фыв, 10:23, 01/02/2016 [^] [ответить] [смотреть все]
| +26 +/– |
Вы серьёзно?
Первичны стандарты.
Правильно будет устранять ПРИЧИНУ ошибки, а не обходить заботливо наставленные "производителями" грабли, являющиеся СЛЕДСТВИЕМ их наплевательского отношения к СТАНДАРТАМ.
|  | | |
| |
| 5.23, Аноним, 10:32, 01/02/2016 [^] [ответить] [смотреть все]
| +13 +/– | |
Охладись, юноша, и добро пожаловать в реальный мир.
>Правильно будет устранять ПРИЧИНУ ошибки
Правильно-то правильно, но как это реалистично сделать? Прежде чем отвечать, подумай не только о технических аспектах.
>наплевательского отношения к СТАНДАРТАМ
Максимализм. Возможно, имела место банальная человеческая ошибка. Все люди ошибаются. Не стоит так огульно обвинять разработчиков, толком не разобравшись в вопросе.
Аноним выше все правильно говорит, а поттер как всегда в своем репертуаре.
|  | | |
| |
| 6.43, Anonplus, 10:55, 01/02/2016 [^] [ответить] [смотреть все]
| +11 +/– |
Бедные системд-хейтеры оказались меж двух огней. Признать, что стандарты рулят = оправдать Поттеринга в этом случае. Признать, что на стандарты можно класть с прибором = лишиться аргумента "а вот этот ваш системд клал с прибором на стандарты".
|  | | |
|
|
| 4.32, Anonplus, 10:46, 01/02/2016 [^] [ответить] [смотреть все]
| +10 +/– | |
Теперь вспомним историю, когда установка линукса на определённые модели ноутбуков Самсунг приводила к их окирпичиванию (тоже затирались настройки NVRAM).
По такой логике тогда следует сказать "типичный Линус", "ядро, написанное рукожопами" и так далее?
Или всё же "у самсунга была кривая прошивка"?
|  | | |
| |
| |
| |
| 7.70, Аноним, 12:01, 01/02/2016 [^] [ответить] [смотреть все]
| +11 +/– |
Я это понял. Отличие между Линусом и Леней в том, что первый - инженер и подходит к таким вопросам как инженер, принимая патчи для обхода железных косяков, а второй - безответственный хипстер, скачущий на розовом единороге по радуге.
|  | | |
|
|
|
|
|
|
| |
| |
| 3.18, фыв, 10:24, 01/02/2016 [^] [ответить] [смотреть все]
| +10 +/– |
Надо пинать производителя. Иначе будет зоопарт таких косяков, с различными вкусами от разных производителей.
|  | | |
|
|
| 1.10, Nicknnn, 10:16, 01/02/2016 [ответить] [смотреть все]
| +/– |
Обычный вброс. Причем тут systemd к efivars являющейся частью ядра? Ну и что, что он это монтирует. Он ведь монтирует и всё остальное.
|  | | |
| 1.12, Аноним, 10:19, 01/02/2016 [ответить] [смотреть все]
| +22 +/– |
В комментариях к данной новости выясняется, что ненависть к поттерингу перевешивает даже косяки кривых uefi в ноутбуках msi.
|  | | |
| 1.38, lucentcode, 10:48, 01/02/2016 [ответить] [смотреть все]
| +4 +/– |
Лёнчик дело говорит - проблемы кривых разрабов MSI его волновать не должны. Пусть свои косяки они за собой сами поправляют. Тем более, что проблема похоже у них не связана с железом - это косяк самой прошивки UEFI.
|  | | |
| 1.81, arisu, 12:20, 01/02/2016 [ответить] [смотреть все]
| +3 +/– |
я не понял, сегодня же не первое апреля. а новость из разряда: «британские учёные выяснили, что если положить голову под гидравлический пресс и запустить, то можно умереть. поголовье британских учёных значительно уменьшилось.»
|  | | |
| 1.85, arisu, 12:23, 01/02/2016 [ответить] [смотреть все]
| +1 +/– |
p.s. в кои‐то веки портерингико ответили нормально. а то в попытках защитить идиота от самого себя дойдут до того, что и рут будет уже не рут, как в винде.
|  | | |
| 1.113, CodeRush, 13:16, 01/02/2016 [ответить] [смотреть все]
| +16 +/– |
Раз уж меня сюда позвали, выскажусь и по этой проблеме. Для начала, systemd тут вообще не при чем (т.е. дополнительно ненавидеть Поттеринга не нужно), и с ядром тут тоже все хорошо (решение Мэтью Гаррет - воркэраунд вокруг настоящей проблемы, и если MSI её не исправят, то применять его надо бы только на этом ноутбуке, а не мешать вообще всем удалять то, что им нужно).
Сама проблема звучит так: "удаление некоторых переменных NVRAM приводит к остановке выполнения фазы DXE на некоторых ноутбуках MSI". Это действительно проблема, причина - в недостатке тестирования этого сценария (вполне, кстати, легитимного, и выполняемого в 20 строк на С в любой UEFI-совместимой ОС), а недостаток этот - он от сокращения времени разработки прошивки и прочих "оптимизаций Time-To-Market".
На самом деле, проблема эта не специфична для MSI, и страдают ей подавляющее большинство реализаций от практически всех IBV, плюс сам производитель железа может добавить свои драйверы, которые зависают от того, что нужных им переменных не оказалось, и не протестировать этот момент.
Решение: конкретный баг у MSI - найти и исправить, тест на этот случай - добавить в следующие версии FWTS, BITS и LUV, довести до производителей его необходимость через UEFI Forum. Пока реализации все еще сломаны - пользоваться воркэраундом Гаррета.
Если вам интересно мое мнение, я тоже против доступа в NVRAM на запись из ОС, по нескольким причинам. Во-первых, те немногие вещи, для которых этот доступ нужен утилите efibootmgr, должны решаться самой прошивкой (добавление/удаление/поиск новых UEFI-загрузчиков, изменение порядка загрузки), как это делается у AMI в данный момент, настройку SecureBoot тоже можно выполнить из Setup или, в крайнем случае, из UEFI Shell. Во-вторых, в случае RO NVRAM я могу поставить RO и на его регион, защитив все содержимое SPI-чипа от записи на аппаратном (ладно, почти аппаратном) уровне, подробности рассказывал в своем докладе на ZeroNights 2015, (вот слайды, если интересно: github.com/NikolajSchlej/ZeroNights2015/blob/master/FixItYourself_Schlej.pdf)
Решать эту проблему тоже нужно не на уровне ядра определенной ОС, т.к. руту вы все равно ничего запретить не сможете, а вызвать SetVariable можно и без всяких псевдо-ФС, нужен только доступ к /dev/mem. Решать её надо либо эмуляцией NVRAM, либо изменением стандарта UEFI. К сожалению, первое воспринимается как костыль, нужный только фанатам безопасности, а второе - весьма непросто будет продавить, но я не перестаю надеяться именно на этот исход. За 10 лет правильно NVRAM на SPI-чипе так никто реализовать не смог - может быть, дело не в людях, а проблемы в консерватории?..
|  | | |
| 1.118, НяшМяш, 13:20, 01/02/2016 [ответить] [смотреть все]
| +3 +/– |
Я как-то почти навечно окирпичил материнку от Гигабайта (которые якобы лучше всех для хакинтоша). В efi shell случайно потёр записи в nvram. Материнка отказалась запускаться, даром что в ней две микросхемы биоса и всё такое. Шаманство с замыканием ног главной микросхемы биоса помогло запуститься с резервной и я сэкономил 150$. Хотя на тех же маках есть сочетание клавиш для сброса этой самой nvram - и комп после этого отлично выживает.На стандарты всем пофиг я понял тогда, когда начал патчи на dsdt накладывать - половина функций стабы, другая половина возвращает минимально возможные данные. Как с этим всем винда с линём работает - просто магия.
|  | | |
| |
| |
| Часть нити удалена модератором |
|
|
| 1.243, AlexAT, 22:18, 01/02/2016 [ответить] [смотреть все]
| +1 +/– |
Итого режим работы UEFI/BIOS в личной практике оказывался переключенным на BIOS на 99% серверов и пк/нб. Впрочем, желающие жевать кактусы могут жевать мсявное поделие дальше.
|  | | |
| 1.320, bOOster, 11:18, 02/02/2016 [ответить] [смотреть все]
| –1 +/– |
Чото боян, года 2-3 назад гнусмас уже имел проблемы индентичного характера. И как раз когда очищались системные разделы.
|  | | |
|
|