LINUX.ORG.RU

История изменений

Исправление 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-команд.