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