И сейчас без особых сложностей принимает. Проблемы могут возникать из-за guid учетки, который некотоые программы любят тящить с собой. Еще между разными версиями винды нельзя простой подменой делать перенос (как межу 32 и 64 редакциями, так и между версиями Windows).
Там можно использовать параметр /f ALL. Он разместит оба типа загрузчиков, но это не гарантирует запуска. Как я уже писал, загрузчик до определенной стадии не воспринимает разметку GPT, а значит грузиться не будет.
Сам такое не делал, но может прокатить. Идея такая:
GRUB4DOS умеет затягивать в память образы дисков (простые, линейные) и эмулировать из него рамдиск, который на уровне BIOS будет восприниматься вполне себе нормальным диском. А уже раз есть такой диск, который MBR, то на нем и размещайте загрузочные данные от Windows.
Тут только я не вполне уверен, в какой момент загружается код, умеющий работать с gpt
Идея растет из того, что можно грузить Windows с GPT, если раздел загрузки находится на флешке (тот самый раздел на 100 мегов). Его можно сделать по этой статье.
Windows, при обнаружении валидной MBR (а у HybridGPT она валидная), проверять наличие gpt уже не будет.
Если же у он находит Protective MBR (специально сформированную заглушку, а HybridGPT кроме раздела заглушки, имеет еще и другие разделы, что не по стандарту, и соответствует валидной MBR), то ищет gpt.
Но это все ерунда, когда выясняется, что код загрузчика Windows, загружаясь в режиме MBR, полностью игнорит существование gpt. Естественно его не находит, и выпадает в осадок.
Костыль: разместить загрузочный раздел на флешке или эмулировать его в памяти (должен быть с разметкой MBR).
Все зависит от реализации самого UEFI, в каждом конкретном случае.
Обычно этого нет. Но если сильно захотеть, можно написать efi скрипт (надо впихнуть его до загрузки вашей ОС). И уже в скрипте, выставлять нужные переменные (какие нужны, смотреть опять индивидуально).
В целом, UEFI предоставляет возможности, схожие с *nix shell.
Распространяется в добровольно-принудительном порядке. Я бы не сказал, что UEFI невероятно лучше, чем BIOS. Задумка хорошая, а вот с реализацией не все гладко (тут, на Хабре, один товарищь очерь подробно разобрал многие проблемы)
Как правило, может. Но не редки ситуации, когда он запарывает BCD совсем.
С учетом не высокой сложности задачи, предпочитаю делать руками, контролируя все этапы.
Я думаю рассмотреть такие аспекты: сравнить скорость записи в тонкий том (и снапшоты тонкого/толстого тома) после выделения пространства в нем (надо заполнить его не нулевыми блоками, или отключить пропуск пустых блоков). Сравнить скорость mdadm raid 0/1 и аналогичных томов LVM2 (да, он такое сам умеет), посмотреть на автоматическое восстановление зеркального тома LVM. Посмотреть как работает том кэширования в LVM (в доках про него что-то писали). Обязательно сравнить скорость чтения (в этом тесте этого не было) и смешанный режим.
Ваши предложения еще?
Для масштабного тестирования, хотелось бы узнать, что именно вы бы хотели протестировать? Какой вид нагрузки надо создать? Ваши предложения по методике? В тесте смогут быть применены 4-е диска.
Да, диск был один. Свободных многодисковых конфигураций сейчас под рукой нет. Но по вашим просьбам, могу подготовить расширенное тестирование.
Есть один "старичек", его выведу из работы и могу устроить такой тест.
ZFS под Linux конечно хорошо. Но он еще не дорос до стадии промышленного применения. Память жрет вагонами. Связка LVM2+ext3/4 даст невысокое потребление памяти (что важно для программных интернет шлюзов на старых компах), приличную скорость и достаточное число полезных плюшек.
Как раз неверные данные для FRU (число вентиляторов) и приводит к их пострянной работе. На каждой мамке их нужно подключать не абы как, а в соответствии с задействованной схемой (она различна для различного числа вентиляторов). И система будет гонять вентиляторы на максимуме, если не обнаружит хотябы один, на определенном разьеме. Это аварийный режим работы, вдруг сдох основрой вентилятор протяжки? Включить все в максимум и терпеть до починки. Узнать на кого ругается система можно в логах самой материнки.
Если не ошибаюсь, то в /etc/nslcd.conf указывается учетка, которая имеет право просмотра ldap (считай любой пользователь). А потом, когда OpenVPN запрашивает пароль, у ldap спрашивают, корректна ли такая комбинация (от лица той самой учетки). Это абсолютно обычная практика. Иногда делают привязку к ldap проверяемой учеткой.
А почему нет? Распложением KickStart управляет inst.ks параметр.
А усложнять они особо и не стали. Раньше инсталятор искал установочные файлы не вполне очевидно, теперь это указывают явно. Больше всего поменялся сам образ. Это теперь немного (или сильно) хитрый iso (не проверял соответствию стандарту), но кроме всего, он содержит рабочую mbr и gpt, что делает процедуру записи образа однотипной для всех сценариев. Просто загнал на носитель и Ок. Кому надо, те расковыряют.
Спасибо за замечание, внес эти правки в статью.
Тема с настройкой правил вообще большая, поэтому все равно все тонкости не раскрою, тут уже кроме как самим изучать Shorewall (и обязательно и iptables) вариантов нет.
GRUB4DOS умеет затягивать в память образы дисков (простые, линейные) и эмулировать из него рамдиск, который на уровне BIOS будет восприниматься вполне себе нормальным диском. А уже раз есть такой диск, который MBR, то на нем и размещайте загрузочные данные от Windows.
Тут только я не вполне уверен, в какой момент загружается код, умеющий работать с gpt
Идея растет из того, что можно грузить Windows с GPT, если раздел загрузки находится на флешке (тот самый раздел на 100 мегов). Его можно сделать по этой статье.
Можно попробовать это сделать и на чистом GRUB\GRUB2.
Если же у он находит Protective MBR (специально сформированную заглушку, а HybridGPT кроме раздела заглушки, имеет еще и другие разделы, что не по стандарту, и соответствует валидной MBR), то ищет gpt.
Но это все ерунда, когда выясняется, что код загрузчика Windows, загружаясь в режиме MBR, полностью игнорит существование gpt. Естественно его не находит, и выпадает в осадок.
Костыль: разместить загрузочный раздел на флешке или эмулировать его в памяти (должен быть с разметкой MBR).
Обычно этого нет. Но если сильно захотеть, можно написать efi скрипт (надо впихнуть его до загрузки вашей ОС). И уже в скрипте, выставлять нужные переменные (какие нужны, смотреть опять индивидуально).
В целом, UEFI предоставляет возможности, схожие с *nix shell.
С учетом не высокой сложности задачи, предпочитаю делать руками, контролируя все этапы.
Ваши предложения еще?
Есть один "старичек", его выведу из работы и могу устроить такой тест.
Вам возможно подойдет такой вариант:
inst.ks=hd:LABEL=<метка раздела>:<полный путь к файлу на разделе>
А усложнять они особо и не стали. Раньше инсталятор искал установочные файлы не вполне очевидно, теперь это указывают явно. Больше всего поменялся сам образ. Это теперь немного (или сильно) хитрый iso (не проверял соответствию стандарту), но кроме всего, он содержит рабочую mbr и gpt, что делает процедуру записи образа однотипной для всех сценариев. Просто загнал на носитель и Ок. Кому надо, те расковыряют.
Тема с настройкой правил вообще большая, поэтому все равно все тонкости не раскрою, тут уже кроме как самим изучать Shorewall (и обязательно и iptables) вариантов нет.