Комментарии 20
Напомнило Gentoo Handbook, в Gentoo это вообще штатный способ установки системы.
В NetBSD это не штатный способ, но, поскольку инсталлятор почему-то моей существующей таблицей разделов давится, ставил ее просто созданием ФС, распаковкой сетов, правкой пары конфигов и конфига GRUB (из линупса) для загрузки нетки.
debootstrap накатывает эквивалент гентушного Stage 3 и тоже является полуштатным способом установки (debian-installer просто ещё и всю «магию» из статьи включает).
Какую проблему кастомизируемости удалось решить таким образом? Чем это отличается от штатного инсталлера?
Если цель EFI, да еще и в виртуалке, то зачем grub?
Если цель EFI, да еще и в виртуалке, то зачем grub?
1. Нужно было ставить без ISO образа и разные версии.
2. Нужна была возможность это всё автоматизировать и заскриптовать. Штатный инсталлер интерактивный, ставит не те ядра, ставит много лишнего и заметно сложнее интегрировать со своими скриптами.
3. Все существующие популярные мануалы немного устарели и требуют активного гугления и экспериментов.
GRUB проще всего контролировать. А вы бы что использовали?
Ну, и на реальном сервере тоже GRUB, а мне нужно всякие магические скрипты отлаживать.
2. Нужна была возможность это всё автоматизировать и заскриптовать. Штатный инсталлер интерактивный, ставит не те ядра, ставит много лишнего и заметно сложнее интегрировать со своими скриптами.
3. Все существующие популярные мануалы немного устарели и требуют активного гугления и экспериментов.
GRUB проще всего контролировать. А вы бы что использовали?
Ну, и на реальном сервере тоже GRUB, а мне нужно всякие магические скрипты отлаживать.
systemd-boot (gummyboot в девичестве) позволяет складывать ядра в EFI/Linux и загружаться с шифрованных дисков и чужих фс не требуя их поддержки в grub.
Но надо будет запретить установку grub в apt и написать обвязку, делающую из ядра и initrd efi-image.
Ну, блин, офигеть замена :) А зачем?
Не говоря уже о том, что EFI загрузчик GRUBа подписан и совместим с SecureBoot.
Не говоря уже о том, что EFI загрузчик GRUBа подписан и совместим с SecureBoot.
Чтобы не писать по каждому чиху в efivars.
Secureboot, в котором вы не управляете своими ключами, не подписываете и не верифицируете каждый загружаемый модуль и конфиг (сколько их в грабе, навскидку?) — всего лишь фиговый листочек, стыдливо прикрывающий что-то там в безопасности.
Подробнее можно посмотреть у CodeRush, кажется.
А не нужно туда писать. Если система одна, то просто ставьте загрузчик по умолчанию. GRUB и сам это делает.
С SecureBoot вопрос не с безопасностью, а с совместимостью с новыми BIOS. У меня уже две машины есть, которые стабильно работают только с SecureBoot. У одной BIOS при загрузке сам по себе периодически начинает ругаться и давать полезные советы о том, как хорошо жить с SecureBoot, и отключить этого нельзя. А вторая и вовсе отказывается грузиться без SecureBoot и предлагает связаться с производителем (а там нонейм какой-то).
В общем не безопасности ради и не от хорошей жизни :)
С SecureBoot вопрос не с безопасностью, а с совместимостью с новыми BIOS. У меня уже две машины есть, которые стабильно работают только с SecureBoot. У одной BIOS при загрузке сам по себе периодически начинает ругаться и давать полезные советы о том, как хорошо жить с SecureBoot, и отключить этого нельзя. А вторая и вовсе отказывается грузиться без SecureBoot и предлагает связаться с производителем (а там нонейм какой-то).
В общем не безопасности ради и не от хорошей жизни :)
почему-то mkfs.vfat при установке arch под virtualbox eufi на диск с gpt проблем у меня никогда не вызывало. размер раздела 512мб
Да, я тоже не раз автоматом делал и работало. А, вот, на текущем VirtalBox отказалось. Его EFI просто считал, что раздел неформатирован.
версия 6.1.18 полет нормальный
Ну, тем не менее, при маленьком размере раздела (буквально десятки мегабайт), после рекомендуемого во всех мауналах «mkfs.vfat -F32» EFI BIOS VirtualBox считает, что раздел не форматирован. Кучу времени убил, пока понял это. В чём именно затык пока не разбирался, но есть ощущение, что что-то с минимальным размером раздела.
Подзреваю, всё дело в том, что майкрософтовский документ, описывающий FAT, утверждает примерно следующее: если количество кластеров помещается в 12 битов, то FAT12, если помещается в 16, то FAT16, а FAT32 — только в случае, если не влез в 16 битов.
Иными словами, при размере кластера 512 байтов (один сектор) раздел должен быть (примерно) больше 32Мб, чтобы его можно было форматировать в FAT32. Ну а если размер кластера составляет несколько секторов, то кратно увеличивается минимальный размер раздела, который можно форматировать в FAT32.
Иными словами, при размере кластера 512 байтов (один сектор) раздел должен быть (примерно) больше 32Мб, чтобы его можно было форматировать в FAT32. Ну а если размер кластера составляет несколько секторов, то кратно увеличивается минимальный размер раздела, который можно форматировать в FAT32.
У меня, кстати, вопрос к уважаемому сообществу.
А есть какой-то способ более удобного написания статей на Хабре?
Этот редактор — просто форменное издевательство! И это на ресурсе для IT-профессионалов!
Абзацы удаляются, фокус скачет, Ctrl+C/Ctrl+V приводит к удивительным результатам и т.п.
Можно как-то загрузить уже готовый markdown текст или что-то подобное?
А есть какой-то способ более удобного написания статей на Хабре?
Этот редактор — просто форменное издевательство! И это на ресурсе для IT-профессионалов!
Абзацы удаляются, фокус скачет, Ctrl+C/Ctrl+V приводит к удивительным результатам и т.п.
Можно как-то загрузить уже готовый markdown текст или что-то подобное?
Если не ошибаюсь, тут еще должны быть настройки fstab...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ставим Ubuntu из другого Linux/LiveCD