Comments 37
Но зачем? ;)
Тоже самое как LFS скриптом собирать, никакого удовольствия.
Интереснее собрать gentoo в chroote по взрослому, потом на живой системе заменить корень на новую систему и ядро. С ораклом это довольно безопасно, у них терминал по типу kvm есть, хотя бы можно будет увидеть в чём косяк, если с ядром накосячить.
Интереснее собрать gentoo в chroote по взрослому, потом на живой системе заменить корень на новую систему и ядро. С ораклом это довольно безопасно, у них терминал по типу kvm есть, хотя бы можно будет увидеть в чём косяк, если с ядром накосячить.
можно ссылку на этот терминал? ищу и никак не найду
Я думал о таком, но к сожалению у этой виртуалки слишком мало памяти, чтобы провернуть подобное если строить новый корень в tmpfs. Или вы предлагаете откусить кусок диска и строить новый корень там?
Ничего не надо откусывать и никакой tmpfs. Gentoo классическим путём устанавливается — распаковка stage3 в каталог, chroot, минимальная настройка — make.conf, профиль, локализация, fstab (можно подглядывать в «оригинальный»), пользователь. Дальше ядро, можно попробовать бинарное (в Gentoo теперь так можно), а можно и собрать по конфигу из оригинальной системы. А ещё лучше оригинальное оставить, никакого профита от своего ядра не будет, по идее в нём есть всё что нужно.
А теперь самое интересное, в оригинальной системе гасим все сервисы (если что-то успели запустить), кроме своей ssh-сессии, и начинаем потихоньку, по каталогам (удаляем каталог и копируем), заменять корень на новый из каталога с Gentoo, например используя mc. Последними меняем /bin, /sbin. И перезагружаемся.
Что может пойти не так? Только игры с ядром, если всё-таки собирали своё есть совсем ненулевая вероятность, что что-нибудь важное не включено.
А теперь самое интересное, в оригинальной системе гасим все сервисы (если что-то успели запустить), кроме своей ssh-сессии, и начинаем потихоньку, по каталогам (удаляем каталог и копируем), заменять корень на новый из каталога с Gentoo, например используя mc. Последними меняем /bin, /sbin. И перезагружаемся.
Что может пойти не так? Только игры с ядром, если всё-таки собирали своё есть совсем ненулевая вероятность, что что-нибудь важное не включено.
Исходно скрипт to-gentoo именно это и делал: распаковывал stage3 в новый корень, монтировал туда /proc, /dev итд, выполнял там всю настройку и после этого копировал все в старый корень. Посмотрев на это мне показалось, что шаг с chroot лишний. Попробовал — и все сработало как надо. Можно попросить вас уточнить почему подход с chroot лучше подхода без него?
но команда reboot не поможета не пробовали systemctl reboot?
Подскажите как в oracle cloud создать вторую машину — копию первой?
docs.oracle.com/en-us/iaas/Content/Block/Tasks/cloningabootvolume.htm
как я понимаю, с этого клона можно создать новый инстанс (раздел «Next Steps»)
в отличие от бэкапа, который можно лишь подключить к другому инстансу в качестве несистемного диска
как я понимаю, с этого клона можно создать новый инстанс (раздел «Next Steps»)
в отличие от бэкапа, который можно лишь подключить к другому инстансу в качестве несистемного диска
Я не планирую использовать на этой машине systemd, так что маскирую его и udev:
Что бы что?
Маскировка sytemd нужна, чтобы он не был установлен как зависимость другого пакета.
Я имел ввиду, с какой целью надо отказываться от systemd?
О, это персональный выбор конкретно для этого проекта. Разумеется, можно не маскировать systemd если он предпочтителен для ваших задач.
Меня просто всегда интересовало, отчего люди отказываются от, как минимум, неплохих инструментов.
Это вы сейчас про какой инструмент, runinit, openrc, sysvinit, upstart?
Вы затрагиваете очень холиварную тему. В интернете можно найти много материалов с критикой systemd. Причин не использовать его достаточно много.
Я откзался от systemd потому, что мне хотелось минималистическую систему, которая была бы проста для понимания. systemd тянет за собой слишком много зависимостей, так что использующую его систему сложно назвать минималистичной. Лично мне проще разобраться в скриптах openrc, чем в случае каких-то вопросов смотреть в исходники systemd.
Я откзался от systemd потому, что мне хотелось минималистическую систему, которая была бы проста для понимания. systemd тянет за собой слишком много зависимостей, так что использующую его систему сложно назвать минималистичной. Лично мне проще разобраться в скриптах openrc, чем в случае каких-то вопросов смотреть в исходники systemd.
Основа systemd, это сам демон
systemd, journald и udevd. Все остальные части systemd, так или иначе, можно менять (например на большинстве десктопных дистрибутивов вместо штатных networkd и resolved используется NetworkManager), хотя как по мне, лучше просто почитать маны, тем более что по качеству, систематизации и подачи материала редко какие маны можно с ними сравнить. А головняка systemd снимает очень много.Вот список зависимостей systemd в gentoo.
rm /etc/resolv.conf && echo 'nameserver 8.8.8.8' > /etc/resolv.confМожет придирка, но зачем rm /etc/resolv.conf?
Потому что ubuntu 20.04 использует systemd-resolved и /etc/resolv.conf это симлинка на /run/systemd/resolve/stub-resolv.conf После перезагрузки этот файл не будет найден, что создаст проблемы для dhcp скрипта.
А чего бы просто не запустить новое ядро с initrd с помощью kexec, таким образом отвалившись от ФС и взяв под контроль всю машину сразу? ;)
Sign up to leave a comment.
Oracle cloud: превращаем ubuntu 20.04 в gentoo