Один из любознательных пользователей 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
Новость: http://www.opennet.dev/opennews/art.shtml?num=43795

• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 09:57 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,llolik, 10:08 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:16 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,фыв, 10:23 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:32 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Андрей, 11:48 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:07 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,Адекват, 15:04 , 01-Фев-16
                • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 22:56 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,анонанонанонанино, 13:14 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:57 , 01-Фев-16
                • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 22:40 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Elhana, 13:32 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,asd, 08:31 , 02-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:46 , 02-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности...,arisu, 13:29 , 02-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности...,Дегенератор, 18:49 , 02-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,torvn77, 21:35 , 03-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,skybon, 10:34 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Anonplus, 10:55 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:18 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,Адекват, 15:16 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:04 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,тоже Аноним, 13:40 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,Паша, 19:23 , 01-Фев-16
                • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 20:19 , 01-Фев-16
                  • Выполнение rm -rf / может привести к неработоспособности UEF...,asd, 08:33 , 02-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 00:55 , 02-Фев-16
                • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 03:35 , 02-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,владц, 22:42 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 06:56 , 02-Фев-16
                • Выполнение rm -rf / может привести к неработоспособности UEF...,Andrey Mitrofanov, 11:28 , 02-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Khariton, 11:04 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Андрей, 11:49 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Khariton, 13:43 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Нимано, 16:05 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,asd, 08:34 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:34 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,asd, 08:35 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,commiethebeastie, 10:35 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Anonplus, 10:46 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:15 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:33 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:01 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:06 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Anonplus, 11:02 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:21 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,SysA, 14:44 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,., 20:08 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,llolik, 12:02 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Ан2, 14:58 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,llolik, 15:03 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:15 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 18:19 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,demimurych, 18:32 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 07:04 , 02-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,asd, 08:36 , 02-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,antares0, 21:52 , 04-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Andrey Mitrofanov, 23:07 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 07:07 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 02:22 , 02-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,AlexYeCU_not_logged, 10:10 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:46 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Andrey Mitrofanov, 23:09 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:01 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,анонимус, 07:35 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,asd, 08:38 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,asd, 08:40 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,iPony, 10:55 , 02-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,анонимус, 14:36 , 03-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,asd, 08:15 , 07-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,anon7894, 12:41 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:02 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:07 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,фыв, 10:24 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:42 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Иван, 20:48 , 16-Янв-18
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:47 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Crazy Alex, 12:13 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:08 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:19 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:29 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:38 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:01 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Khariton, 11:09 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:24 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Khariton, 13:46 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Адекват, 07:23 , 02-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Khariton, 10:22 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:39 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:35 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:10 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Иван, 20:56 , 16-Янв-18
    • Выполнение rm -rf / может привести к неработоспособности UEF...,EuPhobos, 21:51 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 22:24 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 07:12 , 02-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 08:13 , 02-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 16:37 , 13-Фев-21
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:05 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,анонимус, 07:37 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Nicknnn, 10:16 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:11 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Альт, 14:55 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 01:17 , 02-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,asd, 08:56 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:18 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:21 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 18:25 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 20:45 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 21:05 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Andrey Mitrofanov, 23:14 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 08:16 , 02-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Адекват, 07:28 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности...,arisu, 13:25 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности...,Адекват, 15:21 , 02-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности...,arisu, 15:41 , 02-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности...,Аноним, 21:36 , 05-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:19 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:47 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:51 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 21:37 , 05-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,ryoken, 12:07 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:12 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:26 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:37 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:12 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:39 , 01-Фев-16
                • Выполнение rm -rf / может привести к неработоспособности UEF...,ZloySergant, 15:23 , 01-Фев-16
                  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:33 , 01-Фев-16
                    • Выполнение rm -rf / может привести к неработоспособности UEF...,Andrey Mitrofanov, 23:16 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Адекват, 07:47 , 02-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,derfenix, 17:01 , 02-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:49 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:15 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 20:24 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 01:29 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:21 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:25 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,derfenix, 17:02 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 07:53 , 03-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,anonimous, 10:21 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Anonplus, 10:48 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,анонимус вульгарис, 16:21 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:48 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,anonymous, 11:02 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности...,arisu, 12:25 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности...,Аноним, 18:26 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности...,Аноним, 19:27 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности...,Анонистый калий, 19:31 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Адекват, 07:58 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:22 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Maks, 10:22 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:32 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,КО, 10:38 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:43 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Другой аноним, 11:08 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Другой аноним, 11:10 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности...,arisu, 12:26 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности...,Аноним, 01:34 , 02-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:29 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Crazy Alex, 12:17 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:22 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности...,arisu, 12:29 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности...,анонанонанонанино, 13:26 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности...,Нимано, 16:32 , 01-Фев-16
                • Выполнение rm -rf / может привести к неработоспособности...,Адекват, 08:06 , 02-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности...,Аноним, 17:34 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 15:58 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Anonplus, 10:51 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Джедай, 12:02 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,ryoken, 12:09 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Crazy Alex, 14:40 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:13 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Stax, 17:39 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Нанобот, 10:27 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:29 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 01:45 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Led, 02:38 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 09:03 , 03-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Иван, 21:18 , 16-Янв-18
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 10:47 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Иван, 21:19 , 16-Янв-18
• Выполнение rm -rf / может привести к неработоспособности UEF...,lucentcode, 10:48 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:20 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:08 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:57 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 19:32 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Led, 23:57 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 01:49 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,анонимус вульгарис, 16:18 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 17:41 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,анонимус вульгарис, 19:40 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Crazy Alex, 12:18 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:00 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 19:33 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 01:57 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 04:01 , 02-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 04:06 , 02-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 07:59 , 03-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,Andrey Mitrofanov, 08:13 , 03-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:23 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Roo2AT7d, 11:33 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 02:02 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Roo2AT7d, 13:38 , 03-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:37 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Анонимо, 20:30 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:56 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:17 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:24 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,анонимус вульгарис, 19:37 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 19:34 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:34 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,DeadLoco, 18:47 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 19:35 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Анонимо, 20:32 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:40 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:40 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,RazrFalcon, 11:41 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Crazy Alex, 12:21 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:14 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:32 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:18 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,RazrFalcon, 12:05 , 03-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:19 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 11:55 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:39 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:54 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности...,arisu, 12:20 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности...,Аноним, 12:27 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности...,arisu, 12:40 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности...,Анонимо, 20:34 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности...,arisu, 21:50 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,AlexYeCu_not_logged, 12:23 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:29 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,narical, 13:18 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:19 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 02:17 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 04:11 , 02-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Andrey Mitrofanov, 11:43 , 02-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:26 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности...,arisu, 12:23 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:40 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности...,arisu, 12:42 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 02:18 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:00 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:26 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 02:21 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:09 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 02:22 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,CodeRush, 13:16 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 13:27 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,CodeRush, 13:37 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:30 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,CodeRush, 14:45 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Crazy Alex, 14:37 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,CodeRush, 14:59 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности...,arisu, 15:02 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности...,CodeRush, 15:10 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности...,arisu, 15:17 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности...,CodeRush, 15:27 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности...,Аноним, 17:30 , 01-Фев-16
                • Выполнение rm -rf / может привести к неработоспособности...,Crazy Alex, 17:34 , 01-Фев-16
                  • Выполнение rm -rf / может привести к неработоспособности...,CodeRush, 17:53 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности...,Иван, 21:47 , 16-Янв-18
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Crazy Alex, 17:46 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,CodeRush, 18:04 , 01-Фев-16
          • Выполнение rm -rf / может привести к неработоспособности UEF...,vi, 21:28 , 01-Фев-16
            • Выполнение rm -rf / может привести к неработоспособности UEF...,CodeRush, 22:02 , 01-Фев-16
              • Выполнение rm -rf / может привести к неработоспособности UEF...,vi, 22:17 , 01-Фев-16
                • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 00:31 , 02-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,XoRe, 17:39 , 03-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,НяшМяш, 13:20 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:27 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:29 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:18 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:50 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Михрютка, 13:57 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:07 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:19 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:43 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:46 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,цупцпцуп, 19:17 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Led, 00:03 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:45 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 08:27 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:49 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 02:42 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:51 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности...,arisu, 14:54 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности...,Аноним, 15:47 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности...,arisu, 15:55 , 01-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности...,Аноним, 21:01 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 15:13 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,IMHO, 17:48 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 14:53 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 19:17 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 15:12 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,анонимус вульгарис, 16:08 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,клоун, 16:21 , 01-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,анонимус вульгарис, 19:24 , 01-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Адекват, 15:33 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:46 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Нимано, 19:08 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,vi, 21:40 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,twiroh5r6hw, 02:25 , 05-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Daemon, 16:36 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 22:27 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Led, 00:10 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 16:59 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 13:37 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 00:06 , 03-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 17:44 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:39 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:55 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 08:08 , 03-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Andrey Mitrofanov, 08:15 , 03-Фев-16
        • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:41 , 03-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:59 , 03-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:23 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,тоже Аноним, 21:34 , 01-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 12:42 , 03-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,AlexAT, 22:18 , 01-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 18:56 , 03-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 01:28 , 02-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Нимано, 01:48 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аноним, 02:21 , 02-Фев-16
      • Выполнение rm -rf / может привести к неработоспособности UEF...,Михрютка, 22:18 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,bOOster, 11:18 , 02-Фев-16
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Andrey Mitrofanov, 11:53 , 02-Фев-16
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Михрютка, 22:20 , 02-Фев-16
• Выполнение rm -rf / может привести к неработоспособности UEF...,Аркадий, 14:55 , 17-Янв-19
  • Выполнение rm -rf / может привести к неработоспособности UEF...,Michael Shigorin, 16:19 , 17-Янв-19
    • Выполнение rm -rf / может привести к неработоспособности UEF...,Аркадий, 21:35 , 17-Янв-19

типичный поттеринг

А что он сказал не так?
Если UEFI у некоторых производителей работает не так, как ему положено работать в спецификации (сбрасываться к заводским настройкам), а поступить по другому нельзя (будут проблемы с GRUB, например), то что прикажете делать?

Железо оно первично. Если в железе ошибка значит надо обходить эту ошибку. Если железо можно повредить из-за ошибки в железе, значит надо обходить эту ошибку. Очевидно же.

Вы серьёзно?
Первичны стандарты.
Правильно будет устранять ПРИЧИНУ ошибки, а не обходить заботливо наставленные "производителями" грабли, являющиеся СЛЕДСТВИЕМ их наплевательского отношения к СТАНДАРТАМ.

Охладись, юноша, и добро пожаловать в реальный мир.

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

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

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

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

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

Я хоть и не являюсь пользователем systemd (честно погонял 2 месяца, но душа так и не приняла :) ), но считаю, что Поттеринг прав. Стандарты надо соблюдать...

> Стандарты надо соблюдать...

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

> Можно, конечно, стоять рядом с Леней с транспарантом

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

Шокер пригодится - когда ноутбук закирпичится, ты сможешь устроить наглядное шоу для MSI и Intel чего заслуживает их техника.

FHS тоже стпандарт, но на него поклали...

Он странный довольно.

А uefi что, не странный?

Да никто не спорит что надо соблюдать. И тот же Линус тоже бы материл производителя, но при это реакция у него почти наверняка была бы не gtfo, а какое-то решение как пользователя от этого оградить. А поттеринг на любую проблему отвечает что это не его проблемы.

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

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

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

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

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

> я далеко уже не юноша

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

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

Однозначно лайкаю!

>Правильно-то правильно, но как это реалистично сделать?

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

Чувак, можешь сколько угодно заниматься моногамией с бородатыми дядьками в комитетах, но мы живём в РЕАЛЬНОМ мире. Если в этом мире насрать на "стандарт", то этот "стандарт" - филькина грамота. А ПО пишется под ЖЕЛЕЗО, а не "как правильно". Так что с морализаторством - за дверь.

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

сам то понял что сказал?
какие ещё системд-хейтеры? те кто твою любимую программу не любят что ли? а должны?

> сам то понял что сказал?
> какие ещё системд-хейтеры? те кто твою любимую программу не любят что ли?
> а должны?

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

> Признать, что стандарты рулят = оправдать Поттеринга в этом случае.

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

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

К истоку рек возвращаются вновь их воды...

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

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

> Что за странная логика? Если сделано как в стандарте

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

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

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

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

Михаил, несомненно. Стандарты постепенно должны дорабатываться, конечно же.

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

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

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

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

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

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

Никакой веской причины держать  efivarfs по умолчанию в rw нет, безотносительно того, в порядке ли прошивка

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

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

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

Так проблема не в железе, а в софте к нему...)))

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

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

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

>> Так проблема не в железе, а в софте к нему...)))
>> Или вы считаете что если производитель напишет свое толкование ацпи-запросов но для
>> одной ОС в своих драйверах он их правильно растолкует, то если
>> данные ацпи-запросы не верно обрабатываются в другой ОС, то виновата другая
>> ОС?
>> )))
> Асер вроде пару лет назад отхватил уже за кривые ACPI таблицы для
> linux'а?

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

> заботливо наставленные "производителями" грабли, являющиеся СЛЕДСТВИЕМ их наплевательского отношения к СТАНДАРТАМ

Дык, традиция же! Достаточно глянуть в загрузчики 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 код, с костялями специально под них – жив!

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

Вот именно это я и имел в виду.

А это и не ошибка в железе.

Я уже писал выше. С моей точки зрения, тут неважно, в железе или в софте ошибка. Важно, что это ошибка производителя.

>Железо оно первично.

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

Теперь вспомним историю, когда установка линукса на определённые модели ноутбуков Самсунг приводила к их окирпичиванию (тоже затирались настройки NVRAM).

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

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

Нет.
Типичный Линус живет в реальном мире, в отличие от. В этом суть проблемы.

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

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

Я это понял. Отличие между Линусом и Леней в том, что первый - инженер и подходит к таким вопросам как инженер, принимая патчи для обхода железных косяков, а второй - безответственный хипстер, скачущий на розовом единороге по радуге.

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

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

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

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

> Железо оно первично. Если в железе ошибка значит надо обходить эту ошибку.
> Если железо можно повредить из-за ошибки в железе, значит надо обходить
> эту ошибку. Очевидно же.

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

и как ты будешь это фиксить? не только в будущих релизах но и в прошлых.

> и как ты будешь это фиксить? не только в будущих релизах но
> и в прошлых.

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

А то что это только юзер может сделать, причём для него это "black fu***ng magic!" говоря по олбански, - это тебя совсем не смущает?

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

> Железо оно первично. Если в железе ошибка значит надо обходить эту ошибку.

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

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

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

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

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

учить конфигуратор grub перемонтировать с ro на rw и обратно.
Если в gnu/linux простая, случайно запущенная команда способна убить железо, то это проблема gnu/linux.

> учить конфигуратор grub перемонтировать с ro на rw и обратно.

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

Угу. Если самолет падает потому что инженеры допустили ошибку в разработке самолета, то это конечно проблема пилота.

Это проблема пилота, потому что инженеры на земле, а пилот упадёт вместе с самолётом.

Конечно. А вот драть как сидоровых коз надо (и будут) инженеров.

> Угу. Если самолет падает потому что инженеры допустили ошибку в разработке самолета,
> то это конечно проблема пилота.

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

> учить конфигуратор grub перемонтировать с ro на rw и обратно.
> Если в gnu/linux простая, случайно запущенная команда способна убить железо, то это
> проблема gnu/linux.

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

Недалекие ненависники не понимают что проблема не зависит от системы инициализации.

А потом эти же люди булькают, что во фре при извлечении флешки без отмонтирования паника.

Впервые в жизни заступаюсь для Поттеринга: типичный uefi.

два чая Вам - на той же модели ноутбука, даже в легаси, граб работает только если установлен в отдельный ext2 раздел

> Впервые в жизни заступаюсь для Поттеринга: типичный uefi.

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

> типичный поттеринг

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

Все правильно анон выше говорил. Виноват разраб железа кладущий на стандарты, и пользователи которые теоретически умеют в доступ к uefi теперь задумаются насчет покупки msi. Репутация производителя, хоть и у 1% будет потеряна а остальных не особо интересует что там с конфигами загрузчика.

В мой блэклист уже давно входят как MSI с ACER, так и SAMSUNG, SONY и ряд других. Просто принципиально не покупаю.

Имею в виду - не только сам не покупаю, но и других предостерегаю. В том числе клиентов - а там уже не один-два предмета покупается )). Ибо нефиг.
ЗЫ. Если бы таких как я было бы существенная чифра, производители сильно по другому относились бы как к стандартам, так и к клиентам-покупателям. Мечты...

В том то и бида, что белый состоит около из одного элемента 🍎

У меня там асусы.

Кстати, да, с ними засад меньше.

<cap mode> Выполнение rm -rf / может привести к неработоспособности Linux </cap mode>

а ведь разработчики systemd всё верно ответили

Да нет. Люди-то работают с тем что есть. Если в UEFI ошибка надо работать с оглядкой на эту ошибку, а не говорить что это не моё дело.

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

Много ты по пинал производителя по поводу кривых ACPI?

> Много ты по пинал производителя по поводу кривых ACPI?

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

надо допиливать коребут, ибо пинать производителя бесполезно - невидия тому пример

Пинать - надо. Обходить баг - тоже надо.

> Надо пинать производителя.

Надо.

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

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

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

Завтра будет ошибка в 0.001% прошивок от [brand] в которой при выполнении некоторой последовательности операций процессора будет происходить зависание системы, на это тоже надо будет закладываться?

> Завтра будет ошибка в 0.001% прошивок от [brand] в которой при выполнении
> некоторой последовательности операций процессора будет происходить зависание системы,
> на это тоже надо будет закладываться?

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

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

Слишком старое, есть посвежее фейлы и более трудноуловимые:
http://www.computerra.ru/138414/intel-skylake-cpu-bugs/

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

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

> Да нет. Люди-то работают с тем что есть. Если в UEFI ошибка
> надо работать с оглядкой на эту ошибку, а не говорить что
> это не моё дело.

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

не думаю что запрет перезаписи переменных UEFI можно использовать как фичу

> не думаю что запрет перезаписи переменных UEFI можно использовать как фичу

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

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

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

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

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

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

В любом ПО есть workaroud, как это есть с чипсетами nVidia, Radeon r6xx/r7xx. Например работа USB контроллеров

Вот зачем ты об этом сказал? Аноны теперь спать не смогут, пока не добьются от Линукса и Ко исключения из кода ядра _всех_ воркэраундов. Ведь ошибки в железе это не проблема гну/линукса!

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

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

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

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

Ну тогда уж до кучи давайте обвиним и mount, то что монтирует впринципе эту ФС, ну и за одно и rm обвиним, что нет ключа "rm -rf --but-not-my-uefi --pleeeease /"

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

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

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

Upstart как монтирует? Openrc? Init.d?

Upstart и init.d в rw.

Может тогда лучше пнуть Поттеринга не за то, что он захардкожил rw в systemd, а за то, что он изобрел велосипед вместо использования fstab?

Как всегда - никто не при делах, и как хотите так сами и справляйтесь. И не важно, заплатил ты за это деньги (ноутбук MSI), или это открытый код (systemd).

Виноват msi, не благодари.

Обычный вброс. Причем тут systemd к efivars являющейся частью ядра? Ну и что, что он это монтирует. Он ведь монтирует и всё остальное.

> Причем тут systemd

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

Ну понятно, что не альт.

> Ну понятно, что не альт.

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

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

Вот почему никогда не будет никакого системдэ ни на одном компьютере под моим управлением.

Та же проблема будет в init.d и в upstart. Но такому как ты это не понять.

> Та же проблема будет в init.d

В где?

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

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

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

Я решил проверить, что там у труюниксвэй и не самодеятельной системы инициализации с монтированием sysfs и установил slackware. А там тоже rw.

И в alt linux rw.

> Я решил проверить, что там у труюниксвэй и не самодеятельной системы инициализации
> с монтированием sysfs и установил slackware. А там тоже rw.

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

# rm -rf /sys <ENTER>

Содержимое efivars можно удалить.

> Вот почему никогда не будет никакого системдэ ни на одном компьютере под
> моим управлением.

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

> все ментейнеры

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

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

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

да.

арису мэйнтэйнит libastral у линуса.

В комментариях к данной новости выясняется, что ненависть к поттерингу перевешивает даже косяки кривых uefi в ноутбуках msi.

В опенврт загрузчик по умолчанию открыт на запись и можно окирпичить устройство. Правда поттеринг не умеет отношения к опенврт.

>поттеринг не имеет отношения к опенврт

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

саечка чингисхана.
апперкот жаботинского.

> Правда поттеринг не умеет отношения к опенврт.

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

Если бы поттеринг имел отношение к опенврт, то возможно в опенврт было бы поменьше гвоздей и костылей.

>гвоздей и костылей

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

Очевидно, что ты со мной не согласишься, но системд тоже превосходно работает. Так работает, как скриптовым костылям не снилось. Правда это сложно доказать пользователям десктопов и админам локалхоста.
Опенвртшная магия это то, что осложняет её использование в продакшне.

> Так работает, как скриптовым костылям не снилось. Правда это сложно доказать
> пользователям десктопов и админам локалхоста.

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

Не опенсорсно как-то.

>Не опенсорсно как-то.

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

Так опенсорс это метод мышления.

> Так опенсорс это метод мышления.

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

> Очевидно, что ты со мной не согласишься, но системд тоже превосходно работает.
> Так работает, как скриптовым костылям не снилось. Правда это сложно доказать
> пользователям десктопов и админам локалхоста.

Ну ты попробуй, давай докажи преимущества 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" можно же найти, да ?

Перевожу:

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

Кусок Божественного rc.conf из старого Арча детектеД!

Нет. Закрыт. А чтобы был открыт, нужно специально патчить.

На разных устройствах по разному на самом деле.

> В комментариях к данной новости выясняется, что ненависть к поттерингу перевешивает даже
> косяки кривых uefi в ноутбуках msi.

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

Из серии "Хакер в столовой".

случайно ошибся в наборе команд и получил кирпич вместо ноутбука. Обычная ситуация. Каждый кто хоть изредка удаляет каталог с помощью rm может в ней оказаться.

> случайно ошибся в наборе команд и получил кирпич вместо ноутбука. Обычная ситуация.
> Каждый кто хоть изредка удаляет каталог с помощью rm может в
> ней оказаться.

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

Пытаешься прикинуться шлангом? rm ~/tmp /* отлично работает без всяких

Так это, ноутбук-то в он итоге как-то смог восстановить?

> Так это, ноутбук-то в он итоге как-то смог восстановить?

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

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

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

писал с брата

отправил на ремонт по гарантии https://bbs.archlinux.org/viewtopic.php?pid=1599733#p1599733

> Так это, ноутбук-то в он итоге как-то смог восстановить?

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

почему?

Тупой вопрос, ну ладно отвечу. Инструкцию ниасилил от бука где сказано как восстанавливать и прошивать UEFI.

Потому что нефиг было что-либо ломать.

> Так это, ноутбук-то в он итоге как-то смог восстановить?

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

Ваш компьютер в безопасности, когда не работает. Профессиональная защита компьютеров от включения. Звоните!

А что,на системе без systemd эта операция невозможна?

Возможна.

Ну, наверное, не на системД можно указать как монтировать ту или иную систему. А системД монтирует некоторые на свой вкус.

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

>А системД монтирует некоторые на свой вкус.

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

Не совсем верно. Запись в fstab необязательная. Modprobe efivars при условии загрузки в режиме uefi - и мы имеем подпор типов Анны раздел в sysfs. А модуль то может загрузить кто угодно по сути... Т.е. как ни круто - Лёня тут получается не при делах. Ну и по сути он прав. Хотя ситуация конечно сборная и сложная... Я с этим только вчера плотно столкнулся и не думал, что там есть какие-то важные настройки, удаление которых может окирпичить комп

> Не совсем верно. Запись в fstab необязательная. Modprobe efivars при условии загрузки
> в режиме uefi - и мы имеем подмонтированный раздел
> в sysfs. А модуль то может загрузить кто угодно по сути...
> Т.е. как ни круто - Лёня тут получается не при делах.
> Ну и по сути он прав. Хотя ситуация конечно сборная и
> сложная... Я с этим только вчера плотно столкнулся и не думал,
> что там есть какие-то важные настройки, удаление которых может окирпичить комп

Долбанный т9

> Долбанный т9

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

>> Долбанный т9
> «подпор типов Анны» был круче.

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

Возможно она необязательная, но учитывается — https://github.com/systemd/systemd/issues/2402 .

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

Малой кровью здесь является монтирование в ро о чём должны позаботиться мейнтейнеры дистрибутива.

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

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

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

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

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

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

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

> (см. 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% десктопов, никогда, увы.
Заметьте - человек не поленился что-то вроде баг-репорта написать, иначе вы бы не узанли бы об этой проблеме.
На его месте мог кто-то из вас оказаться или ваших родственников, или вы могли так угробить чей-то ноут и попасть на бабки :)

Ты так и не понял что произошло.. Вместе с этой багой root получил права не только убить данные на носителях, но и само железо. Такое уже бывало многократно. И каждый раз в ядро или юзерспейс внедряли новую распорку, которая не давала root-у ломать железо. А тут по твоей логике какой-то особый случай. Странно слышать такое от тебя, arisu. Ты же в курсе насколько root в Linux ограничен в своих возможностях?

> Ни хрена он по сути не прав. Если ты можешь прикрыть пользователя
> малой кровью от проблемы, которую не он создаёт - надо прикрывать.
> Мата в адрес MSI это не отменяет, конечно. А то, что
> он несёт - это его обычная безответственность.

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

> Ну, наверное, не на системД можно указать как монтировать ту или иную
> систему. А системД монтирует некоторые на свой вкус.

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

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

Потому что гладиолус

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

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

Ну вот пусть они и монтируют. И отмонтируют после работы. Не самая частая операция, как ни крути.

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

efibootmgr(8)

Для полноты картины стоит упомянуть еще grub-install на uefi (хотя почти наверняка он сводится к копированию файлов + вызову efibootmgr)

вполне аргументированый отказ разрабов

Арчеводы самые любознательные.

> Арчеводы самые любознательные.

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

>> Арчеводы самые любознательные.
> Это от того, что у них лучшая документация в сети.

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

Лучшая документация у rhel.

> Лучшая документация у rhel.

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

все вполне логично если я грохнул efivars то с какого они должны сбрасыватся по дефолту? Я ведь их стер.

> все вполне логично если я грохнул efivars то с какого они должны
> сбрасыватся по дефолту? Я ведь их стер.

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

Лёнчик дело говорит - проблемы кривых разрабов MSI его волновать не должны. Пусть свои косяки они за собой сами поправляют. Тем более, что проблема похоже у них не связана с железом - это косяк самой прошивки UEFI.

Разработчики у MSI вполне себе адекватные и баги в UEFI фиксят хоть и не быстро.

А ещё кривых разрабов Гигабайтов (там такая же херня), а ещё мало ли каких кривых разрабов.

надо было брать макбук

> надо было брать макбук

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

> надо было брать макбук

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

>> надо было брать макбук
> А попа не слипнется?

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

> А ещё кривых разрабов Гигабайтов (там такая же херня), а ещё мало
> ли каких кривых разрабов.

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

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

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

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

Его должны бы волновать проблемы пользователей. Но - увы...

Самое удивительное в новости то, что парень поставил арч с уефи ))

> Самое удивительное в новости то, что парень поставил арч с уефи ))

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

>> Самое удивительное в новости то, что парень поставил арч с уефи ))
> Мудрила чудный

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

Почему минус? Потому что я среди идиотов?

> Почему минус? Потому что я среди идиотов?

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

Рейтинг: -30295 баллов

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

> Рейтинг: -30295 баллов
> бгг, каанешна "ничего не значит", у-тю-тю

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

А зачем вообще нужен этот уродский UEFI? Производители на пустом месте зачем-то придумали проблем всем пользователям. Никаких преимуществ тем же пользователям оно не даёт.

Это как с системд: на 2 секунды быстрее включается устройство

> Это как с системд: на 2 секунды быстрее включается устройство

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

В новости про UEFI явно имеется ввиду холодный старт, к тому же многое упирается в io.

Конечно не нужен, давайте пользоваться сороколетним биосом подпёртым костылями со всех сторон, лишь бы он работал с современным железом.

UEFI наверное без костылей? Что-то ему это не помогло.

например, с EFI чтобы сделать загрузочную флешку, не нужны никакие dd и unetbootin - достаточно распаковать на нее образ с дистром. Есть efi shell, из которой можно загрузить ядро с нужными параметрами. Ну и secure boot - кто бы что ни говорил, но если есть возможность управлять ключами, то это очень полезная штука.

> например, с EFI чтобы сделать загрузочную флешку, не нужны никакие dd и
> unetbootin - достаточно распаковать на нее образ с дистром.

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

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

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

Так трудно написать dd?

> например, с 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

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

> А зачем вообще нужен этот уродский UEFI? Производители на пустом месте зачем-то
> придумали проблем всем пользователям. Никаких преимуществ тем же пользователям оно не
> даёт.

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

Еще один факт почему уефи нинужен. Слишком уж навороченный.

Ну, почему же? Очень даже нужен. Например, можно незаметно для юзера грузить баребоновый гипервизор, затем юзерскую ОС, и еще втихаря свои хитрые штучки, которые будут перехватывать все-все - от сетевых пакетов до клавиатурного ввода и отпечатков пальцев со сканера. Круто же!

> Ну, почему же? Очень даже нужен. Например, можно незаметно для юзера грузить
> баребоновый гипервизор, затем юзерскую ОС, и еще втихаря свои хитрые штучки,
> которые будут перехватывать все-все - от сетевых пакетов до клавиатурного ввода
> и отпечатков пальцев со сканера. Круто же!

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

расскажи это Сноудену

самое главное что так смонтировали ребята из арча, а виноват все равно systemd

Имхо, поттеринг не прав, т.к. В любом ПО есть workaroud, как это есть с чипсетами nVidia, Radeon r6xx/r7xx. Например работа USB контроллеров.
ИМХО, слабый аргумент, что бы это игнорировать.

В Gentoo без systemd вообще efi не монтируется. Зачем он нужен, да еще и в режиме rw - непонятно.

Вот именно. Те полторы утилиты, которым он нужен, вполне могут сами его смотировать, сделать что надо и размонтировать обратно. Как по мне, кстати, то же самое и к /boot относится.

> Вот именно. Те полторы утилиты, которым он нужен, вполне могут сами его
> смотировать, сделать что надо и размонтировать обратно. Как по мне, кстати,
> то же самое и к /boot относится.

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

'it should be mounted through the sysfs init script'
https://wiki.gentoo.org/wiki/Efibootmgr

> В Gentoo без systemd вообще efi не монтируется.

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

Странно, еще пару лет назад нужно было efivars самому подгружать, а теперь он грузится сам. Видимо что-то поменялось.
Тем не менее /sys/firmware/efi/efivars пустой.

> В Gentoo без systemd вообще efi не монтируется. Зачем он нужен, да
> еще и в режиме rw - непонятно.

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

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

https://twitter.com/mjg59/status/693494314941288448
Жду оправданий поттеринг-хейтеров.

Кого-кого? Нет таких людей, вы сами их выдумали.

Прям библейское "подставь свою жoпy"

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

Просто новость жёлтая. Объективное обсуждение проблемы было бы с заголовком 'rm -rf / под рутом убивает некоторые реализации uefi'.

а если ещё точнее, то: «некоторые реализации уефы не могут в emergency recovery mode».

> а если ещё точнее, то: «некоторые реализации уефы не могут в emergency
> recovery mode».

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

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

Кстати, а что будет с матплатой, если винт с уефишным разделом тупо сдохнет?
Там вообще чтоли никаких "настроек по умолчанию" нет? Сдох винт, плата окирпичилась?
Из-за чего такой шум-то?

Новый уровень понимания ситуации в треде.

Ничего не будет. Винт не имеет никакого отношения к работоспособности UEFI. Учи матчасть.

> Там вообще чтоли никаких "настроек по умолчанию" нет? Сдох винт, плата окирпичилась?

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

>> Там вообще чтоли никаких "настроек по умолчанию" нет? Сдох винт, плата окирпичилась?
> Не-а.  См. http://www.rodsbooks.com/efi-bootloaders/ по порядку, если интересно.

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

>>> Там вообще чтоли никаких "настроек по умолчанию" нет? Сдох винт, плата окирпичилась?
>> Не-а.  См. http://www.rodsbooks.com/efi-bootloaders/ по порядку, если интересно.
> Туманно дал туманную ссылку Шигорин, сам, видимо, нимуя не понимая.

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

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

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

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

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

Всё будет нормально, этот раздел не на винте, а облаке(яндекс диск).

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

Лишь бы поср@ться. Собрались бы разрабы systemd вместе с разработчиками ядра, по возможности пригласили бы разработчиков железа. Обсудили бы как выйти из ситуации. Важен конечный продукт. Умение выходить из кризисных ситуаций - вот что должно характеризовать разработчиков как хороших, а не огрызание и показывание пальцем.

выйди, пожалуйста. вон из дверей.

Но вместо них, как всегда, срётся опнетик ;)

Эту директорию необходимо монтировать к ro, как какой-нибудь DVD-ROM или Floppy с защёлкнутым окошком.

Её можно запросто перемонтировать. Это костыль.

> Эту директорию необходимо монтировать к ro, как какой-нибудь DVD-ROM или Floppy с
> защёлкнутым окошком.

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

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

> На лоре написали, что виновным себя признал гаретый феминист

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

Раз уж меня сюда позвали, выскажусь и по этой проблеме. Для начала, 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-чипе так никто реализовать не смог - может быть, дело не в людях, а проблемы в консерватории?..

Спасибо за рассказ, хорошо бы им дополнить новость, если не против.

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

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

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

> С моей точки зрения, если нужно что-то крутить из внутренностей прошивки - для этого специально предназначен UEFI Shell

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

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

Как мнение пользователя/программиста/в прошлом админа - чем меньше специализированных сред - тем лучше. Я хочу при решении задач иметь привычный набор инструментов - от скриптов до доступа из сети, причём всё это - стандартным для моей инфраструктуры образом. В этом плане идея закрыть к чему-либо доступ из ОС мне не нравится совершенно.

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

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

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

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

> Альтернативу предложите для нынешних платформ?

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

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

Скажите пожалуйста, прошивки чего вы разрабатываете (ну чтоб случайно не купить) ?

Присоединяюсь к вопросу.

Случайно вы их все равно не купите, это промышленные платы congatec в форм-факторе COM-Express и QSeven.

> Альтернативу предложите для нынешних платформ?

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

Позиция ясна. У меня она несколько другая:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OverlayFS

> OverlayFS

В чипе?

А если просто ввести sysctl параметр, что-то типа a.b.c.rw = 1?
По умолчанию, естественно, сделать rw = 0.
Если кому нужно обновить что-то, у них будет простой способ:
sysctl a.b.c.rw = 1
update
sysctl a.b.c.rw = 0
И все.

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

Может как-то обезопасить файлы от удаления?
1 Почему нельзя делать что-то типа echo "uefi suka command" /sys/uefi/pipe
2 Зачем вообще нужен этот католог и как он используется?
3 Разделить католог на безопасную часть которую можно редактировать (настройки бута) и другую.

Вот за что не люблю uefi. Мало того что написали кучу костылей типа править параметры мышкой, залочить устройство от его хозяина, так ещё и +100500 способов прострелить ногу.

Да, к uefi c secureboot скоро понадобятся кряки чтобы только загружать Linux (и пиратскую винду). Людей уже приучают на смартфонах что типа нормально когда нельзя просто загрузиться или просто воспользоваться root.
"Рутование" - слово то какое мерзкое.
Это uefi с одной стороны раздутая, а с другой в ней нет многих вещей.
И Secure Boot не защищает от вторжения, а только от пользователя. Ей не нужны были ключи, она должна была делать контрольные суммы например предупреждая о запуске того чему я ещё не доверяю.

- Доктор, у меня болит, когда я делаю вот так.
- Не делайте так больше.

вроде ж ходили уже по этим граблям?

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

rm -rf / --no-preserve-root --no-preserve-uefi-mountpoint --disable-confirmation-dialog-and-crack-computer-with-unpossibilities-of-restoring
# простите за мой диалект.

"пользователь решил понаблюдать как поведёт себя система в случае выполнения "rm -rf /", после чего ноутбук пришёл в неработоспособное состояние и перестал подавать признаки жизни"

Я РЖАЛ)

Я тоже делал это и один раз случайно. Прочитал про опцию --no-preserve-root и стало интересно будет ли она запрошена при пути /* вместо '/' Оказалось не будет и я удалил всё что есть на компьютере.  

> Я РЖАЛ)

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

>> Я РЖАЛ)
> Проблема не в том, что ноутбук перестал подавать признаки жизни.
> Проблема в том, что на него теперь даже установить другую операционку нельзя.

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

> "пользователь решил понаблюдать как поведёт себя система в случае выполнения "rm -rf
> /", после чего ноутбук пришёл в неработоспособное состояние и перестал подавать
> признаки жизни"
> Я РЖАЛ)

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

Итак, Вы решили прострелить себе ногу (версия для систем инициализации).
sysv init: Вы успешно простреливаете себе ногу из старого дедовского дробовика.
systemd: Вы наводите прицел современной высокотехнологичной снайперской винтовки на свою ногу, но пуля попадает Вам в голову.

> systemd: Вы наводите прицел современной высокотехнологичной снайперской винтовки

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

А кто-нибудь проверял, что будет, если выполнить

rm -rf /proc /sys

?

> А кто-нибудь проверял, что будет, если выполнить
> rm -rf /proc /sys
> ?

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

А мне не верили на лоре, когда у меня такая же проблема была. Мда. А про какого-то придурка щас даже на опеннете новость. Круто, ага.

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

Да, ещё я знаю, что такие же есть и тут. Например, ты.

это да. куда мне до гениев, сносящих всё рекурсивно с корня под рутом!

я так и не понял, а просто создать новую fs на диске не судьба?

Потому что ты писал про свою проблемы на лоре, а "придурок" на форуме арча. Отсюда и  разный результат.

> А мне не верили на лоре

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

Чувак, конечно, лох, но будь у него не MSI, проблем с восстановлением не было бы. А MSI без программатора не чинится.

> Чувак, конечно, лох, но будь у него не MSI, проблем с восстановлением
> не было бы. А MSI без программатора не чинится.

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

То странное чувство, когда комментарии на опеннет адекватней комментариев на хакерньюс.

Если программа может непоправимо повредить оборудование, это баг оборудования.

Нет, это значит, что есть две ошибки. И ни одна из них не оправдывает другую.

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

Согласен, ошибок в данном случае две. Одну из них допустили разработчики EFI, другую — юзер.

Линуксойды должны страдать.

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. Теперь видно что линукс МОЖЕТ угандоишить железо, как мило, ми-ми-ми :))

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

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

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

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

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

>линуксоЙды

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

Потестил на слаке - все норм. Просто руки дошли оффтоп поставить по нужде...

Там так же sysfs монтируется в rw.

> Просто руки дошли оффтоп поставить по нужде...

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

Кстати, а системд можно настроить так, чтобы эта байда вообще не монтировалась, ни в ro, ни в rw?

> Кстати, а системд можно настроить так, чтобы эта байда вообще не монтировалась,
> ни в ro, ни в rw?

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

Может проще в блэклист внести?

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

Очевидно же что на некоторые новости на opennet.ru приходят тролли (оплачиваемые так или иначе) для задания определённого тона в обсуждении новости.

Не прослеживаю такой очевидной зависимости.

Ну давайте профы, что-ли, интересно почитать. В идеале - зарплатную ведомость.

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

> Ну давайте профы, что-ли, интересно почитать. В идеале - зарплатную ведомость.
> А то, раз мы тут родину продаём, вдруг недоплачивают?

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

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

У чем дурность новости? В том что большому количеству людей показали/напомнили что надо перемонтировать efivars в ro после установки и настройки загрузчика?

Всегда считал что BIOS это программа которая мешает работать OS. UEFI как дитя BIOS только ухудшила ситуацию.

Берешь пассатижи, выдергиваешь микросхему из платы - и ничего твоей ОС больше не мешает!

Берешь пассатижи, выдергиваешь себе яйцы - и ничего твоей смене ориентации больше не мешает!

Итого режим работы UEFI/BIOS в личной практике оказывался переключенным на BIOS на 99% серверов и пк/нб. Впрочем, желающие жевать кактусы могут жевать мсявное поделие дальше.

если он есть. Если работает.

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

> один себе крайне удачно в ногу выстрелил, другие зажопились вменяемо ответить на
> вопрос "на кой вам 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.

я ведь сформулировал вопрос - "на кой". т.е. - "зачем", а не "кому". вот зачем это надо делать именно так? какой юзкейс и частота применения этого финта ушами?

ну например мне нужно загрузить систему с другого девайса. one off или постоянно.

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

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

Чото боян, года 2-3 назад гнусмас уже имел проблемы индентичного характера. И как раз когда очищались системные разделы.

> Чото боян, года 2-3 назад гнусмас уже имел проблемы индентичного характера. И
> как раз когда очищались системные разделы.

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

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

>> Чото боян, года 2-3 назад гнусмас уже имел проблемы индентичного характера. И
>> как раз когда очищались системные разделы.
> И так будет с каждым проприертар-телем прошивок. И каждого - по новостям
> возить об тейбле.
> ---Попупайте лоттерейные билеты либребута! А газ, свет и воду вам и так
> поотключают.

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

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

> Мне нужно удалить раздел жесткого диска

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

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

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