URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 106549
[ Назад ]

Исходное сообщение
"Выполнение rm -rf / может привести к неработоспособности UEF..."

Отправлено opennews , 01-Фев-16 09:57 
Один из любознательных пользователей Arch Linux столкнулся (https://bbs.archlinux.org/viewtopic.php?id=207549) с непредвиденной проблемой, пытаясь провести эксперимент по выполнению "rm -rf --no-preserve-root /" на ноутбуке MSI GP60. Перед плановой переразбивкой диска пользователь решил понаблюдать как поведёт себя система в случае выполнения "rm -rf /", после чего ноутбук пришёл в неработоспособностое состояние и перестал подавать признаки жизни, даже не пытаясь вывести что-то на экран при включении.


Проблема оказалась (https://bbs.archlinux.org/viewtopic.php?id=208102) в монтировании псевдо-ФС efivarfs, предоставляющей доступ к переменным UEFI, в режиме не только чтения, но и записи. Таким образом, при выполнении "rm -rf /" удалялось и содержимое директории /sys/firmware/efi/efivars, что приводило к очистке и повреждению конфигурации EFI.


На запрос перейти к монтированию /sys/firmware/efi/efivars в режиме только на чтение разработчики systemd
ответили (https://github.com/systemd/systemd/issues/2402), что запись в данную директорию необходима и они не видят с этим проблемы, так как изменение efivars возможно только под пользователем root, который в случае неадекватных действий может с тем же успехом повредить содержимое /dev/sda или перемонтировать efivars на запись и нарушить содержимое конфигурации UEFI. Поэтому проблема в UEFI-прошивке, очистка конфигурации которой не должно приводить к блокированию работы устройства.
При желании пользователи и разработчики дистрибутивов могут самостоятельно перейти к работе efivars в режиме только на чтение, без изменения кода systemd, достаточно для efivars  указать в /etc/fstab флаг "ro".

URL: https://bbs.archlinux.org/viewtopic.php?id=208102
Новость: https://www.opennet.ru/opennews/art.shtml?num=43795


Содержание

Сообщения в этом обсуждении
"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 09:57 
типичный поттеринг

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено llolik , 01-Фев-16 10:08 
А что он сказал не так?
Если UEFI у некоторых производителей работает не так, как ему положено работать в спецификации (сбрасываться к заводским настройкам), а поступить по другому нельзя (будут проблемы с GRUB, например), то что прикажете делать?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:16 
Железо оно первично. Если в железе ошибка значит надо обходить эту ошибку. Если железо можно повредить из-за ошибки в железе, значит надо обходить эту ошибку. Очевидно же.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено фыв , 01-Фев-16 10:23 
Вы серьёзно?
Первичны стандарты.
Правильно будет устранять ПРИЧИНУ ошибки, а не обходить заботливо наставленные "производителями" грабли, являющиеся СЛЕДСТВИЕМ их наплевательского отношения к СТАНДАРТАМ.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:32 
Охладись, юноша, и добро пожаловать в реальный мир.

>Правильно будет устранять ПРИЧИНУ ошибки

Правильно-то правильно, но как это реалистично сделать? Прежде чем отвечать, подумай не только о технических аспектах.

>наплевательского отношения к СТАНДАРТАМ

Максимализм. Возможно, имела место банальная человеческая ошибка. Все люди ошибаются. Не стоит так огульно обвинять разработчиков, толком не разобравшись в вопросе.

Аноним выше все правильно говорит, а поттер как всегда в своем репертуаре.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Андрей , 01-Фев-16 11:48 
Я хоть и не являюсь пользователем systemd (честно погонял 2 месяца, но душа так и не приняла :) ), но считаю, что Поттеринг прав. Стандарты надо соблюдать...

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:07 
> Стандарты надо соблюдать...

Никто с этим не спорит. Но, увы, реальное положение вещей далеко не идеально. Можно, конечно, стоять рядом с Леней с транспарантом "Not our problem". С транспарантом и нерабочим железом, да.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Адекват , 01-Фев-16 15:04 
> Можно, конечно, стоять рядом с Леней с транспарантом

Лучше с шокером.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 22:56 
Шокер пригодится - когда ноутбук закирпичится, ты сможешь устроить наглядное шоу для MSI и Intel чего заслуживает их техника.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонанонанонанино , 01-Фев-16 13:14 
FHS тоже стпандарт, но на него поклали...

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:57 
Он странный довольно.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 22:40 
А uefi что, не странный?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Elhana , 01-Фев-16 13:32 
Да никто не спорит что надо соблюдать. И тот же Линус тоже бы материл производителя, но при это реакция у него почти наверняка была бы не gtfo, а какое-то решение как пользователя от этого оградить. А поттеринг на любую проблему отвечает что это не его проблемы.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено asd , 02-Фев-16 08:31 
Юноша ) Я - юноша )
Не надо ТЫКАТЬ незнакомым людям, во первых. Даже в интернете.
Спасибо, но я далеко уже не юноша, и именно поэтому считаю, что стандарты обязаны соблюдаться. Наелся уже в жизни, знаете ли.
Я вообще-то не о поттеринге, мне самому не очень нравится systemd. Но тут он в какой-то мере прав.
Производителей заставить сделать что-либо достаточно просто. На законодательном уровне, или же банально не покупая их продукцию. Другое дело, что лемминги всё равно будут покупать что им нравится, а не что сделано нормально.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 11:46 
> Производителей заставить сделать что-либо достаточно просто. На законодательном уровне, или же банально не покупая их продукцию.

Покупая продукцию Вы всегда знаете её "подводные камни"?

> Не надо ТЫКАТЬ незнакомым людям, во первых. Даже в интернете.
>> Другое дело, что лемминги ...
>> ... не о поттеринге ...

Одно другому не мешает, юноша?!


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 02-Фев-16 13:29 
> я далеко уже не юноша

а ума так и не прибавилось. впрочем, старым дуракам свойственно ходить туда, где они никому не нужны, и «учить молодых жить». всенепременно начиная с: «вы мне не тыкайте, молодой человек». даже там, где «ты» — изначальная традиция.

впрочем, я уже не удивляюсь. старые дураки уверены, что седины каким‐то образом добавляют им ума и уважения. ну отчего бы вам не организовать дом престарелых, и меряться сединами там?


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Дегенератор , 02-Фев-16 18:49 
Однозначно лайкаю!

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено torvn77 , 03-Фев-16 21:35 
>Правильно-то правильно, но как это реалистично сделать?

Сделать реестр совместимости оборудования с Linux таким, чтобы им захотелось пользоваться и виндузятникам.
подраспиарить его среди них, а потом как поместить туда запись материнки такие то производителя такого то имеют не коректную реализацию UEFI, которая приводит к программной порче ПК.
Ну и наслаждаться эффектом, особенно после того как кто нибудь напишет под этот дефект вирус.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено skybon , 01-Фев-16 10:34 
Чувак, можешь сколько угодно заниматься моногамией с бородатыми дядьками в комитетах, но мы живём в РЕАЛЬНОМ мире. Если в этом мире насрать на "стандарт", то этот "стандарт" - филькина грамота. А ПО пишется под ЖЕЛЕЗО, а не "как правильно". Так что с морализаторством - за дверь.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Anonplus , 01-Фев-16 10:55 
Бедные системд-хейтеры оказались меж двух огней. Признать, что стандарты рулят = оправдать Поттеринга в этом случае. Признать, что на стандарты можно класть с прибором = лишиться аргумента "а вот этот ваш системд клал с прибором на стандарты".

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:18 
сам то понял что сказал?
какие ещё системд-хейтеры? те кто твою любимую программу не любят что ли? а должны?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Адекват , 01-Фев-16 15:16 
> сам то понял что сказал?
> какие ещё системд-хейтеры? те кто твою любимую программу не любят что ли?
> а должны?

Это тот, который из тех, ну короче которым сказать нечего, но хочется, вот они и говорят.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:04 
> Признать, что стандарты рулят = оправдать Поттеринга в этом случае.

Эх, двоешники, ЦА таких вот популистов...

Самый дешёвый способ спрыгнуть с ответственности -- указать на регламент.  Особенно если его писал не ты.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено тоже Аноним , 01-Фев-16 13:40 
К истоку рек возвращаются вновь их воды...

> Are you saying that pulseaudio is entering on some weird loop if the
> returned value is not -EINVAL? That seems a bug at pulseaudio.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Паша , 01-Фев-16 19:23 
Что за странная логика? Если сделано как в стандарте и на это указали - то это спрыгнуть с ответственности, совсем уже? А потом будете ныть, что везде костыли и ходить на них не удобно.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 20:19 
> Что за странная логика? Если сделано как в стандарте

Видимо, подразумевали "не как в стандарте"?

> и на это указали - то это спрыгнуть с ответственности, совсем уже?

Невозможно написать стандарт, учитывающий все случаи для сколь-нибудь сложной системы.  Если кто не хочет знакомиться с понятием комбинаторного взрыва (или вообще комбинаторикой) -- ну можно почитать про доказательство программ для наиболее ответственных применений.

При этом одни спрыгивают с ответственности, не вникая в нюансы; другие -- экономя на тестировании (как вот в #113 было разъяснено); третьи -- пытаясь отмахнуться теорией от практики.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено asd , 02-Фев-16 08:33 
Михаил, несомненно. Стандарты постепенно должны дорабатываться, конечно же.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 00:55 
> Самый дешёвый способ спрыгнуть с ответственности -- указать на регламент.  Особенно если его писал не ты.

А вот ты здесь именно этим постоянно занимаешься. Правда, тут ещё и регламент, если и не на 100% твой, то, по крайней мере, полностью уютненько тебя устраивающий, да ещё и кнопки все под руками, как рычаги подавления любого инакомыслия. Свобода по шигорински. Да вы все такие "свободные", только вот до этих самых кнопок вас допусти. А что случится, если вас допустят до пулемёта? Подумать страшно. Кто не свободен - тот труп :) Кровавое месиво из несвободных.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 02-Фев-16 03:35 
>> Самый дешёвый способ спрыгнуть с ответственности -- указать на регламент.
> А вот ты здесь именно этим постоянно занимаешься.

Почти хорошая подковырка, только Вы не умеете (или не захотели?) влазить в тапки другого человека.

Ещё проще было бы _молча_ (как некоторые и требуют) удалять несоответствующее правилам.

А моя ответственность -- в том, чтоб человек понял, "за что".  Потому что сам бы хотел, если уж угробили комментарий, который полчаса думал и писал -- то чтоб хоть сказали.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено владц , 01-Фев-16 22:42 
Никакой веской причины держать  efivarfs по умолчанию в rw нет, безотносительно того, в порядке ли прошивка


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 06:56 
Невозможность установки загрузчика. Невозможность управления загрузчиком. Все это без внятных сообщений почему и что с этим делать.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Andrey Mitrofanov , 02-Фев-16 11:28 
> Невозможность установки загрузчика. Невозможность управления загрузчиком. Все это без
> внятных сообщений почему и что с этим делать.

Это не причина для RW, это причина выкинуть из ядра и "вернуть к чертёжной доске". Впрочем, да, Линус будет типа против.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Khariton , 01-Фев-16 11:04 
Так проблема не в железе, а в софте к нему...)))

Или вы считаете что если производитель напишет свое толкование ацпи-запросов но для одной ОС в своих драйверах он их правильно растолкует, то если данные ацпи-запросы не верно обрабатываются в другой ОС, то виновата другая ОС?
)))


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Андрей , 01-Фев-16 11:49 
> Так проблема не в железе, а в софте к нему...)))
> Или вы считаете что если производитель напишет свое толкование ацпи-запросов но для
> одной ОС в своих драйверах он их правильно растолкует, то если
> данные ацпи-запросы не верно обрабатываются в другой ОС, то виновата другая
> ОС?
> )))

Асер вроде пару лет назад отхватил уже за кривые ACPI таблицы для linux'а?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Khariton , 01-Фев-16 13:43 
>> Так проблема не в железе, а в софте к нему...)))
>> Или вы считаете что если производитель напишет свое толкование ацпи-запросов но для
>> одной ОС в своих драйверах он их правильно растолкует, то если
>> данные ацпи-запросы не верно обрабатываются в другой ОС, то виновата другая
>> ОС?
>> )))
> Асер вроде пару лет назад отхватил уже за кривые ACPI таблицы для
> linux'а?

Да?
От спасибо! Порадовали...
Я в свое время задолбался изобретать патчи к новым ядрам на имея один рабочий патч для старого ядра...
Продал машинку в итоге. А там где отдал никто ядро менять не то что не будет, он даже не догадывается что оно есть, но Кубунту юзает на ура уже какой год...)))


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Нимано , 01-Фев-16 16:05 
> заботливо наставленные "производителями" грабли, являющиеся СЛЕДСТВИЕМ их наплевательского отношения к СТАНДАРТАМ

Дык, традиция же! Достаточно глянуть в загрузчики MBR или сразу в Ralf Brown's Interrupt List –  легаси костыль на костыле и костылем погоняет.
В том же GRUBе (причем, это только "начальные" 448 байт загрузчика):

http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/boo...
>  *  Determine the hard disk geometry from the BIOS!
> *  We do this first, so that LS-120 IDE floppies work correctly.

http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/boo...
> * This is a workaround for buggy BIOSes which don't pass boot
> * drive correctly.

Ну или классика:
http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/boo...


/*
     * ljmp to the next instruction because some bogus BIOSes
     * jump to 07C0:0000 instead of 0000:7C00.
ljmp    $0, $real_start

Те машинки наверное только где-то в музеях и остались, но дело^W код, с костялями специально под них – жив!

Так что нужно продолжать славное дело костыляния на стороне разработчиков низкоуровневого софта!
А то куда это годится – при написании софта не учитывать пару-тройку дюжин возможных граблей, на которые производители привычно забили (ну а че не забить, если все равно "исправят" костылянием?)


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено asd , 02-Фев-16 08:34 
Вот именно это я и имел в виду.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:34 
А это и не ошибка в железе.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено asd , 02-Фев-16 08:35 
Я уже писал выше. С моей точки зрения, тут неважно, в железе или в софте ошибка. Важно, что это ошибка производителя.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено commiethebeastie , 01-Фев-16 10:35 
>Железо оно первично.

Венда не запускается на произвольно взятом мипсе => венда лайно!


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Anonplus , 01-Фев-16 10:46 
Теперь вспомним историю, когда установка линукса на определённые модели ноутбуков Самсунг приводила к их окирпичиванию (тоже затирались настройки NVRAM).

По такой логике тогда следует сказать "типичный Линус", "ядро, написанное рукожопами" и так далее?

Или всё же "у самсунга была кривая прошивка"?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:15 
Нет.
Типичный Линус живет в реальном мире, в отличие от. В этом суть проблемы.

http://www.h-online.com/open/news/item/Protection-against-Sa...


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:33 
Анон в предыдущем комментарии говорит о проблеме, когда в нврам складывались крашдампы, что разрешено спеками, но самсунговские ноутбуки умирали от этого.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:01 
Я это понял. Отличие между Линусом и Леней в том, что первый - инженер и подходит к таким вопросам как инженер, принимая патчи для обхода железных косяков, а второй - безответственный хипстер, скачущий на розовом единороге по радуге.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:06 
> Или всё же "у самсунга была кривая прошивка"?

В ядре, глупенький, ошибку прошивки объехали со второго или третьего раза.

> написанное рукожопами

И да, не пишите сюда не тем, чем положено.  Научитесь сперва читать и понимать прочитанное.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Anonplus , 01-Фев-16 11:02 
> Железо оно первично. Если в железе ошибка значит надо обходить эту ошибку.
> Если железо можно повредить из-за ошибки в железе, значит надо обходить
> эту ошибку. Очевидно же.

Ошибку прошивки нужно фиксить в прошивке, а не заставлять юзера гадать, в каком дистре оно пофикшено, а в каком нет


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:21 
и как ты будешь это фиксить? не только в будущих релизах но и в прошлых.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено SysA , 01-Фев-16 14:44 
> и как ты будешь это фиксить? не только в будущих релизах но
> и в прошлых.

Открой для себя "firmware update"!


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено . , 01-Фев-16 20:08 
А то что это только юзер может сделать, причём для него это "black fu***ng magic!" говоря по олбански, - это тебя совсем не смущает?

И что - не работать на таких системах ... а ну да, мы же Ылита :)


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено llolik , 01-Фев-16 12:02 
> Железо оно первично. Если в железе ошибка значит надо обходить эту ошибку.

Только это не проблема systemd и инита в принципе. Что с этим Лёня должен сделать?
Собственно, Мэттью Гаррет уже всказался, что проблему нужно решать на уровне ядра
Пруф в его Твиттере, https://twitter.com/mjg59/status/693494314941288448



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Ан2 , 01-Фев-16 14:58 
>> Железо оно первично. Если в железе ошибка значит надо обходить эту ошибку.
> Только это не проблема systemd и инита в принципе. Что с этим
> Лёня должен сделать?
> Собственно, Мэттью Гаррет уже всказался, что проблему нужно решать на уровне ядра
> Пруф в его Твиттере, https://twitter.com/mjg59/status/693494314941288448

то есть свалить всё на Линуса ))


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено llolik , 01-Фев-16 15:03 
> то есть свалить всё на Линуса ))

Да он, вроде как, уже сам hotfix сделал.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 18:15 
учить конфигуратор grub перемонтировать с ro на rw и обратно.
Если в gnu/linux простая, случайно запущенная команда способна убить железо, то это проблема gnu/linux.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 18:19 
> учить конфигуратор grub перемонтировать с ro на rw и обратно.

Это не grub, хотя можно и там.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено demimurych , 01-Фев-16 18:32 
Угу. Если самолет падает потому что инженеры допустили ошибку в разработке самолета, то это конечно проблема пилота.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 07:04 
Это проблема пилота, потому что инженеры на земле, а пилот упадёт вместе с самолётом.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено asd , 02-Фев-16 08:36 
Конечно. А вот драть как сидоровых коз надо (и будут) инженеров.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено antares0 , 04-Фев-16 21:52 
> Угу. Если самолет падает потому что инженеры допустили ошибку в разработке самолета,
> то это конечно проблема пилота.

Именно. Ты не поверишь, но для каждой серии есть гайд с списком того чего пилоту лучше не делать. Самолет он сильно дороже китайбука имени MCI и его просто так не заменишь.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Andrey Mitrofanov , 01-Фев-16 23:07 
> учить конфигуратор grub перемонтировать с ro на rw и обратно.
> Если в gnu/linux простая, случайно запущенная команда способна убить железо, то это
> проблема gnu/linux.

Пральнаящитаю, надо rm -rf / научить наконец перемонтировать в RO то, что потеринг оставил в RW.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 07:07 
Недалекие ненависники не понимают что проблема не зависит от системы инициализации.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 02:22 
А потом эти же люди булькают, что во фре при извлечении флешки без отмонтирования паника.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено AlexYeCU_not_logged , 01-Фев-16 10:10 
Впервые в жизни заступаюсь для Поттеринга: типичный uefi.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:46 
два чая Вам - на той же модели ноутбука, даже в легаси, граб работает только если установлен в отдельный ext2 раздел

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Andrey Mitrofanov , 01-Фев-16 23:09 
> Впервые в жизни заступаюсь для Поттеринга: типичный uefi.

А ведь мудрые люди пердкперждали: майкрософт, фат16... не к добру. Ну, да они не дожили.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:01 
> типичный поттеринг

Да в этой новости всё прекрасно...


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонимус , 02-Фев-16 07:35 
Все правильно анон выше говорил. Виноват разраб железа кладущий на стандарты, и пользователи которые теоретически умеют в доступ к uefi теперь задумаются насчет покупки msi. Репутация производителя, хоть и у 1% будет потеряна а остальных не особо интересует что там с конфигами загрузчика.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено asd , 02-Фев-16 08:38 
В мой блэклист уже давно входят как MSI с ACER, так и SAMSUNG, SONY и ряд других. Просто принципиально не покупаю.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено asd , 02-Фев-16 08:40 
Имею в виду - не только сам не покупаю, но и других предостерегаю. В том числе клиентов - а там уже не один-два предмета покупается )). Ибо нефиг.
ЗЫ. Если бы таких как я было бы существенная чифра, производители сильно по другому относились бы как к стандартам, так и к клиентам-покупателям. Мечты...

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено iPony , 02-Фев-16 10:55 
В том то и бида, что белый состоит около из одного элемента 🍎

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонимус , 03-Фев-16 14:36 
У меня там асусы.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено asd , 07-Фев-16 08:15 
Кстати, да, с ними засад меньше.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено anon7894 , 02-Фев-16 12:41 
<cap mode> Выполнение rm -rf / может привести к неработоспособности Linux </cap mode>



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:02 
а ведь разработчики systemd всё верно ответили

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:07 
Да нет. Люди-то работают с тем что есть. Если в UEFI ошибка надо работать с оглядкой на эту ошибку, а не говорить что это не моё дело.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено фыв , 01-Фев-16 10:24 
Надо пинать производителя. Иначе будет зоопарт таких косяков, с различными вкусами от разных производителей.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:42 
Много ты по пинал производителя по поводу кривых ACPI?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Иван , 16-Янв-18 20:48 
> Много ты по пинал производителя по поводу кривых ACPI?

Я асуса пнул, он меня послал в издевательской форме. Больше его не покупаю.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:47 
надо допиливать коребут, ибо пинать производителя бесполезно - невидия тому пример

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Crazy Alex , 01-Фев-16 12:13 
Пинать - надо. Обходить баг - тоже надо.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:08 
> Надо пинать производителя.

Надо.

> Иначе будет зоопарт таких косяков

Белого кролика ещё не нашли? :)


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 18:19 
надо пинать производителя, но... Очень сложно будет заставить его выпустить обновление для всех устройств с этой ошибкой. Даже если обновления будут выпущены, уже выпущенным устройствам это поможет слабо, ведь надо в ручную провести потенциально деструктивную операцию, сложную... А еще надо просто суметь узнать что эту операцию нужно провести

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:29 
Завтра будет ошибка в 0.001% прошивок от [brand] в которой при выполнении некоторой последовательности операций процессора будет происходить зависание системы, на это тоже надо будет закладываться?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:38 
> Завтра будет ошибка в 0.001% прошивок от [brand] в которой при выполнении
> некоторой последовательности операций процессора будет происходить зависание системы,
> на это тоже надо будет закладываться?

А ты как думал!

https://en.wikipedia.org/wiki/Pentium_F00F_bug


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:01 
Слишком старое, есть посвежее фейлы и более трудноуловимые:
http://www.computerra.ru/138414/intel-skylake-cpu-bugs/


Проблема железок должна решаться производителем железки.

Так как и под Виндой или MacOS, или любой другой ОС могут точно также обнулиться параметры UEFI в результате вредоносной активности, с последующим окирпичиванием.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Khariton , 01-Фев-16 11:09 
> Да нет. Люди-то работают с тем что есть. Если в UEFI ошибка
> надо работать с оглядкой на эту ошибку, а не говорить что
> это не моё дело.

конечно!
потом когда производитель починит ошибку, а вы уже к ней приспособились, а ваше ПО приспособилось к ней и использует ее как фичу, то после фикса оной проблемы от производителя как вы будете чинить ваше ПО? Как будете объяснять проблему? Как будете поддерживать и ту и ту ветки?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:24 
не думаю что запрет перезаписи переменных UEFI можно использовать как фичу

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Khariton , 01-Фев-16 13:46 
> не думаю что запрет перезаписи переменных UEFI можно использовать как фичу

Ну возможность есть? Ок. Может и сгодится.

Например МС не могла предвидеть, что ограничение используемых символов в имени файла может привести к тому, что они не смогут использовать в ФС юникод. Мало того они предоставили это как фичу еще со времен ДОС! Мол пользоватлею так будет проще и удобнее!
А в юниксах такого ограничения нет.)))


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Адекват , 02-Фев-16 07:23 
> Например МС не могла предвидеть, что ограничение используемых символов в имени файла
> может привести к тому, что они не смогут использовать в ФС
> юникод. Мало того они предоставили это как фичу еще со времен
> ДОС! Мол пользоватлею так будет проще и удобнее!
> А в юниксах такого ограничения нет.)))

И сколько человек перешли на линукс с винды по этой причине ? и не вернулись потом обратно ?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Khariton , 02-Фев-16 10:22 
> И сколько человек перешли на линукс с винды по этой причине ?
> и не вернулись потом обратно ?

А сколько раз вас послали бабочек ловить за смену топика в ленте?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:39 
В любом ПО есть workaroud, как это есть с чипсетами nVidia, Radeon r6xx/r7xx. Например работа USB контроллеров

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:35 
Вот зачем ты об этом сказал? Аноны теперь спать не смогут, пока не добьются от Линукса и Ко исключения из кода ядра _всех_ воркэраундов. Ведь ошибки в железе это не проблема гну/линукса!

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:10 
> потом когда производитель починит ошибку, а вы уже к ней приспособились,
> а ваше ПО приспособилось к ней и использует ее как фичу

Это не то же, что объезд (ближе к последующему bug compatibility).


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Иван , 16-Янв-18 20:56 
> потом когда производитель починит ошибку, а вы уже к ней приспособились, а
> ваше ПО приспособилось к ней и использует ее как фичу, то
> после фикса оной проблемы от производителя как вы будете чинить ваше
> ПО? Как будете объяснять проблему? Как будете поддерживать и ту и

Предлагаю не приспосабливать к ошибкам основные ветки, а создавать патчи/драйверы, которые надо будет подгружать только на проблемных системах. А после починки просто перестать подгружать. Т. о. и код основной ветки замусориваться не будет ипользователи будут помнить, кому из производителей они обязаны необходимостью донастраивать систему на использование багфиксов.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено EuPhobos , 01-Фев-16 21:51 
Ну тогда уж до кучи давайте обвиним и mount, то что монтирует впринципе эту ФС, ну и за одно и rm обвиним, что нет ключа "rm -rf --but-not-my-uefi --pleeeease /"

Я сам не сторонник systemd, но бляха-муха, причём тут вообще systemd я никак не пойму? Как его сюда приписали в этой теме, проблема то вообще systemd никак не касается.
И главное комментаторы все такие "моя тему не читать, моя гневный коммент писать".


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 22:24 
> Я сам не сторонник systemd, но бляха-муха, причём тут вообще systemd я
> никак не пойму? Как его сюда приписали в этой теме, проблема
> то вообще systemd никак не касается.

Касается, именно systemd монтирует efivarfs в /sys с доступом на запись. То что в ядро предлагают добавить для защиты - грязный хак. Точно так же проблему можно обойти монтированием efivarfs в ro для проблемных прошивок на уровне systemd.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 07:12 
Upstart как монтирует? Openrc? Init.d?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 08:13 
Upstart и init.d в rw.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 13-Фев-21 16:37 
Может тогда лучше пнуть Поттеринга не за то, что он захардкожил rw в systemd, а за то, что он изобрел велосипед вместо использования fstab?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:05 
Как всегда - никто не при делах, и как хотите так сами и справляйтесь. И не важно, заплатил ты за это деньги (ноутбук MSI), или это открытый код (systemd).

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонимус , 02-Фев-16 07:37 
Виноват msi, не благодари.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Nicknnn , 01-Фев-16 10:16 
Обычный вброс. Причем тут systemd к efivars являющейся частью ядра? Ну и что, что он это монтирует. Он ведь монтирует и всё остальное.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:11 
> Причем тут systemd

Это ж арчик, там не спрашивали.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Альт , 01-Фев-16 14:55 
Ну понятно, что не альт.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 01:17 
> Ну понятно, что не альт.

Будто в Демьяне людей с ул.. пользователей о чём-то спрашивали. Так, погрызлись между собой и порешили. А Альт что, не осиливает ещё systemd? Я просто не в курсе.
Не знаю, Килин, Ред Стар на системдэ? Если да, то альтовцам тоже нужно подтягиваться. А то как технологиями будут делиться?



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено asd , 02-Фев-16 08:56 
В альте, да будет вам известно, нет такой проблемы - монжо и системд поставить, некоторые дистрибутивы с ним и идут по умончанию. Если не знаете - не надо сотрясать воздух, лады?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:18 
Вот почему никогда не будет никакого системдэ ни на одном компьютере под моим управлением.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 18:21 
Та же проблема будет в init.d и в upstart. Но такому как ты это не понять.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 18:25 
> Та же проблема будет в init.d

В где?

> Но такому как ты это не понять.

Вам слово fstab если б что-то говорило, то не умничали бы.

Виденные мной sysvinit-овые скрипты не самодеятельничают и не монтируют того, чего не было велено.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 20:45 
Я решил проверить, что там у труюниксвэй и не самодеятельной системы инициализации с монтированием sysfs и установил slackware. А там тоже rw.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 21:05 
И в alt linux rw.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Andrey Mitrofanov , 01-Фев-16 23:14 
> Я решил проверить, что там у труюниксвэй и не самодеятельной системы инициализации
> с монтированием sysfs и установил slackware. А там тоже rw.

Недопроверил, бракодел!

# rm -rf /sys <ENTER>


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 08:16 
Содержимое efivars можно удалить.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Адекват , 02-Фев-16 07:28 
> Вот почему никогда не будет никакого системдэ ни на одном компьютере под
> моим управлением.

Куда вы нахрен денетесь, когда все ментейнеры в едином порыве оставят ТОЛЬКО systemd ? :))
Собственно рано или поздно все будет работать ТОЛЬКО через systemd и pulseaudio.


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 02-Фев-16 13:25 
> все ментейнеры

лжёшь, свинья паршивая — как и обычно.


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Адекват , 02-Фев-16 15:21 
>> все ментейнеры
> лжёшь, свинья паршивая — как и обычно.

Мусье может видеть будущее ?


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 02-Фев-16 15:41 
да.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Аноним , 05-Фев-16 21:36 
арису мэйнтэйнит libastral у линуса.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:19 
В комментариях к данной новости выясняется, что ненависть к поттерингу перевешивает даже косяки кривых uefi в ноутбуках msi.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:47 
В опенврт загрузчик по умолчанию открыт на запись и можно окирпичить устройство. Правда поттеринг не умеет отношения к опенврт.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:51 
>поттеринг не имеет отношения к опенврт

бритва Мицгола


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 05-Фев-16 21:37 
саечка чингисхана.
апперкот жаботинского.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено ryoken , 01-Фев-16 12:07 
> Правда поттеринг не умеет отношения к опенврт.

За что ему лично я ему горячо благодарен.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:12 
Если бы поттеринг имел отношение к опенврт, то возможно в опенврт было бы поменьше гвоздей и костылей.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:26 
>гвоздей и костылей

зато работает


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:37 
Очевидно, что ты со мной не согласишься, но системд тоже превосходно работает. Так работает, как скриптовым костылям не снилось. Правда это сложно доказать пользователям десктопов и админам локалхоста.
Опенвртшная магия это то, что осложняет её использование в продакшне.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:12 
> Так работает, как скриптовым костылям не снилось. Правда это сложно доказать
> пользователям десктопов и админам локалхоста.

Я как автор термина "админ локалхоста" лишаю Вас лицензии на применение этого словосочетания. :]
</доля шютки>


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:39 
Не опенсорсно как-то.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено ZloySergant , 01-Фев-16 15:23 
>Не опенсорсно как-то.

Так ведь это и не код.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 18:33 
Так опенсорс это метод мышления.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Andrey Mitrofanov , 01-Фев-16 23:16 
> Так опенсорс это метод мышления.

Это када своих мыслей -- 0.0 ?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Адекват , 02-Фев-16 07:47 
> Очевидно, что ты со мной не согласишься, но системд тоже превосходно работает.
> Так работает, как скриптовым костылям не снилось. Правда это сложно доказать
> пользователям десктопов и админам локалхоста.

Ну ты попробуй, давай докажи преимущества systemctl + netctl над /etc/rc.conf, особенно необходимость именовать интерфейсы не eth0, eth1 а enp0s25 например.
Вот у меня на сервере был глюк, после того как я добавил строчку:
SkipNoCarrier=yes
У меня перестал подниматься подниматься интерфейс enp0s25 (прости господи) и назначаться ему адрес.
при этом, если сделать в консоле netctl start enp0s25 - интерфейс таки стартует.

Я просто приведу строчки, необходимые для настройки в bsd-like init в rc.conf:


HOSTNAME="old_srv"

# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
#
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
#   - prefix an entry in INTERFACES with a ! to disable it
#   - no hyphens in your interface names - Bash doesn't like it
#
# DHCP:     Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#

#Static IP example
#eth1="dhcp"
eth0="eth0 192.168.4.7 netmask 255.255.255.0 broadcast 192.168.4.255"
eth1="eth1 xxx.xxx.xxx.xxx  netmask 255.255.255.128"

боже мой, какой ужас - как мы жили со всем этим, да ?
То ли дело сейчас - такое раздолье, имя хоста в одном файле, настройки интерфейса в другом, плюс чтобы не было скучно - все может поменяться через год-полтора, имя хоста будет совершенно в другом файле. а на смену netctl придет systemd.netcfg.


а как демоны запускались, это просто гадость какая-то:
# -----------------------------------------------------------------------
# DAEMONS
# -----------------------------------------------------------------------
#
# Daemons to start at boot-up (in this order)
#   - prefix a daemon with a ! to disable it
#   - prefix a daemon with a @ to start it up in the background
#

DAEMONS=(syslog-ng @network netfs crond sshd samba @exim @ntpdate @ntpd @apcupsd  @iptables @ddclient @tuntap @openvpn !mot_up  httpd)

Боже мой, какая мерзость - всего одна строчка в одном файле, АААААА какже мы жили с этим !!!
Вы не представляете какой это был ужас - вот например в списке есть демон mot_up - вы представляете, он был всего из одной строчки - там через LD_PRELOAD запускался motoin с нужным конфигом.
То ли дело сейчас - православные Ln -s в каталог /etc/systemd не помню куда, но через "find /etc/systemd" можно же найти, да ?



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено derfenix , 02-Фев-16 17:01 
Перевожу:

"А-а-а! Какой ужас!! Я только с одним инитом разобрался и научился не ломать ничего, так тут ещё какой-то systemd появился, да ещё и настраивать надо иначе! Это уж я точно не осилю и не разберусь, умственные ресурсы и так уже выработаны под ноль!"


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 18:49 
Кусок Божественного rc.conf из старого Арча детектеД!

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:15 
Нет. Закрыт. А чтобы был открыт, нужно специально патчить.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 20:24 
На разных устройствах по разному на самом деле.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 01:29 
> В комментариях к данной новости выясняется, что ненависть к поттерингу перевешивает даже
> косяки кривых uefi в ноутбуках msi.

Так ведь вас 85% или 83% по новым подсчётам Левада-центра, вроде? К тому же, кругом враги. Вон в Германии 19-летний педофил изнасиловал 17-летнего русского ребёнка-девочку.. Поттеринг вообще там должен теперь тихо себе сидеть. Иначе придут ночью к нему придут Хрюша и Степашка (из тех 85%) и устроят ему такой init!



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:21 
Из серии "Хакер в столовой".

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 18:25 
случайно ошибся в наборе команд и получил кирпич вместо ноутбука. Обычная ситуация. Каждый кто хоть изредка удаляет каталог с помощью rm может в ней оказаться.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено derfenix , 02-Фев-16 17:02 
> случайно ошибся в наборе команд и получил кирпич вместо ноутбука. Обычная ситуация.
> Каждый кто хоть изредка удаляет каталог с помощью rm может в
> ней оказаться.

И часто ты случайно набираешь --no-preserve-root, пытаясь что-то удалить?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 03-Фев-16 07:53 
Пытаешься прикинуться шлангом? rm ~/tmp /* отлично работает без всяких

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено anonimous , 01-Фев-16 10:21 
Так это, ноутбук-то в он итоге как-то смог восстановить?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Anonplus , 01-Фев-16 10:48 
> Так это, ноутбук-то в он итоге как-то смог восстановить?

Перепрошивать микросхему надо. Программатором. Выпаивать, если не вынимается, и перепрошивать. В принципе, необратимо не угробил, но и тривиальным восстановление назвать нельзя.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонимус вульгарис , 01-Фев-16 16:21 
> Перепрошивать микросхему надо. Программатором. Выпаивать, если не вынимается, и перепрошивать.
> В принципе, необратимо не угробил, но и тривиальным восстановление назвать нельзя.

Ну выпаивать, положим, не придётся, MSI специальный разъём для этой цели выводит. Ибо очень уж часто у них такое случается.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:48 
писал с брата

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено anonymous , 01-Фев-16 11:02 
отправил на ремонт по гарантии https://bbs.archlinux.org/viewtopic.php?pid=1599733#p1599733

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 12:25 
> Так это, ноутбук-то в он итоге как-то смог восстановить?

зачем ему ноутбук, он же дебил.


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Аноним , 01-Фев-16 18:26 
почему?

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Аноним , 01-Фев-16 19:27 
Тупой вопрос, ну ладно отвечу. Инструкцию ниасилил от бука где сказано как восстанавливать и прошивать UEFI.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Анонистый калий , 01-Фев-16 19:31 
Потому что нефиг было что-либо ломать.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Адекват , 02-Фев-16 07:58 
> Так это, ноутбук-то в он итоге как-то смог восстановить?

Предлагаю законодательно разрешить магазинам отказывать в гарантии, если на ноут был поставлен линукс.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:22 
Ваш компьютер в безопасности, когда не работает. Профессиональная защита компьютеров от включения. Звоните!

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Maks , 01-Фев-16 10:22 
А что,на системе без systemd эта операция невозможна?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:32 
Возможна.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено КО , 01-Фев-16 10:38 
Ну, наверное, не на системД можно указать как монтировать ту или иную систему. А системД монтирует некоторые на свой вкус.

Другой вопрос - что это за системные утилиты, которые требуют кровь из носу доступ на запись в переменные UEFI, без которых загрузиться будет нельзя?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:43 
>А системД монтирует некоторые на свой вкус.

Системд монтирует efivarfs, так как указано в fstab.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Другой аноним , 01-Фев-16 11:08 
Не совсем верно. Запись в fstab необязательная. Modprobe efivars при условии загрузки в режиме uefi - и мы имеем подпор типов Анны раздел в sysfs. А модуль то может загрузить кто угодно по сути... Т.е. как ни круто - Лёня тут получается не при делах. Ну и по сути он прав. Хотя ситуация конечно сборная и сложная... Я с этим только вчера плотно столкнулся и не думал, что там есть какие-то важные настройки, удаление которых может окирпичить комп

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Другой аноним , 01-Фев-16 11:10 
> Не совсем верно. Запись в fstab необязательная. Modprobe efivars при условии загрузки
> в режиме uefi - и мы имеем подмонтированный раздел
> в sysfs. А модуль то может загрузить кто угодно по сути...
> Т.е. как ни круто - Лёня тут получается не при делах.
> Ну и по сути он прав. Хотя ситуация конечно сборная и
> сложная... Я с этим только вчера плотно столкнулся и не думал,
> что там есть какие-то важные настройки, удаление которых может окирпичить комп

Долбанный т9



"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 12:26 
> Долбанный т9

«подпор типов Анны» был круче.


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Аноним , 02-Фев-16 01:34 
>> Долбанный т9
> «подпор типов Анны» был круче.

А я уж было подумал, что это какой-то божественный сленг.



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:29 
Возможно она необязательная, но учитывается — https://github.com/systemd/systemd/issues/2402 .

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Crazy Alex , 01-Фев-16 12:17 
Ни хрена он по сути не прав. Если ты можешь прикрыть пользователя малой кровью от проблемы, которую не он создаёт - надо прикрывать. Мата в адрес MSI это не отменяет, конечно. А то, что он несёт - это его обычная безответственность.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:22 
Малой кровью здесь является монтирование в ро о чём должны позаботиться мейнтейнеры дистрибутива.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 12:29 
вот не надо, в этот раз он таки нормально всё говорит. если уж ты залез в рута, и решил всё убить — не надо от этого «защищать». да, всё на свете файл. надо было это выучить, прежде чем в рута лазить и rm делать.

вот если бы обычный юзер без рутовых привилегий мог такое сотворить — тогда да, тогда был бы Ужос.

а если рута «защищать», то следующим логичным шагом будет сделать из него недорута, как сделали из администратора флагшток‐куна в виндах.


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено анонанонанонанино , 01-Фев-16 13:26 
Поттер сказал: "рут может всё". В том-то и дело, рут может даже rm -rf, но где это видано чтобы rm -rf железо убивал? Вывод: поттер поломал rm -rf.

SYSTEMD ЛОМАЕТ RM -RF !!!1111адинадинадин


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Нимано , 01-Фев-16 16:32 
> Поттер сказал: "рут может всё". В том-то и дело, рут может даже
> rm -rf, но где это видано чтобы rm -rf железо убивал?

Когда-то на форточках запуск "setup.exe" (вернее, зараженного экзешника) уже убивал железо (см. CIH).
Привело к "костылянию" на стороне производителей железа ("железная" защита от записи). Со временем, правда, забылось и все вернулось на круги своя.



"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Адекват , 02-Фев-16 08:06 
> (см. CIH).
> Привело к "костылянию" на стороне производителей железа ("железная" защита от записи).
> Со временем, правда, забылось и все вернулось на круги своя.

Смотрим....

https://ru.wikipedia.org/wiki/CIH

CIH, или «Чернобыль» (Virus.Win9x.CIH) — компьютерный вирус, написанный тайваньским студентом Чэнь Инхао (кит. трад. 陳盈豪, пиньинь: Chén Yíngháo, англ. ) в июне 1998 года. Представляет собой резидентный вирус, работающий только под операционной системой Windows 95/98/ME.


Угу....98ой год...виндовс98.
Я вас правильно понял ? Современный линукс, благодаря исключительно своей архитектуре страдает проблемами винды 98 года разлива ?
Конечного пользователя же не волнует кто виноват будет - производитель буков, или Линус или Леннарт - у конечного пользователя будет убит ноут.
И да, если конечный пользователь придет к мысли "в винде ТАК НИКОГДА НЕ БУДЕТ" - он будет прав.
Не быть линуксу более чем на 5% десктопов, никогда, увы.
Заметьте - человек не поленился что-то вроде баг-репорта написать, иначе вы бы не узанли бы об этой проблеме.
На его месте мог кто-то из вас оказаться или ваших родственников, или вы могли так угробить чей-то ноут и попасть на бабки :)


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Аноним , 01-Фев-16 17:34 
Ты так и не понял что произошло.. Вместе с этой багой root получил права не только убить данные на носителях, но и само железо. Такое уже бывало многократно. И каждый раз в ядро или юзерспейс внедряли новую распорку, которая не давала root-у ломать железо. А тут по твоей логике какой-то особый случай. Странно слышать такое от тебя, arisu. Ты же в курсе насколько root в Linux ограничен в своих возможностях?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 15:58 
> Ни хрена он по сути не прав. Если ты можешь прикрыть пользователя
> малой кровью от проблемы, которую не он создаёт - надо прикрывать.
> Мата в адрес MSI это не отменяет, конечно. А то, что
> он несёт - это его обычная безответственность.

Да! Ошибку в моей программе предлагаю исправить разработчикам glibc, пусть напишут workaround. Или даже разработчиков компиляторов напрячь. Им чо, сложно што ле?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Anonplus , 01-Фев-16 10:51 
> Ну, наверное, не на системД можно указать как монтировать ту или иную
> систему. А системД монтирует некоторые на свой вкус.

ЕслИ бЫ вЫ внимательнО читалИ новостЬ, тО зналИ бЫ, чтО параметрЫ монтированиЯ определяюТ сборщикИ дистрибутивА.

Кстати, зачем вы делаете последнюю букву заглавной в тех словах, в которых она заглавной не предусмотрена?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Джедай , 01-Фев-16 12:02 
Потому что гладиолус

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено ryoken , 01-Фев-16 12:09 
> Другой вопрос - что это за системные утилиты, которые требуют кровь из
> носу доступ на запись в переменные UEFI, без которых загрузиться будет
> нельзя?

Навскидку - efibootmgr? И все, кто загрузочные записи в EFI делает.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Crazy Alex , 01-Фев-16 14:40 
Ну вот пусть они и монтируют. И отмонтируют после работы. Не самая частая операция, как ни крути.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:13 
> Другой вопрос - что это за системные утилиты, которые требуют кровь из
> носу доступ на запись в переменные UEFI, без которых загрузиться будет
> нельзя?

efibootmgr(8)


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Stax , 01-Фев-16 17:39 
Для полноты картины стоит упомянуть еще grub-install на uefi (хотя почти наверняка он сводится к копированию файлов + вызову efibootmgr)

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Нанобот , 01-Фев-16 10:27 
вполне аргументированый отказ разрабов

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:29 
Арчеводы самые любознательные.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 01:45 
> Арчеводы самые любознательные.

Это от того, что у них лучшая документация в сети.



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Led , 02-Фев-16 02:38 
>> Арчеводы самые любознательные.
> Это от того, что у них лучшая документация в сети.

Естествено, как обычно у школоты: учебников полно, но кто ж их читает?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 03-Фев-16 09:03 
Лучшая документация у rhel.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Иван , 16-Янв-18 21:18 
> Лучшая документация у rhel.

Запаришься искать, где написано, как сделать нужное без графического режима. Часть настроек без него вообще официально названа в документации невозможной.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 10:47 
все вполне логично если я грохнул efivars то с какого они должны сбрасыватся по дефолту? Я ведь их стер.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Иван , 16-Янв-18 21:19 
> все вполне логично если я грохнул efivars то с какого они должны
> сбрасыватся по дефолту? Я ведь их стер.

Но биос же при аналогичной операции сбрасывается на дефолт, а не исчезает.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено lucentcode , 01-Фев-16 10:48 
Лёнчик дело говорит - проблемы кривых разрабов MSI его волновать не должны. Пусть свои косяки они за собой сами поправляют. Тем более, что проблема похоже у них не связана с железом - это косяк самой прошивки UEFI.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:20 
Разработчики у MSI вполне себе адекватные и баги в UEFI фиксят хоть и не быстро.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:08 
А ещё кривых разрабов Гигабайтов (там такая же херня), а ещё мало ли каких кривых разрабов.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:57 
надо было брать макбук

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 19:32 
> надо было брать макбук

Куда мне нужно брать макбук?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Led , 01-Фев-16 23:57 
> надо было брать макбук

А попа не слипнется?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 01:49 
>> надо было брать макбук
> А попа не слипнется?

Ну а тебе то зачем это обсуждать? Тебе не предстоит подобных выборов в жизни.



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонимус вульгарис , 01-Фев-16 16:18 
> А ещё кривых разрабов Гигабайтов (там такая же херня), а ещё мало
> ли каких кривых разрабов.

Разве у гигабайтов тоже нет дуал биос, или как там в их интерпретации эта фича называлась? Отсутствие возможности восстановления прошивки без спец. оборудования — фирменная фишка MSI.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 17:41 
О да, вставить шлюшку с прошивкой ты не осилил, для этого нужно спец оборудование.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонимус вульгарис , 01-Фев-16 19:40 
> О да, вставить шлюшку с прошивкой ты не осилил, для этого нужно
> спец оборудование.

Для того, чтобы это работало, нужен хотя бы частично живой биос. Если же он убит совсем, как в случае большинства кирпичей, такой метод не работает. На форуме MSI полно тому примеров.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Crazy Alex , 01-Фев-16 12:18 
Его должны бы волновать проблемы пользователей. Но - увы...

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:00 
Самое удивительное в новости то, что парень поставил арч с уефи ))

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 19:33 
> Самое удивительное в новости то, что парень поставил арч с уефи ))

Мудрила чудный



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 01:57 
>> Самое удивительное в новости то, что парень поставил арч с уефи ))
> Мудрила чудный

Ну понятно, что там ноут и uefi прибито гвоздями, но вот у меня на Asus Sabertooth Z77 десктопной, uefi может в трёх режимах работать - без него вообще, по требованию ОС (то есть, если ОС может загрузиться только c uefi, то оно предоставляется) и принудительно только оно. Этими опциями рулит хозяин платы - человек, то есть, я.



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 04:01 
Почему минус? Потому что я среди идиотов?



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 02-Фев-16 04:06 
> Почему минус? Потому что я среди идиотов?

1) плюсминусы здесь ничего особого не значат, не нервничайте;
2) UEFI+CSM -- это ни разу не "по требованию ОС", а два набора фирмвари (на ноутах такое тоже вполне себе встречается);
3) обратите внимание на http://wiki.opennet.ru/ForumHelp


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 03-Фев-16 07:59 
Рейтинг: -30295 баллов

бгг, каанешна "ничего не значит", у-тю-тю


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Andrey Mitrofanov , 03-Фев-16 08:13 
> Рейтинг: -30295 баллов
> бгг, каанешна "ничего не значит", у-тю-тю

Да.   Как и ретинг -2312675 баллов.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:23 
А зачем вообще нужен этот уродский UEFI? Производители на пустом месте зачем-то придумали проблем всем пользователям. Никаких преимуществ тем же пользователям оно не даёт.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Roo2AT7d , 01-Фев-16 11:33 
Это как с системд: на 2 секунды быстрее включается устройство

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 02:02 
> Это как с системд: на 2 секунды быстрее включается устройство

Нет. У меня Core2Duo 3 Ггц, загружается со старта grub 3(!) секунды до приглашения ввода имени пользователя. А сколько тогда загружается современный i7? Я не знаю.



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Roo2AT7d , 03-Фев-16 13:38 
В новости про UEFI явно имеется ввиду холодный старт, к тому же многое упирается в io.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:37 
Конечно не нужен, давайте пользоваться сороколетним биосом подпёртым костылями со всех сторон, лишь бы он работал с современным железом.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Анонимо , 01-Фев-16 20:30 
UEFI наверное без костылей? Что-то ему это не помогло.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:56 
например, с EFI чтобы сделать загрузочную флешку, не нужны никакие dd и unetbootin - достаточно распаковать на нее образ с дистром. Есть efi shell, из которой можно загрузить ядро с нужными параметрами. Ну и secure boot - кто бы что ни говорил, но если есть возможность управлять ключами, то это очень полезная штука.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:17 
> например, с EFI чтобы сделать загрузочную флешку, не нужны никакие dd и
> unetbootin - достаточно распаковать на нее образ с дистром.

Вот сюда почитайте ещё: http://mjg59.dreamwidth.org/4957.html

> то это очень полезная штука

Пользовались?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:24 
Так трудно написать dd?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонимус вульгарис , 01-Фев-16 19:37 
> например, с EFI чтобы сделать загрузочную флешку, не нужны никакие dd и
> unetbootin - достаточно распаковать на нее образ с дистром.

Это что же получается, теперь вместо

    # dd if=image.iso of=/dev/sdx

можно писать

    # mkfs.vfat -I /dev/sdx
    # mkdir /mnt/iso /mnt/flash
    # mount -o loop image.iso /mnt/iso
    # mount /dev/sdx /mnt/flash
    # cp -a /mnt/iso/* /mnt/flash
    # umount /mnt/iso
    # umount /mnt/flash
    # rmdir /mnt/iso /mnt/flash

???
До чего прогресс дошёл...


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 19:34 
> А зачем вообще нужен этот уродский UEFI? Производители на пустом месте зачем-то
> придумали проблем всем пользователям. Никаких преимуществ тем же пользователям оно не
> даёт.

Тебя не спросили, иди выступи на конференции и расскажи всем какое каках этот ваш UEFI и как замечателен BIOS.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:34 
Еще один факт почему уефи нинужен. Слишком уж навороченный.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено DeadLoco , 01-Фев-16 18:47 
Ну, почему же? Очень даже нужен. Например, можно незаметно для юзера грузить баребоновый гипервизор, затем юзерскую ОС, и еще втихаря свои хитрые штучки, которые будут перехватывать все-все - от сетевых пакетов до клавиатурного ввода и отпечатков пальцев со сканера. Круто же!

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 19:35 
> Ну, почему же? Очень даже нужен. Например, можно незаметно для юзера грузить
> баребоновый гипервизор, затем юзерскую ОС, и еще втихаря свои хитрые штучки,
> которые будут перехватывать все-все - от сетевых пакетов до клавиатурного ввода
> и отпечатков пальцев со сканера. Круто же!

Неуловимый Джо перелогиньтесь.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Анонимо , 01-Фев-16 20:32 
расскажи это Сноудену

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:40 
самое главное что так смонтировали ребята из арча, а виноват все равно systemd

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:40 
Имхо, поттеринг не прав, т.к. В любом ПО есть workaroud, как это есть с чипсетами nVidia, Radeon r6xx/r7xx. Например работа USB контроллеров.
ИМХО, слабый аргумент, что бы это игнорировать.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено RazrFalcon , 01-Фев-16 11:41 
В Gentoo без systemd вообще efi не монтируется. Зачем он нужен, да еще и в режиме rw - непонятно.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Crazy Alex , 01-Фев-16 12:21 
Вот именно. Те полторы утилиты, которым он нужен, вполне могут сами его смотировать, сделать что надо и размонтировать обратно. Как по мне, кстати, то же самое и к /boot относится.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:14 
> Вот именно. Те полторы утилиты, которым он нужен, вполне могут сами его
> смотировать, сделать что надо и размонтировать обратно. Как по мне, кстати,
> то же самое и к /boot относится.

А мне всё-таки кажется, что efibootmgr и те полторы утилиты вызываются несравненно чаще, чем rm -rf /


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:32 
'it should be mounted through the sysfs init script'
https://wiki.gentoo.org/wiki/Efibootmgr

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:18 
> В Gentoo без systemd вообще efi не монтируется.

Это не "efi" (эт где?), а /sys.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено RazrFalcon , 03-Фев-16 12:05 
Странно, еще пару лет назад нужно было efivars самому подгружать, а теперь он грузится сам. Видимо что-то поменялось.
Тем не менее /sys/firmware/efi/efivars пустой.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 13:19 
> В Gentoo без systemd вообще efi не монтируется. Зачем он нужен, да
> еще и в режиме rw - непонятно.

Счеголи не монтируется то? Как я по твоему тогда получил надпись "Gentoo" в меню загрузки? OpenRC, само собой.

Если же ты грузишься в режиме legacy - то примонтировать efivars не получится


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 11:55 
https://twitter.com/mjg59/status/693494314941288448
Жду оправданий поттеринг-хейтеров.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:39 
Кого-кого? Нет таких людей, вы сами их выдумали.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:54 
Прям библейское "подставь свою жoпy"

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 12:20 
я не понял, сегодня же не первое апреля. а новость из разряда: «британские учёные выяснили, что если положить голову под гидравлический пресс и запустить, то можно умереть. поголовье британских учёных значительно уменьшилось.»

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Аноним , 01-Фев-16 12:27 
Просто новость жёлтая. Объективное обсуждение проблемы было бы с заголовком 'rm -rf / под рутом убивает некоторые реализации uefi'.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 12:40 
а если ещё точнее, то: «некоторые реализации уефы не могут в emergency recovery mode».

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Анонимо , 01-Фев-16 20:34 
> а если ещё точнее, то: «некоторые реализации уефы не могут в emergency
> recovery mode».

не точнее, команда не должна убивать uefi - в этом суть, а вместо emergency может стоять и другая технология


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 21:50 
emergency — он на то и emergency, что его зовут, когда уже всё пропало, юзер всё сломал, и жопа переместилась с горизонта на соседний стул.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено AlexYeCu_not_logged , 01-Фев-16 12:23 
Кстати, а что будет с матплатой, если винт с уефишным разделом тупо сдохнет?
Там вообще чтоли никаких "настроек по умолчанию" нет? Сдох винт, плата окирпичилась?
Из-за чего такой шум-то?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:29 
Новый уровень понимания ситуации в треде.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено narical , 01-Фев-16 13:18 
Ничего не будет. Винт не имеет никакого отношения к работоспособности UEFI. Учи матчасть.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:19 
> Там вообще чтоли никаких "настроек по умолчанию" нет? Сдох винт, плата окирпичилась?

Не-а.  См. http://www.rodsbooks.com/efi-bootloaders/ по порядку, если интересно.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 02:17 
>> Там вообще чтоли никаких "настроек по умолчанию" нет? Сдох винт, плата окирпичилась?
> Не-а.  См. http://www.rodsbooks.com/efi-bootloaders/ по порядку, если интересно.

Туманно дал туманную ссылку Шигорин, сам, видимо, нимуя не понимая.



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 04:11 
>>> Там вообще чтоли никаких "настроек по умолчанию" нет? Сдох винт, плата окирпичилась?
>> Не-а.  См. http://www.rodsbooks.com/efi-bootloaders/ по порядку, если интересно.
> Туманно дал туманную ссылку Шигорин, сам, видимо, нимуя не понимая.

Есть минусы, но нет пояснения ситуации. Всё-таки профессионально-техническое.. не очень техническое образование Шигорина не даёт ему.. объяснить ситуацию.



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Andrey Mitrofanov , 02-Фев-16 11:43 
> Есть минусы, но нет пояснения ситуации. Всё-таки профессионально-техническое.. не очень
> техническое образование Шигорина

Те два минуса, я _думаю_, были от тех, кто посчитал бесполезным обсуждение на предложенном Вами уровне, аргументацию недостойной обсуждения и т.п..  Вот Вам третий от меня. ...а, да, один из двух уже был мой. Но не суть же.

Вот Вам ещё минус на "почему минус без пояснения": за трату _моего_ времени _дважды_.

Спасибо за Ваше понимание!


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:26 
Всё будет нормально, этот раздел не на винте, а облаке(яндекс диск).

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 12:23 
p.s. в кои‐то веки портерингико ответили нормально. а то в попытках защитить идиота от самого себя дойдут до того, что и рут будет уже не рут, как в винде.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 12:40 
Лишь бы поср@ться. Собрались бы разрабы systemd вместе с разработчиками ядра, по возможности пригласили бы разработчиков железа. Обсудили бы как выйти из ситуации. Важен конечный продукт. Умение выходить из кризисных ситуаций - вот что должно характеризовать разработчиков как хороших, а не огрызание и показывание пальцем.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 12:42 
выйди, пожалуйста. вон из дверей.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 02:18 
Но вместо них, как всегда, срётся опнетик ;)



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:00 
Эту директорию необходимо монтировать к ro, как какой-нибудь DVD-ROM или Floppy с защёлкнутым окошком.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:26 
Её можно запросто перемонтировать. Это костыль.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 02:21 
> Эту директорию необходимо монтировать к ro, как какой-нибудь DVD-ROM или Floppy с
> защёлкнутым окошком.

Точняк. Давайте теперь убивать заводские штампованные дивидюки и блюраи уличной магией из командной строки! :)



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:09 
На лоре написали, что виновным себя признал гаретый феминист

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 02:22 
> На лоре написали, что виновным себя признал гаретый феминист

Проклятый любитель тян?



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено CodeRush , 01-Фев-16 13: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-чипе так никто реализовать не смог - может быть, дело не в людях, а проблемы в консерватории?..

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 01-Фев-16 13:27 
Спасибо за рассказ, хорошо бы им дополнить новость, если не против.

> Во-первых, те немногие вещи, для которых этот доступ нужен утилите efibootmgr,
> должны решаться самой прошивкой (добавление/удаление/поиск новых UEFI-загрузчиков,
> изменение порядка загрузки)

Конкретно тут явный перегиб -- и на BIOS доводилось крутить nvramtool'ом в оптовых количествах.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено CodeRush , 01-Фев-16 13:37 
Без проблем, конечно.
С моей точки зрения, если нужно что-то крутить из внутренностей прошивки - для этого специально предназначен UEFI Shell, из него есть доступ ко всем протоколам, ко всем драйверам еще не выгруженным, к BootServices, и вообще ко всему "мясу и кишкам" прошивки. При этом загрузиться в него можно только пройдя правильно настроенный SecureBoot, а не воспользовавшись очередным LPE.
Обновление прошивки уже перенесли в безопасное pre-boot окружение, т.к. защитить его нормально оказалось практически невозможно, теперь туда же нужно переносить и настройку.  У автора блога firmwaresecurity.com Ли Фишера была недавно мысль о функции ExitRuntimeServices, после которой от UEFI оставались бы одни SMM-обработчики и ACPI-таблицы. Я считаю, что такой режим был бы полезным, и продвигать его однозначно стоит, даже ценой отказа от доступ к NVRAM и функции GetTime, но это мое мнение, и навязать его UEFI Forum'у я, понятно, не могу.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:30 
> С моей точки зрения, если нужно что-то крутить из внутренностей прошивки - для этого специально предназначен UEFI Shell

Ну и как тогда например менять параметры загрузки на удаленной машине ? Никак ?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено CodeRush , 01-Фев-16 14:45 
А какие именно параметры предполагается менять? Если порядок загрузки - используйте GRUB или любой другой EFI-бутлоадер с конфигурацией, если опции ядра - тем более. Если вам нужны более серьезные модификации - пользуйтесь IPMI или AMT для удаленного управления из BIOS Setup. Загрузчик новой системы, которая устанавливалась по сети через PXE или UEFI HTTP Boot, подхватит и добавит в список загрузочных устройств диспетчер BDS, если её загрузчик положить на ESP в указанную в документации директорию (http://uefi.org/registry).

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Crazy Alex , 01-Фев-16 14:37 
Как мнение пользователя/программиста/в прошлом админа - чем меньше специализированных сред - тем лучше. Я хочу при решении задач иметь привычный набор инструментов - от скриптов до доступа из сети, причём всё это - стандартным для моей инфраструктуры образом. В этом плане идея закрыть к чему-либо доступ из ОС мне не нравится совершенно.

Но вот сделать этот доступ нетривиальным, чтобы исключить случайности - дело другое. В данном случае я вообще не понимаю, зачем эту FS монтировать без явной нужды, хоть в RO, хоть в RW.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено CodeRush , 01-Фев-16 14:59 
Моя задача, как разработчика прошивок - не только правильно инициализировать и передать ОС все установленные на плате железяки, но и сделать так, чтобы никакой дальнейший код мою прошивку сломать не мог, будь он запущен в ОС от рута или от черта лысого. С одной стороны, это связано с тем, что восстановление зачастую долгое и дорогое, а простые вроде бы решения ("поставьте второй чип") - они при массовом производстве стоят самые настоящие миллионы долларов, а сейчас нужно экономить на всем, иначе у тебя ничего не купят. С другой стороны, прошивка на данный момент является либо корнем доверия в системе, либо одним из звеньев цепи доверия, начинающейся с железа (BootGuard, PSP HWVB, вот это все). Потому мне нужно как-то защитить эту самую прошивку от разрушительных и/или вредоносных изменений, а лучший способ это сделать - хранить её на устройстве, которое просто нельзя смонтировать в RW из ОС. Я понимаю, что для пользователя это создает дополнительные трудности, но в конкретно этом случае security/convenience trade-off я выбираю сторону security, вот такая у меня профдеформация.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 15:02 
маленький нюанс тут, правда, в том, что это называется не «секурити», а «анальное огораживание».

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено CodeRush , 01-Фев-16 15:10 
Альтернативу предложите для нынешних платформ?
Открыть прошивку целиком не позволят сами производители чипов, слишком много документации придется выводить из под NDA. Получить нужные сведения реверс-инженирингом либо очень долго (3-4 поколения продуктов успевает смениться), либо вообще невозможно (на новых APU AMD инициализацию памяти выполняет встроенный криптопроцессор из своей TrustZone, а его прошивка подписана и зашифрована, удачи в реверсе). Пока у нас закрытое железо - открытых прошивок к нему не будет, и исключение libreboot только подтверждает наличие правила. Я смотрю с надеждой на OpenRISC и другие инициативы, но сейчас - лучше анальное огораживание, чем дефиле с голой жопой, уж простите.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 15:17 
> Альтернативу предложите для нынешних платформ?

конечно. но она очень не понравится производителям — что и было описано в скипнутой части поста. но лично для меня это не причина врать, называя «огораживание» «секурностью».


"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено CodeRush , 01-Фев-16 15:27 
Ну пусть будет "огораживание", хоть горшком назови, только в печь не станови. На системах с Intel BootGuard, настроенным на максимальное огораживание, вообще нельзя изменить ни одно байта в любом месте, кроме региона для NVRAM - они подписаны, а хеш ключа зашит в однократно-записываемую память чипсета. Хочешь экспериментов - меняй чипсет на чистый, если у тебя СнК - то и всю СнК. Вот это огораживание, тут я ничего сказать не могу, но я так на своих системах постараюсь не делать до последнего, т.к. вот это уже сильно ограничивает свободу пользователя. От порчи же прошивки софтом (а не пользователем с физическим доступом, способным загрузить UEFI Shell) я защищался и буду защищаться, хоть как это называйте.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Аноним , 01-Фев-16 17:30 
Скажите пожалуйста, прошивки чего вы разрабатываете (ну чтоб случайно не купить) ?

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Crazy Alex , 01-Фев-16 17:34 
Присоединяюсь к вопросу.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено CodeRush , 01-Фев-16 17:53 
Случайно вы их все равно не купите, это промышленные платы congatec в форм-факторе COM-Express и QSeven.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Иван , 16-Янв-18 21:47 
> Альтернативу предложите для нынешних платформ?

Джампер ro/rw? И пусть владелец сам решает, разрешать писать в NVRAM из ОС или нет с риском сложного востановления.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Crazy Alex , 01-Фев-16 17:46 
Позиция ясна. У меня она несколько другая:

1) если путём нетривиальных манипуляций владелец свою железку таки угробил - это его вина и его проблемы. Будь то "левая" смазка в шуруповёрте, стёртая с процессора термопаста или залитая левая прошивка - случай явно не гарантийный. Конечно, если при такой ситуации будет какая-то возможность сбросить устройство в дефолты, это плюс - но, вообще говоря, не обязательно.

2) "защита" прошивки от нетривиальных действий рута, запущенного на этом же устройстве (то есть после прохождения всех верификаций на этапе запуска системы) - это не "дополнительные трудности", а нечто совершенно неприемлемое. Это не security, а банальное ограничение прав якобы владельца устройства.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено CodeRush , 01-Фев-16 18:04 
> 1) если путём нетривиальных манипуляций владелец свою железку таки угробил - это
> его вина и его проблемы. Будь то "левая" смазка в шуруповёрте,
> стёртая с процессора термопаста или залитая левая прошивка - случай явно
> не гарантийный. Конечно, если при такой ситуации будет какая-то возможность сбросить
> устройство в дефолты, это плюс - но, вообще говоря, не обязательно.

Тем не менее, системы с какой-то защитой, даже если она по факту или не работает, или не работает как надо, продаются значительно веселее, чем без совсем без нее, поэтому сейчас их делает каждый IBV, и у всех практически она не работает как надо. Маркетинг - он такой.

> 2) "защита" прошивки от нетривиальных действий рута, запущенного на этом же устройстве
> (то есть после прохождения всех верификаций на этапе запуска системы) -
> это не "дополнительные трудности", а нечто совершенно неприемлемое. Это не security,
> а банальное ограничение прав якобы владельца устройства.

Не согласен. Если вы действительно владелец устройства, у вас есть физический доступ, т.е. джампер для вас переставить - проблемы не составляет. Защита от изменения прошивки ограничивает не пользователя, а вредоносный код, получивший у этого пользователя рута каким-либо образом. В Linux за год находят 3-5 локальных повышений привилегий, и еще 1-2 удаленных выполнения кода, т.е. вероятность атаки на прошивку от рута ниже того порога, после которого нужна защита от такого рода атак. Проблема в том, что кроме Linux у нас сейчас используются некоторые другие ОС одной известной компании, в которой получить рута легче, а разрушительные последствия - такие же. Тем более, что с внедрением UEFI сложность разработки вредоносного кода для прошивки уменьшилась даже не на порядок, а еще сильнее, и если не защищать её сейчас - потом будет уже поздно. Не нравится - не покупайте, я не заставляю, у Gigabyte и EVGA нет вообще никаких защит до сих пор, все платы шьются flashrom'ом из любой ОС. Coreboot есть для тех, кто реализациям UEFI не доверяет, опять же. Хотите сидеть с открытой прошивкой - у вас есть такая возможность, только вот мы не хотим, и клиенты наши тоже.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено vi , 01-Фев-16 21:28 
Две Ваши фразы (возможно, "вырванные" из контекста).
> С одной стороны, это связано с тем, что восстановление зачастую долгое и дорогое, а простые вроде бы решения ("поставьте второй чип") - они при массовом производстве стоят самые настоящие миллионы долларов, а сейчас нужно экономить на всем, иначе у тебя ничего не купят.
> Тем не менее, системы с какой-то защитой, даже если она по факту или не работает, или не работает как надо, продаются значительно веселее, чем без совсем без нее, поэтому сейчас их делает каждый IBV, и у всех практически она не работает как надо. Маркетинг - он такой.

Поясните? Хотя, необязательно.


>[оверквотинг удален]
> изменения прошивки ограничивает не пользователя, а вредоносный код, получивший у этого
> пользователя рута каким-либо образом. В Linux за год находят 3-5 локальных
> повышений привилегий, и еще 1-2 удаленных выполнения кода, т.е. вероятность атаки
> на прошивку от рута ниже того порога, после которого нужна защита
> от такого рода атак. Проблема в том, что кроме Linux у
> нас сейчас используются некоторые другие ОС одной известной компании, в которой
> получить рута легче, а разрушительные последствия - такие же. Тем более,
> что с внедрением UEFI сложность разработки вредоносного кода для прошивки уменьшилась
> даже не на порядок, а еще сильнее, и если не защищать
> её сейчас - потом будет уже поздно.

С чем боролись, ... ;)

> Не нравится - не
> покупайте, я не заставляю, у Gigabyte и EVGA нет вообще никаких
> защит до сих пор, все платы шьются flashrom'ом из любой ОС.
> Coreboot есть для тех, кто реализациям UEFI не доверяет, опять же.
> Хотите сидеть с открытой прошивкой - у вас есть такая возможность,
> только вот мы не хотим, и клиенты наши тоже.

И да, перемычки сейчас "немодно" (немаркитоидно, так сказать ;) Ибо позволяют железке служить немного дольше, чем заложено производителем (хотя, на сегодняшний момент есть и другие методы создать потребителю так сказать постоянный зуд в одном месте :(


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено CodeRush , 01-Фев-16 22:02 
> Поясните? Хотя, необязательно.

Поясняю. Есть несколько методов восстановления прошивки, но все они делятся на два больших класса - работающие, но дорогие, и бесплатные, но работающие через раз. Я о том, что первыми почти никто не пользуется по причине экономии средств, а вот вторые реализованы почти у всех, но срабатывают правильно они довольно редко.

> И да, перемычки сейчас "немодно" (немаркитоидно, так сказать ;) Ибо позволяют железке
> служить немного дольше, чем заложено производителем (хотя, на сегодняшний момент есть
> и другие методы создать потребителю так сказать постоянный зуд в одном
> месте :(

Дело не в маркетоидности, а в той самой NVRAM, которой вынь да полож доступ на запись в произвольный момент времени. Плюс в том же чипе свои настройки хранят Management Engine, Ethernet-контролер, Embedded Controller и остальные, причем первые два тоже могут осуществлять запись в случайный момент времени - как тут делать RO в таких условиях?
По поводу срока службы - верьте во что хотите, я никакого ухудшения качества материнских плат не вижу, и железо у обычных пользователей успевает устареть из за прогресса ПО (если это считать прогрессом, но это уже другой вопрос), а в промышленности работает по 10 лет и не жужжит.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено vi , 01-Фев-16 22:17 
>> Поясните? Хотя, необязательно.
> Поясняю. Есть несколько методов восстановления прошивки, но все они делятся на два
> больших класса - работающие, но дорогие, и бесплатные, но работающие через
> раз. Я о том, что первыми почти никто не пользуется по
> причине экономии средств, а вот вторые реализованы почти у всех, но
> срабатывают правильно они довольно редко.

Все равно, за все заплатит потребитель!

>[оверквотинг удален]
> Дело не в маркетоидности, а в той самой NVRAM, которой вынь да
> полож доступ на запись в произвольный момент времени. Плюс в том
> же чипе свои настройки хранят Management Engine, Ethernet-контролер, Embedded Controller
> и остальные, причем первые два тоже могут осуществлять запись в случайный
> момент времени - как тут делать RO в таких условиях?
> По поводу срока службы - верьте во что хотите, я никакого ухудшения
> качества материнских плат не вижу, и железо у обычных пользователей успевает
> устареть из за прогресса ПО (если это считать прогрессом, но это
> уже другой вопрос), а в промышленности работает по 10 лет и
> не жужжит.

OverlayFS


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 02-Фев-16 00:31 
> OverlayFS

В чипе?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено XoRe , 03-Фев-16 17:39 
А если просто ввести sysctl параметр, что-то типа a.b.c.rw = 1?
По умолчанию, естественно, сделать rw = 0.
Если кому нужно обновить что-то, у них будет простой способ:
sysctl a.b.c.rw = 1
update
sysctl a.b.c.rw = 0
И все.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено НяшМяш , 01-Фев-16 13:20 
Я как-то почти навечно окирпичил материнку от Гигабайта (которые якобы лучше всех для хакинтоша). В efi shell случайно потёр записи в nvram. Материнка отказалась запускаться, даром что в ней две микросхемы биоса и всё такое. Шаманство с замыканием ног главной микросхемы биоса помогло запуститься с резервной и я сэкономил 150$. Хотя на тех же маках есть сочетание клавиш для сброса этой самой nvram - и комп после этого отлично выживает.На стандарты всем пофиг я понял тогда, когда начал патчи на dsdt накладывать - половина функций стабы, другая половина возвращает минимально возможные данные. Как с этим всем винда с линём работает - просто магия.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:27 
Может как-то обезопасить файлы от удаления?
1 Почему нельзя делать что-то типа echo "uefi suka command" /sys/uefi/pipe
2 Зачем вообще нужен этот католог и как он используется?
3 Разделить католог на безопасную часть которую можно редактировать (настройки бута) и другую.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:29 
Вот за что не люблю uefi. Мало того что написали кучу костылей типа править параметры мышкой, залочить устройство от его хозяина, так ещё и +100500 способов прострелить ногу.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:18 
Да, к uefi c secureboot скоро понадобятся кряки чтобы только загружать Linux (и пиратскую винду). Людей уже приучают на смартфонах что типа нормально когда нельзя просто загрузиться или просто воспользоваться root.
"Рутование" - слово то какое мерзкое.
Это uefi с одной стороны раздутая, а с другой в ней нет многих вещей.
И Secure Boot не защищает от вторжения, а только от пользователя. Ей не нужны были ключи, она должна была делать контрольные суммы например предупреждая о запуске того чему я ещё не доверяю.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 13:50 
- Доктор, у меня болит, когда я делаю вот так.
- Не делайте так больше.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Михрютка , 01-Фев-16 13:57 
вроде ж ходили уже по этим граблям?

https://lkml.org/lkml/2012/2/16/234


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:07 
rm -rf / --no-preserve-root --no-preserve-uefi-mountpoint --disable-confirmation-dialog-and-crack-computer-with-unpossibilities-of-restoring
# простите за мой диалект.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:19 
"пользователь решил понаблюдать как поведёт себя система в случае выполнения "rm -rf /", после чего ноутбук пришёл в неработоспособное состояние и перестал подавать признаки жизни"


Я РЖАЛ)


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:43 
Я тоже делал это и один раз случайно. Прочитал про опцию --no-preserve-root и стало интересно будет ли она запрошена при пути /* вместо '/' Оказалось не будет и я удалил всё что есть на компьютере.  

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:46 
> Я РЖАЛ)

Проблема не в том, что ноутбук перестал подавать признаки жизни.
Проблема в том, что на него теперь даже установить другую операционку нельзя.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено цупцпцуп , 01-Фев-16 19:17 
>> Я РЖАЛ)
> Проблема не в том, что ноутбук перестал подавать признаки жизни.
> Проблема в том, что на него теперь даже установить другую операционку нельзя.

Да я понял, просто уж очень смешно звучит)


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Led , 02-Фев-16 00:03 
> "пользователь решил понаблюдать как поведёт себя система в случае выполнения "rm -rf
> /", после чего ноутбук пришёл в неработоспособное состояние и перестал подавать
> признаки жизни"
> Я РЖАЛ)

Старшеклассники всегда над младшенькими ржут.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:45 
Итак, Вы решили прострелить себе ногу (версия для систем инициализации).
sysv init: Вы успешно простреливаете себе ногу из старого дедовского дробовика.
systemd: Вы наводите прицел современной высокотехнологичной снайперской винтовки на свою ногу, но пуля попадает Вам в голову.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 08:27 
> systemd: Вы наводите прицел современной высокотехнологичной снайперской винтовки

Не уверен, что сравнение этого нагромождения всякой всячины со снайперской винтовкой является уместным...


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:49 
А кто-нибудь проверял, что будет, если выполнить

rm -rf /proc /sys

?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 02:42 
> А кто-нибудь проверял, что будет, если выполнить
> rm -rf /proc /sys
> ?

Во Фре не даст смонтированный через fstab линуксовый proc удалить, хоть ты тресни. Он там нужен для работы некоторых линуксовых портов, htop, например. Хоть тресни, не удалишь, пока не размонтировано.



"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:51 
А мне не верили на лоре, когда у меня такая же проблема была. Мда. А про какого-то придурка щас даже на опеннете новость. Круто, ага.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 14:54 
ну, теперь ты знаешь, что ты не единственный такой придурок. надеюсь, тебе полегчало.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Аноним , 01-Фев-16 15:47 
Да, ещё я знаю, что такие же есть и тут. Например, ты.

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено arisu , 01-Фев-16 15:55 
это да. куда мне до гениев, сносящих всё рекурсивно с корня под рутом!

"Выполнение rm -rf / может привести к неработоспособности..."
Отправлено Аноним , 01-Фев-16 21:01 
я так и не понял, а просто создать новую fs на диске не судьба?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 15:13 
Потому что ты писал про свою проблемы на лоре, а "придурок" на форуме арча. Отсюда и  разный результат.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено IMHO , 01-Фев-16 17:48 
> А мне не верили на лоре

на ЛОРе про линукс хотят слышать только хорошее, а все остальное 4.2


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 14:53 
Чувак, конечно, лох, но будь у него не MSI, проблем с восстановлением не было бы. А MSI без программатора не чинится.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 19:17 
> Чувак, конечно, лох, но будь у него не MSI, проблем с восстановлением
> не было бы. А MSI без программатора не чинится.

Вы откуда такие недо инженеры беретесь?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 15:12 
То странное чувство, когда комментарии на опеннет адекватней комментариев на хакерньюс.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонимус вульгарис , 01-Фев-16 16:08 
Если программа может непоправимо повредить оборудование, это баг оборудования.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено клоун , 01-Фев-16 16:21 
Нет, это значит, что есть две ошибки. И ни одна из них не оправдывает другую.

Почти все современные катастрофы происходят в ситуациях, когда ошибаются 2 или более лиц.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено анонимус вульгарис , 01-Фев-16 19:24 
Согласен, ошибок в данном случае две. Одну из них допустили разработчики EFI, другую — юзер.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Адекват , 01-Фев-16 15:33 
Линуксойды должны страдать.

1. От наглухо завешивающих систему (иксы, но один хер ничего пользователь не сделает) chromium'ов:
http://www.techsupportforum.com/forums/f64/solved-system-fre...
https://toster.ru/q/237935
файерфокс тоже:
https://bbs.archlinux.org/viewtopic.php?id=201333
2. От зависаний на 1,5 минуты при выключении:
https://bugs.freedesktop.org/show_bug.cgi?id=70593
3. От необходимости использоваться pulseaudio, иначе:
https://bbs.archlinux.org/viewtopic.php?id=188236
и не факт что Pulseaudio поможет.
4. От того, что линукс - он не ваш, он ментейнерский, и если вы пользуетесь каким-то любимым DE, например xfce4, то ментейнеры могут просто болт на его поддержку забить и вам ПРИДЕТСЯ перебираться на другой DE.
https://www.linux.org.ru/news/linux-general/11254746
5. Теперь видно что линукс МОЖЕТ угандоишить железо, как мило, ми-ми-ми :))


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 18:46 
Винда тоже не ваша, ты ее взял напрокат почитай EULA. Ну учитывая что в линуксе 100500 DE даже если один из них прекратят поддерживать можно перейти на похожий. А зачем мейнтенерам прекращать поддерживать популярный DE? Логика та же что и в коммерческих поделиях. Ой, файрфокс и вообще любой браузер прекрасно вешает намертво систему в любом мастдае. И не надо сказки рассказывать Я бывший пользователь их седьмого поделия.
Жаль тебя огорчать, но ни от чего перечисленного не страдаю :))

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Нимано , 01-Фев-16 19:08 
> файерфокс тоже:
> https://bbs.archlinux.org/viewtopic.php?id=201333

Ага,
> It just becomes unresponsive and when I switch windows/workspaces it continues to not paint the window an instead

подвешивание наглухо – оно тако, не показывает нужное окошко!

> 2. От зависаний на 1,5 минуты при выключении:
> https://bugs.freedesktop.org/show_bug.cgi?id=70593

Ну, это хоть баг, а в некоторых осях это фича – ведь вполне логично начинать ставить обновления при выключении ноута, пользователь ведь наверняка никуда не торопится! )

> 3. От необходимости использоваться pulseaudio, иначе:
> https://bbs.archlinux.org/viewtopic.php?id=188236

А для фотошопа <подставить любую проприетарь> вообще нужна виртуалка, а то и установка форточки!1

> 4. От того, что линукс - он не ваш, он ментейнерский,

Откройте для себя уж LFS, генту <нужное вставить> ну или просто банальный компилятор, которым (вот засада-то, а!) можно тупо собрать нужный софт.

В общем, аккуратней надо, а то вентилятор не справляется.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено vi , 01-Фев-16 21:40 
> В общем, аккуратней надо, а то вентилятор не справляется.

Спасибо! Хоть кто то повеселил ;)


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено twiroh5r6hw , 05-Фев-16 02:25 
>линуксоЙды

Такие как ты должны страдать.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Daemon , 01-Фев-16 16:36 
Потестил на слаке - все норм. Просто руки дошли оффтоп поставить по нужде...

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 22:27 
Там так же sysfs монтируется в rw.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Led , 02-Фев-16 00:10 
> Просто руки дошли оффтоп поставить по нужде...

По нужде не ставят, а ходят.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 16:59 
Кстати, а системд можно настроить так, чтобы эта байда вообще не монтировалась, ни в ro, ни в rw?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 13:37 
> Кстати, а системд можно настроить так, чтобы эта байда вообще не монтировалась,
> ни в ro, ни в rw?

пересобрать ядро без поддержки модуля efivars


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 03-Фев-16 00:06 
Может проще в блэклист внести?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 17:44 
Забавная зависимость, чем дурней новость тем больше комментариев. Что явно намекает на уровень комментаторов.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 18:39 
Очевидно же что на некоторые новости на opennet.ru приходят тролли (оплачиваемые так или иначе) для задания определённого тона в обсуждении новости.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 18:55 
Не прослеживаю такой очевидной зависимости.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 03-Фев-16 08:08 
Ну давайте профы, что-ли, интересно почитать. В идеале - зарплатную ведомость.

А то, раз мы тут родину продаём, вдруг недоплачивают?


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Andrey Mitrofanov , 03-Фев-16 08:15 
> Ну давайте профы, что-ли, интересно почитать. В идеале - зарплатную ведомость.
> А то, раз мы тут родину продаём, вдруг недоплачивают?

Сходи печёночку проверь. Твоя зарплата придёт туда.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 03-Фев-16 12:41 
Бессвязная речь, спутанность мыслей и недержание темы разговора - верный признак начинающейся шизофрении. Марш к психиатру.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 03-Фев-16 18:59 
У чем дурность новости? В том что большому количеству людей показали/напомнили что надо перемонтировать efivars в ro после установки и настройки загрузчика?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 01-Фев-16 18:23 
Всегда считал что BIOS это программа которая мешает работать OS. UEFI как дитя BIOS только ухудшила ситуацию.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено тоже Аноним , 01-Фев-16 21:34 
Берешь пассатижи, выдергиваешь микросхему из платы - и ничего твоей ОС больше не мешает!

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 03-Фев-16 12:42 
Берешь пассатижи, выдергиваешь себе яйцы - и ничего твоей смене ориентации больше не мешает!

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено AlexAT , 01-Фев-16 22:18 
Итого режим работы UEFI/BIOS в личной практике оказывался переключенным на BIOS на 99% серверов и пк/нб. Впрочем, желающие жевать кактусы могут жевать мсявное поделие дальше.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 03-Фев-16 18:56 
если он есть. Если работает.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 01:28 
один себе крайне удачно в ногу выстрелил, другие зажопились вменяемо ответить на вопрос "на кой вам efivars на запись?". все как обычно

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Нимано , 02-Фев-16 01:48 
> один себе крайне удачно в ногу выстрелил, другие зажопились вменяемо ответить на
> вопрос "на кой вам efivars на запись?". все как обычно

https://github.com/systemd/systemd/issues/2402
> poettering commented 12 hours ago
> To make this very clear: we actually write to the EFI fs in systemd. Specifically, when you issue "systemctl
> reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup.
> And because we need it writable we'll mount it writable for that.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аноним , 02-Фев-16 02:21 
я ведь сформулировал вопрос - "на кой". т.е. - "зачем", а не "кому". вот зачем это надо делать именно так? какой юзкейс и частота применения этого финта ушами?

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Михрютка , 02-Фев-16 22:18 
ну например мне нужно загрузить систему с другого девайса. one off или постоянно.

я бы с удовольствием сделал бы это через какое-нибудь ilo но на него то лицензию не купят то браузер поломают то плугин отменят.

и нет, мне не очень интересна частота этого юзкейса. даже раз в год тащиться в Малые Ебеня в нерабочее время, чтобы тыкнуть кнопочку при загрузке железа для меня на раз больше чем надо.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено bOOster , 02-Фев-16 11:18 
Чото боян, года 2-3 назад гнусмас уже имел проблемы индентичного характера. И как раз когда очищались системные разделы.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Andrey Mitrofanov , 02-Фев-16 11:53 
> Чото боян, года 2-3 назад гнусмас уже имел проблемы индентичного характера. И
> как раз когда очищались системные разделы.

И так будет с каждым проприертар-телем прошивок. И каждого - по новостям возить об тейбле.

---Попупайте лоттерейные билеты либребута! А газ, свет и воду вам и так поотключают.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Михрютка , 02-Фев-16 22:20 
>> Чото боян, года 2-3 назад гнусмас уже имел проблемы индентичного характера. И
>> как раз когда очищались системные разделы.
> И так будет с каждым проприертар-телем прошивок. И каждого - по новостям
> возить об тейбле.
> ---Попупайте лоттерейные билеты либребута! А газ, свет и воду вам и так
> поотключают.

нефиг пользовать несертифицированный софт и железо без поддержки. проблема от этого никуда не денется, но это будет уже не ваша проблема.


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аркадий , 17-Янв-19 14:55 
Если в OS X 10.8.5 на 13-дюймовом MacBook Air 2012 года выпуска ввести в терминале sudo rm -rf /, может ли это повредить EFI? Мне нужно удалить раздел жесткого диска и установить Windows 8 в нераспределённое пространство, а перед этим снять видео по удалению OS X через терминал, чтобы выложить на YouTube, но главное - чтобы это не повредило EFI.

"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Michael Shigorin , 17-Янв-19 16:19 
> Мне нужно удалить раздел жесткого диска

Ну так и удаляйте _раздел_, а не содержимое файловой системы на нём.

PS: вот почему предпочитаю не смотреть подобные ролики на тытрубе -- вдруг там автор тоже придёт на форум сантехников с вопросами доставки пиццы в ночной клуб (и газовым патрубком в руках)...


"Выполнение rm -rf / может привести к неработоспособности UEF..."
Отправлено Аркадий , 17-Янв-19 21:35 
Человек, о ситуации которого статья, удалял файлы тоже перед плановой переразбивкой диска и, возможно, тоже снял видео.