История изменений
Исправление
Spoofing,
(текущая версия)
:
спасибо, а вы случайно не сталкивались с проблемой загрузки больших initrd образов на железе из bios/uefi?
по началу когда разрабатывал booty, тоже думал initrd хватит всем (ц), потом оказалось что не на всех компьютерах возможно загрузиться в большой initrd. столкнулся с проблемой на AM4 на плате gigabyte ab350m-ds3h v2, при этом с той же флешки тот-же образ прекрасно загружается на FM2 сокете и на LGA 1151-v2 (H110).
ну в итоге пришлось допиливать ещё создание ISO образов и загрузочных носителей, чтобы загрузчики умели находить vmlinuz/initrd, писать навороченный init чтобы тот тоже смог найти образы систем на насителе (флешке) и уже в них загрузиться.
а не просто загрузился в initrd и либо получил систему в стадии initramfs, либо сделал switch_root, увы, это не сработает. кстати стадия initramfs это отдельная сущность скажем так, и после того как ты загрузился в систему, сделать switch_root ещё раз мне уже не удалось. система просто зависла. возможно init pid=1 не даёт, не знаю. не суть.
ну когда ты делаешь kexec -e, то проблем таких нет, можешь хоть 5гб засунуть в initrd, я так думаю это скорее особенность биосов, что у них стоит ограничение на загрузку образов. при чём у всех всё по-разному. опытным путём выяснил, что это около 512мб на моём гнилобайте.
ну декларалататилаварнававая конфигурация это конечно здорово, только вот users.users.root.openssh.authorizedKeys.keys
такие вещи надо знать. в то время как на баш портянке любая домохозяйка знает, что надо сделать cat ~/.ssh/*.pub > rootfs/root/.ssh/authorized_keys
.
пожалуй это единственный недостаток такого подхода с файлом конфигурации, который кем-то придуман и синтаксис строго ограничен. больше, чем умеет сам shell, ты всё равно не реализуешь. поэтому имеет смысл сразу придерживаться shell-команд.
networking.interfaces.ens3.useDHCP
ens3
ооо сколько боли предвкушаю я. :D установи лишний девайс и получи сломанную «прошивку».
Исходная версия
Spoofing,
:
спасибо, а вы случайно не сталкивались с проблемой загрузки больших initrd образов на железе из bios/uefi?
по началу когда разрабатывал booty, тоже думал initrd хватит всем (ц), потом оказалось что не на всех компьютерах возможно загрузиться в большой initrd. столкнулся с проблемой на AM4 на плате gigabyte ab350m-ds3h v2, при этом с той же флешки тот-же образ прекрасно загружается на FM2 сокете и на LGA 1151-v2 (H110).
ну в итоге пришлось допиливать ещё создание ISO образов и загрузочных носителей, чтобы загрузчики умели находить vmlinuz/initrd, писать навороченный init чтобы тот тоже смог найти образы систем на насителе (флешке) и уже в них загрузиться.
а не просто загрузился в initrd и либо получил систему в стадии initramfs, либо сделал switch_root, увы, это не сработает. кстати стадия initramfs это отдельная сущность скажем так, и после того как ты загрузился в систему, сделать switch_root ещё раз мне уже не удалось. система просто зависла. возможно init pid=1 не даёт, не знаю. не суть.
ну когда ты делаешь kexec -e, то проблем таких нет, можешь хоть 5гб засунуть в initrd, я так думаю это скорее особенность биосов, что у них стоит ограничение на загрузку образов. при чём у всех всё по-разному. опытным путём выяснил, что это около 512мб на моём гнилобайте.
ну декларалататилаварнававая конфигурация это конечно здорово, только вот users.users.root.openssh.authorizedKeys.keys
такие вещи надо знать. в то время как на баш портянке любая домохозяйка знает, что надо сделать cat ~/.ssh/*.pub > rootfs/root/.ssh/authorized_keys
.
пожалуй это единственный недостаток такого подхода с файлом конфигурации, который кем-то придуман и синтаксис строго ограничен. больше, чем умеет сам shell, ты всё равно не реализуешь. поэтому имеет смысл сразу придерживаться shell-команд.