Comments 51
Ну вроде как почти всё по арчвики, один только вопрос — для чего здесь grub? Просто чтобы не класть «ядро и initramfs на /dev/vda1» (т.е. чтобы только часть /boot была незашифрована как у вас, а не весь с ядрами)? Есть какой-то сакральный смысл, оправдывающий использование grub-а в 2018 году в этой схеме?
з.ы. ну и жаль что secure boot упущен, это как раз непростая и местами мутная тема, а очень важная.
з.ы. ну и жаль что secure boot упущен, это как раз непростая и местами мутная тема, а очень важная.
PS: для повышения уровня шизофрении здесь не хватает только secure boot, чтобы подписать наш загрузчик grubx64.efi.
Просто положить ядро и initramfs на /dev/vda1 я счёл безыинтересным, так как 100 раз так уже делал. Другие загрузчики типа SHIM, bootctl и прочее не умеют вытворять подобного(ну и ли я не в курсе — расскажите в комментах )
к тому же, если не использовать grub, а, к примеру, просто положить ядро придётся положить на открытое место и initramfs(поправьте меня, если я ошибаюсь). И как в этом варианте использовать secure boot? Ну или какой от неё будет толк, если фс открыта и будет можно подменить и ядро и initramfs?
Я примерно понял, как использовать secureboot, по сути эти подписание загрузчика (efi-исполняемого файла) в pki UIFI. Может коряво, но вроде поянил норм.
В моём варианте есть файл grubx64.efi, который мы «подпишем» и вряд ли он изменится(ну или не так часто), а вот если обновится ядро, то как-то заново надо будет secureboot настраивать или?
— До конца не разобрался как secureboot работает, возможно позже добавлю его в статью, когда настрою на ноуте. Но как мне видится, есть только один файл, который является загрузчиком и только его можно подменить, но его же можно и верифицировать через secureboot чтобы избежать подмены.
Поправьте меня, если что не так
Конечно, придётся положить и ядро и initramfs в /boot (хотя повторюсь ниже — не знаю, может есть способы без груба грузить ядро с LUKS, может кто поправит). В параметрах ядра настраивается что нужно и дальше уже всё будет в точности как у вас — пароль при загрузке.
Вы немного путаетесь. Исходим из того, что grub в uefi-загрузке вообще не нужен. Для этого есть же uefi бут-менеджеры, начиная с самого тупого который включен в systemd-boot, он умеет грузить только другие efi-бинарники, например, ядро линукса (если оно efistub, а оно так и есть во многих дистрибах, в т.ч. в арче). И именно он, этот лаунчер, не меняется и подписывается. А так-то понятно уже, что можно в принципе грузить вообще без всего и даже без этого лаунчера, прямо из загрузчика на материнке сразу ядро.
Вы немного путаетесь. Исходим из того, что grub в uefi-загрузке вообще не нужен. Для этого есть же uefi бут-менеджеры, начиная с самого тупого который включен в systemd-boot, он умеет грузить только другие efi-бинарники, например, ядро линукса (если оно efistub, а оно так и есть во многих дистрибах, в т.ч. в арче). И именно он, этот лаунчер, не меняется и подписывается. А так-то понятно уже, что можно в принципе грузить вообще без всего и даже без этого лаунчера, прямо из загрузчика на материнке сразу ядро.
Ну вернее тут видимо нужно ещё уточнение, grubx64.efi это как бы и есть «uefi бут-менеджер», который на самом деле просто efi-версия груба.
ниииииит! grubx64.efi это бинарный файл, efi-приложение, которое тупо запускается, а дальше уже работает… как приложение собсно.
А вот, к примеру, efibootmgr, он чуть более крут, он ( мой любимый приём — поправьте, если не так ) efi-приложением не является, а напрямую взаимодействует с efi, позволяя поменять порядок загрузки, создать порядок и беспорядок)
А вот, к примеру, efibootmgr, он чуть более крут, он ( мой любимый приём — поправьте, если не так ) efi-приложением не является, а напрямую взаимодействует с efi, позволяя поменять порядок загрузки, создать порядок и беспорядок)
Под бут-менеджерами подразумевается тут UEFI boot manager, которыми являются всякие systemd-boot, rEFind, виндовый (не помню как оно там) итд, т.е. efi-приложения которые грузятся непосредственно загрузчиком мат.платы и дальше уже грузят другие efi-бинарники, утилиты всякие, ядро итд.
Ну да, efibootmgr это просто утилита, которая настраивает как раз тот самый uefi-загрузчик на мат.плате, а именно — прописываются пункты меню те которые «в биосе» (т.е. пути на эти самые UEFI boot manager на загрузочном разделе). Обычно туда лезут как раз всякие грубы чтобы прописать на себя запись. Я стараюсь на незнакомых компах это не трогать (детская травма от окирпичивания, раньше это было обычное дело если неправильно покопаться), ставлю просто по дефолтным путям, а дальше в rEFind уже настраиваешь что хочешь. Сейчас вообще просто systemd-boot без изысков.
Ну да, efibootmgr это просто утилита, которая настраивает как раз тот самый uefi-загрузчик на мат.плате, а именно — прописываются пункты меню те которые «в биосе» (т.е. пути на эти самые UEFI boot manager на загрузочном разделе). Обычно туда лезут как раз всякие грубы чтобы прописать на себя запись. Я стараюсь на незнакомых компах это не трогать (детская травма от окирпичивания, раньше это было обычное дело если неправильно покопаться), ставлю просто по дефолтным путям, а дальше в rEFind уже настраиваешь что хочешь. Сейчас вообще просто systemd-boot без изысков.
т.е. чтобы только часть /boot была незашифрована как у вас, а не весь с ядрами)
у меня как раз /boot зашифрован. Разве нет? — доступен только /dev/sda1 fat32, на котором grub-файл и всё, дальше только по парольной фразе
у меня как раз /boot зашифрован. Разве нет? — доступен только /dev/sda1 fat32, на котором grub-файл и всё, дальше только по парольной фразеНу да, я так и сказал (запутал отрицательным оборотом). У вас /boot зашифрован, а часть — нет (/boot/efi).
Да, если вы хотите ядро шифровать, то кроме grub я не знаю как ещё можно грузить, может есть какие-то uefi-лаунчеры, никогда не интересовался, т.к. повторюсь груб в uef как-то лишним кажется, потому у меня и возникает вопрос — стоит ли оно того.
жаль что secure boot упущен, это как раз непростая и местами мутная тема, а очень важная.
Не только мутная и важная, но ещё и опасная для устройства, как это выяснилось. Недавно настраивал следуя инструкциям из статьи и на следующий день обнаружил что suspend2ram (ждущий режим) у меня больше не работает.
Где-то читал о красивейшем трюке — вы создайте ещё один Key для LUKS, и положите его в initramfs, и им же декодируйте диск. Тогда пароля для grub2 хватит. Если с вашим опытом получится впихнуть — будет огненно.
Звучит как оставьте в открытом виде пароль, так удобнее будет вас взломать. Я бы лучше сканером отпечатков во втором запросе открывал.
Так нет, вы кладёте второй ключ к диску внутрь initramfs на зашифрованном разделе, который надо как-то ещё открыть. Конечно, в теории это дополнительная уязвимость, но доступ к нему ещё надо получить изнутри загруженной системы.
Я ещё видел, как прикручивают аппаратные токены к LUKS, и кажется этот этап тоже на Grub не сделаешь, он не умеет так.
красивейший трюк меня просили сделать на прошлой работе. Суть — найти секурный VPS, где потом настроить luks таким же образом, что и описано в системе, но зашить в initramfs мини-образ системы с сетью и ssh-демоном, что использовать ssh для того, чтобы после перезагрузки системы открыть контейнер и загрузить саму систему.
Не хватило времени и желания… пришлось уволиться)
Не хватило времени и желания… пришлось уволиться)
У себя сделал отдельные разделы /boot и / (root) внутри luks-раздела с помощью lvm. После окончания загрузки, /boot и соответствующий ему /dev/mapper уже не нужны, и они не монтируются в системе, так что для того, чтобы вытащить luks-ключ из работающей системы требуется сперва ввести этот самый ключ для монтирования /boot-раздела. Хотя это, скорее всего, излишне. Если у кого-то есть root-доступ к работающей системе (который нужен для того, чтобы распаковать initramfs), то luks-ключ ему, в общем-то, и не нужен уже
Жаль что resume не работает на шифрованной подкачке с включенным secureboot. Пришлось на ноуте отказаться от secureboot и шифрованных разделов.
А как именно на это влияет secureboot? Сам по себе suspend-to-disk вполне можно использовать с LUKS же. При загрузке монтируется шифрованное устройство, поверху LVM, там своп и далее как обычно. Ну или ещё какие-то там способы на том же арчвики были другие, емнип.
https://m.habr.com/post/308032/
Вот тут информация по причине неработоспособности гибернация. Никаких подвижек пока нет. Если я хочу сохранить полный контроль за загрузкой и использую единственную точку входа в виде граба, который даже подписанный может быть скомпрометирован, потому что конфиг то лежит рядом незашифрованый. Ну не засунуть в мой криптоконтейнер закладку, значит засунут в граб скрапер и я не замечу. Единственное решение это каждый раз подписывать ядро и все его модули, но тогда срабатывает патч запрещающий даже с зашифрованной подкачки выходить из гибернации, а каждый раз пересобирать ядро для удаления этого патча, задача неблагодарная. Патч для подписи образа восстановления тоже висит в аналах истории и никто не торопиться его вливать в апстрим. Прошло уже столько лет, а защитить Линукс ноуты с помощью secureboot до сих пор нельзя.
Способ 1. Отключить верификацию модулей ядра
Включённая верификация модулей ядра отключает гибернацию. По умолчанию верификация модулей ядра включается вместе с Secure Boot, однако она от Secure Boot не зависит. Её можно отключить, оставив только Secure Boot.
Собственно, вижу способ, не вижу препятствий. Т.е. достаточно будет только подписать сам загрузчик, а модули ядра особо и незачем будет подписывать, потому как они лежат в криптоконтейнере и всё будет работать. Не?
Если я хочу сохранить полный контроль за загрузкой и использую единственную точку входа в виде граба, который даже подписанный может быть скомпрометирован, потому что конфиг то лежит рядом незашифрованый.
Конфиг какой? /boot/grub/grub.cfg лежит уже внутри криптоконтейнера.
Ну не засунуть в мой криптоконтейнер закладку, значит засунут в граб скрапер и я не замечу.
Ну тут я только один метод могу представить — кто-то нашёл уязвимость в самом luks, secure boot и т.д., что достаточно сложно и надо таком человеку руку пожать просто
Хм, ну вот лежит у меня бинарник в efi разделе, всё остальное зашифровано. Вопрос, какую задачу будет выполнять этот бинарник, если доступа к конфигурации у него нет? Наверно попытается все блочные устройства подключить? А если в конфиге параметр отвечающий за шифрование запрещает расшифровку?
ну, если быть точным, бинарник будет искать все устройства, которые имеют определённый HEADER (TYPE=«crypto_LUKS») и далее спрашивать пароль на открытие этого контейнера.
Вот у меня по статье зашифровано всё и открыт только один файл efi и всё(ну, естественно раздел тоже)
а чёт как-то бессмысленно звучит. Зашифровывать раздел а потом указывать, что надо запрещать расшифровку, так-то оно да, целее будет, согласен.
Вот у меня по статье зашифровано всё и открыт только один файл efi и всё(ну, естественно раздел тоже)
А если в конфиге параметр отвечающий за шифрование запрещает расшифровку?
а чёт как-то бессмысленно звучит. Зашифровывать раздел а потом указывать, что надо запрещать расшифровку, так-то оно да, целее будет, согласен.
А если я ССЗБ и в конфиге запретил luks? Тогда он будет игнорировать мой конфиг что-ли или не будет ничего выполнять(как он узнал до расшифровки контейнера, что в конфиге запрещено расшифровывать)?
что такое ССЗБ? В каком конфиге LUKS? Что значит «запрещать»?
Он это кто? LUKS? GRUB? Ваши вопросы меня… немного смущают. Странные они. Я лучше вместо полемики бесполезной просто расскажу, как оно, на мой взгляд, работает(как я понял)
1. UEFI запускает grubx64.efi
2. Это запущеное приложение ищет по HEAD устройство LUKS, спрашивает у вас пароль ( Grub 2.02~beta2-29 supports reading an encrypted /boot partition. option GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub )
3. Контейнер открывается для самого grub после успешного ввода пароля. Становится доступной содержимое /boot/* (у меня оно там же, где и /)
4. С открытого контейнера с опциями, параметрами загружается ядро, initramfs.
5. На этапе загрузки initramfs, а именно предварительно настроенного хука encrypt второй раз спрашивается пароль уже для системы. Контейнер заново открывается уже для самой системы и вы работаете в ней.
PS. такое ощущение, что тупо троллите.
Тогда он будет игнорировать мой конфиг что-ли или не будет ничего выполнять
Он это кто? LUKS? GRUB? Ваши вопросы меня… немного смущают. Странные они. Я лучше вместо полемики бесполезной просто расскажу, как оно, на мой взгляд, работает(как я понял)
1. UEFI запускает grubx64.efi
2. Это запущеное приложение ищет по HEAD устройство LUKS, спрашивает у вас пароль ( Grub 2.02~beta2-29 supports reading an encrypted /boot partition. option GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub )
3. Контейнер открывается для самого grub после успешного ввода пароля. Становится доступной содержимое /boot/* (у меня оно там же, где и /)
4. С открытого контейнера с опциями, параметрами загружается ядро, initramfs.
5. На этапе загрузки initramfs, а именно предварительно настроенного хука encrypt второй раз спрашивается пароль уже для системы. Контейнер заново открывается уже для самой системы и вы работаете в ней.
PS. такое ощущение, что тупо троллите.
Дискоммуникация просто. Итак после запуска граб, с какого перепуга он будет искать luks? А если у меня кейс без шифрования? А если я указал в конфиге граба GRUB_ENABLE_CRYPTODISK=n как он об этом узнает без расшифровки контейнера? Ссзб — сам себе злобный Буратино, устоявшееся выражение, означающие, что мы сами создали себе такую ситуацию, в которой у нас проблемы.
Лан, не вопрос, просто как-то слог сложноват для понимания.
А вот тут вот самое забавное.
1. Итак, представим, что мы такие всё зашифровали и у нас сейчас в /etc/default/grub GRUB_ENABLE_CRYPTODISK=n, далее мы делаем grub-install /dev/vda и вот, что происходит, ololo.efi генерится заново и т.д.
Потом мы грузимся(пытаемся) и, так как grub не видит конфига он тупо входит в grub-rescue или как там оно называется.
2. Сразу после этого, мы с live-cd заходим, открываем контейнер, бла-бла-бла, заходим в chroot и меняем GRUB_ENABLE_CRYPTODISK=y в /etc/default/grub, далее опять делаем grub-install /dev/vda, и тут получаем уже новый ololo.efi, который уже будет пытаться найти и запросить пароль для расшифровки luks.
Как-то так. Попробуйте, оно так и есть
Т.е. как я понимаю, этот файл *.efi уже немного другой.
В efi вон люди даже тетрис запускают :)
А если у меня кейс без шифрования? А если я указал в конфиге граба GRUB_ENABLE_CRYPTODISK=n как он об этом узнает без расшифровки контейнера?
А вот тут вот самое забавное.
1. Итак, представим, что мы такие всё зашифровали и у нас сейчас в /etc/default/grub GRUB_ENABLE_CRYPTODISK=n, далее мы делаем grub-install /dev/vda и вот, что происходит, ololo.efi генерится заново и т.д.
Потом мы грузимся(пытаемся) и, так как grub не видит конфига он тупо входит в grub-rescue или как там оно называется.
2. Сразу после этого, мы с live-cd заходим, открываем контейнер, бла-бла-бла, заходим в chroot и меняем GRUB_ENABLE_CRYPTODISK=y в /etc/default/grub, далее опять делаем grub-install /dev/vda, и тут получаем уже новый ololo.efi, который уже будет пытаться найти и запросить пароль для расшифровки luks.
Как-то так. Попробуйте, оно так и есть
Т.е. как я понимаю, этот файл *.efi уже немного другой.
В efi вон люди даже тетрис запускают :)
Если вы знаете, то после переконфигурирования не переустанавливать загрузчик в начало диска, да и для efi это не нужно, оно же оперирует последовательностью загрузки из nvram, а файлы для загрузки кладутся на ефи раздел. Ну и бинарник не перекомпилируется для ефи. Суть вопроса в общем то таже, в теории мы в граб рескью свалимся, но как граб узнает можно расшифровывать или нельзя наш контейнер с конфигом для граба в котором этот параметр указан?
ок, давайте разложим для понимания тогда.
У нас есть 3 «инстанции», куда обращается GRUB, записывает и чем оперирует.
1. «последовательность загрузки в nvram». По сути это некая область памяти на мат. плате, где написать «шо и куда и последовательно как»
2. Начало диска — как обратная совместимость с обычной BIOS загрузкой (первые 4** байт, кто-то говорит 512, где-то написано, что до 2 мегабайт может занимать) — не суть
3. /boot/efi — раздел fat32 EFI — туда кладётся исполняемый бинарник — приложение UEFI — совместимое.
Моя догадка в том, что бинарник всё-таки меняется и, собственно он(исполняемый файл EFI, выполняясь, уже имеет инструкцию искать и предлагать расшифровать).
У нас есть 3 «инстанции», куда обращается GRUB, записывает и чем оперирует.
1. «последовательность загрузки в nvram». По сути это некая область памяти на мат. плате, где написать «шо и куда и последовательно как»
2. Начало диска — как обратная совместимость с обычной BIOS загрузкой (первые 4** байт, кто-то говорит 512, где-то написано, что до 2 мегабайт может занимать) — не суть
3. /boot/efi — раздел fat32 EFI — туда кладётся исполняемый бинарник — приложение UEFI — совместимое.
Моя догадка в том, что бинарник всё-таки меняется и, собственно он(исполняемый файл EFI, выполняясь, уже имеет инструкцию искать и предлагать расшифровать).
Ну это мы с вами гадаем, а хочется же научиться, чтобы знать точно. Подождём, может кто ответит.
ну, у меня после такого теста просто нет сомнений, что это действительно так:
к тому же… чего ждать, если можно тупо почитать:
www.gnu.org/software/grub/manual/grub/grub.html
и я думаю, что нет способа «generate additional commands needed to access them during boot» без перекомпиляции этого бинарника.
1. Итак, представим, что мы такие всё зашифровали и у нас сейчас в /etc/default/grub GRUB_ENABLE_CRYPTODISK=n, далее мы делаем grub-install /dev/vda и вот, что происходит, ololo.efi генерится заново и т.д.
Потом мы грузимся(пытаемся) и, так как grub не видит конфига он тупо входит в grub-rescue или как там оно называется.
2. Сразу после этого, мы с live-cd заходим, открываем контейнер, бла-бла-бла, заходим в chroot и меняем GRUB_ENABLE_CRYPTODISK=y в /etc/default/grub, далее опять делаем grub-install /dev/vda, и тут получаем уже новый ololo.efi, который уже будет пытаться найти и запросить пароль для расшифровки luks.
к тому же… чего ждать, если можно тупо почитать:
www.gnu.org/software/grub/manual/grub/grub.html
‘GRUB_ENABLE_CRYPTODISK’
If set to ‘y’, grub-mkconfig and grub-install will check for encrypted disks and generate additional commands needed to access them during boot. Note that in this case unattended boot is not possible because GRUB will wait for passphrase to unlock encrypted container.
и я думаю, что нет способа «generate additional commands needed to access them during boot» без перекомпиляции этого бинарника.
(Хорошая статья, упустил, ещё раз внимательнее покопаю позже.) Ну я там не вижу про неработоспособность. Ну да, есть проблемы, но точно это лучше чем альтернатива в виде «отказаться от secureboot и шифрованных разделов». Или я не понимаю чего-то, зачем и то и то отключать, в крайнем случае можно отключить secureboot только уж. Тем более что разделы шифруются и подавно в основном не от хакеров, а от потерь/краж или от доблестных служб.
Разве grub-mkstandalone не зашивает конфиг в бинарник?
я вот видел пару раз шифрование подкачки. Расскажите мне зачем и почему? т.е. я видел, что бывает так, что система не зашифрована, а swap — зашифрован.
Насколько я помню swap очищается при корректном выключении/перезагрузке системы. Стало быть только стоп виртуалки или выключение по питанию может сохранить данные в swap (т.е. по сути продолжение обычной памяти). Но, так как свопится зачастую всякое, скажем не такое уж и важное, то какова суть шифровать swap без шифрования рута?
PS, ещё помню, что XSPider на вёнды 2000,2003 показывал уязвимость «Неочищаемый раздел подкачки» и советовал в реестре это исправить. Кто знает как это вообще можно использовать для компроментирования удалённой системы?
Насколько я помню swap очищается при корректном выключении/перезагрузке системы. Стало быть только стоп виртуалки или выключение по питанию может сохранить данные в swap (т.е. по сути продолжение обычной памяти). Но, так как свопится зачастую всякое, скажем не такое уж и важное, то какова суть шифровать swap без шифрования рута?
PS, ещё помню, что XSPider на вёнды 2000,2003 показывал уязвимость «Неочищаемый раздел подкачки» и советовал в реестре это исправить. Кто знает как это вообще можно использовать для компроментирования удалённой системы?
Выше я дал ссылку на хорошую статью. Ну и если немного покопаться, то поймёте, что в подкачку скидывается образ восстановления для гибернации (режим suspend-to-disk). Чтобы закладку туда не пихнули и/или ключи шифрования оттуда не вытянули. А шифровать только подкачку это для извращенцев, которые так захотели.
Я делал подобную систему на ZFS. Её git-версия тоже умеет в шифрование.
Я тоже с шифрованием дисков делал интересную штуку. Есть сервак в личном использовании, который содержит разную личную информацию, есть вероятность его физической кражи. Было желание обеспечить шифрование чувствительных данных, но при этом возможны перезагрузки по питанию, и сервер должен был полностью загружаться без участия человека. Вышел из ситуации следующим образом — root оставил незашифрованным (кому нужен мой линукс?), а конфиденциальные данные разместил на шифрованных разделах, которые маунтятся с помощью ключа, который забирается с другой машинки в сети по ssh, она надежно припрятана (это маленькая платка на арме). Таким образом, не зная схемы работы всего этого добра и не найдя машину с ключом, физическая кража дисков не приведет к утечке данных, при этом загрузка системы автономна и не требует ввода паролей.
Может еще расскажете, как TPM заюзать, чтобы не вводить пароль каждый раз?
Пусть и повторюсь, но для чего здесь grub? У вас в наличии уже есть systemd и ядро с efi заголовком!!! Разделы шифруете парольной фразой, stub+kernel+initrd в один подписанный файл, ключ в nvram и… Всё, кроме esp зашифровано, модификация initrd исключена, т.к. подписано ключём, который на шифрованном разделе.
В общем статья — очередной велосипед, да ещё и с квадратными колёсами.
В общем статья — очередной велосипед, да ещё и с квадратными колёсами.
ну, здесь зачастую люди и делятся велосипедами. Вариант имеет место быть и ваш тоже, мне как-то привычнее и удобнее было сделать именно так.
Велосипед с квадратными колёсами едет немного с бОльшим усилием, а тут по «усилиям» — производительности, ресурсам, скорости загрузки вообще ничего не изменится.
Велосипед с квадратными колёсами едет немного с бОльшим усилием, а тут по «усилиям» — производительности, ресурсам, скорости загрузки вообще ничего не изменится.
Делал подобное несколько лет назад, только целью было избежать использование данных при краже устройства (ноутбука). Ядро и рам диск не шифровал, а luks заголовок хранился отдельно на внешнем носителе (флешке). Боязно мне было хранить заголовок с мастер-ключом на том же носителе, хоть и зашифрованный паролем. Для этого пришлось поправить хук «encrypt» и прописать правило для udev.
Включил. Ожидание нужной флешки. Вставил, ввел пароль и вытащил. Удобно. Работает до сих пор.
Включил. Ожидание нужной флешки. Вставил, ввел пароль и вытащил. Удобно. Работает до сих пор.
немножко автоматизации:
timedatectl set-ntp true && timedatectl set-timezone Europe/Moscow &&
parted -s /dev/sda mklabel gpt mkpart efi '0%' '512MB' mkpart crypt 513MB '100%' set 1 esp on set 1 boot on print && \
mkfs.vfat /dev/sda1 && \
cryptsetup -v luksFormat --type luks1 /dev/sda2
cryptsetup luksOpen /dev/sda2 container
pvcreate /dev/mapper/container && \
vgcreate rootvg /dev/mapper/container && \
lvcreate -L6G -n root rootvg && \
mkfs.ext4 -L root /dev/mapper/rootvg-root && \
mount /dev/mapper/rootvg-root /mnt/ && \
mkdir -p /mnt/{home,boot/efi} && \
mount /dev/sda1 /mnt/boot/efi/ && \
sed -i '/yandex/!d' /etc/pacman.d/mirrorlist && \
pacstrap /mnt base base-devel grub dosfstools efibootmgr mtools
genfstab -pU /mnt >> /mnt/etc/fstab && \
cat /mnt/etc/fstab && \
arch-chroot /mnt
sed -i '/yandex/!d' /etc/pacman.d/mirrorlist &&
hwclock --systohc && \
echo luks-test > /etc/hostname && \
passwd root
sed -i 's/^HOOKS.*/HOOKS=(base udev autodetect modconf block keymap encrypt lvm2 resume filesystems keyboard fsck)/' /etc/mkinitcpio.conf && \
grep HOOKS /etc/mkinitcpio.conf && \
mkinitcpio -p linux
echo $(blkid -s UUID /dev/sda2 | awk -F 'UUID=*' '{print $2}' | sed 's/"//g' ) >> /etc/default/grub
nano /etc/default/grub
#GRUB_ENABLE_CRYPTODISK=y
#GRUB_CMDLINE_LINUX=«cryptdevice=UUID=$UUID:container»
cat /etc/default/grub | grep -E 'GRUB_ENABLE_CRYPTODISK|GRUB_CMDLINE_LINUX' && \
grub-install /dev/sda && \
grub-mkconfig -o /boot/grub/grub.cfg && \
echo «container /dev/sda2 none» >> /etc/crypttab
exit
Sign up to leave a comment.
Установка Archlinux c полным шифрованием системы и LVM на LUKS