MAAS: загрузка на фридос для обновления прошивки

Чтобы MAAS был эффективным решением в нашей инфраструктуре, мы требуем, чтобы он тоже мог загружать наши серверы под определенный FreeDOS.img, содержащий инструменты / файлы для обновления прошивки. В настоящее время у нас есть pxeMenu, который также выполняет функцию предоставления нашим серверам ubuntu / preseed. Мы хотим заменить это на MAAS, но нам нужно выяснить, как устанавливать прошивки, которые не могут быть обновлены из коробки с Ubuntu.

Я попытаюсь объяснить, что я сделал, чтобы заставить его работать (хакерски), чтобы кто-то мог предложить лучший (или даже поддерживаемый) способ сделать это. Одна вещь, которую я нахожу, - то, что Maas очень плохо зарегистрирован. В настоящее время я тестирую версию 2.4 в бионическом режиме на машинах KVM, которые ведут себя так, как если бы они были голыми.

Тесты: 1) (TL; DR это не сработало!) Импортирование изображения Freedos в качестве ddraw. maas user boot-resources create name=custom/freedos architecture=amd64/generic content@=/opt/images/freedos.img filetype=ddraw maas user boot-resources import

После импорта я развернул пользовательское изображение. Это pxe загружается правильно на ввод изображения. Кажется, Кертин пытается перенести файл freedos.img на жесткий диск, который, как я полагаю, можно исправить позже. Но после первой перезагрузки он пытается TFTP файла freedos.img, и это не удается. Он пытается получить образ из неправильного каталога (custom / amd64 / ga-18.04 / freedos / no-such-image / boot-kernel ...).

На данный момент мне это не понравилось, поэтому я решил попробовать другой метод.

2) Импортирование как freedos.tgz затем взломало мой путь: Mount loop'd img и распаковал файлы. Затем импортировал его. Файл не будет найден как обычно ... Вот тогда я решил попробовать заставить tftp найти его по правильному пути из консоли сервера. Это (вроде) сработало. Образ начал загружаться, но pxelinux ожидал, что это будет ядро.

Поэтому я решил попробовать следующее, поскольку теперь обратил внимание на ожидаемые пути к файлам:

• В /var/lib/maas/boot-resources/snapshot-20190718-194439/custom/amd64/ создана символическая ссылка ga-18.04 -> generic/.
• В /var/lib/maas/boot-resources/snapshot-20190718-194439/custom/amd64/generic/freedos/ создана символическая ссылка no-such-image -> uploaded/.
• Загрузил ядро ​​freedos (memdisk) и переименовал его boot-kernel.
• Создана символическая ссылка boot-initrd -> root-tgz (для согласованности).

Это тоже не сработало. Ядро остается на Loading boot sector... booting... и ничего не происходит. Поэтому я попытался заменить root-tgz (это freedos.tgz, который MAAS переименовывает) на freedos.img, но также с именем root-tgz и сохранить символическую ссылку на него под названием boot-kernel.

Успех! После завершения загрузки изображения я получил приглашение FreeDOS. Очевидно, что развертывание в MAAS сообщило о сбое (с этим, возможно, я могу жить).

Но затем я попытался очистить старые изображения, которые я импортировал, и после запуска: maas user boot-resource delete <num> я закончил тем, что сломал взлом, поскольку MAAS решил пересоздать снимок.

Мои вопросы: есть ли способы сделать эту работу без такой путаницы? [1 125]