Разворачивал новую машинку для домашнего Xen’а – в конфиге заметил новый для себя параметр – bootloader=pygrub. Заинтересовался; собирать ядра для практически не используемого домашнего сервера мне давно уже лень, а как грузить ядро изнутри domU было неизвестно. До сих пор.
Итак. Да, оно таки может загрузить установленное внутри domU ядро. Перевел несколько domU на “внутреннее ядро” – косяки и заметки, которые при этом получились:
- Убираем из /etc/xen/*.cfg kernel и initrd
- Вписываем bootloader = ‘pygrub’
- В DomU ставим:
apt-get install linux-image-amd64 grub-legacy --no-install-recommends
grub-install /dev/xvda1
update-grub
grub-install
создает каталог /boot/grub – ну и делает прочие нужные вещи. update-grub
генерирует /boot/grub/menu.lst
. Тут есть косяк: на Debian 11 (а на многих хостах у меня был именно он) он отрабатывает криво. В итоге в качестве root для записей в меню указан (hostdisk//dev/xvda1) – при этом система не может загрузиться: ругается на “Unable to find partition containing kernel”. Сравнив свежесозданную машину и старые, увидел, что в новой идет более привычный (hd0,0). Заменил – все заработало. Поэтому при update-grub на старых машинах дополнительно выполняем:
sed -i 's@hostdisk//dev/xvda1@hd0,0@g' /boot/grub/menu.lst
Пару машин обновил до Debian 12, там update-grub выполняется корректно и ничего править не надо.
Память. Да, тут очень много факторов и это сложно назвать прямым сравнением, но все же. Старое ядро – 4.9.161 без initrd (все в одном файлике, который лежит снаружи domU и просто указан в конфиг-файле domU как kernel). Новое – 5.10.0-26-amd64 для Debian 11 + initrd впридачу. На машинке, где было прописано 256 МБ для хоста – в первом случае оставалось 238, во втором – только 203. Ощутимая разница.
И еще момент по памяти – частично как следствие предыдущего пункта. На некоторых хостах было выделено 192 МБ памяти. Нормально поставить пакет с ядром даже не удалось – был вылет из-за OOM на генерации и распаковке (при загрузке) initrd. Добавил до 256 – не помогло. Только после установки 384 МБ все прошло успешно. Проблема – на сейчас при дефолтном конфиге initrd получается ну очень большим – порядка 30 МБ. Для современных алгоритмов компрессии под это требуется уже ощутимый объем памяти. В итоге памяти не хватало, система не могла распаковать initrd и циклически перезагружалась. Фикс – правим /etc/initramfs-tools/initramfs.conf и ставим MODULES=dep, потом
update-initramfs -k all -u
Ну или для простоты:
sed -i '/MODULES=/s/MODULES=.*/MODULES=dep/g' /etc/initramfs-tools/initramfs.conf && update-initramfs -k all -u
Сейчас initrd занимает 6-7 МБ. Сравнение занимаемой им при старте памяти:
Для дефолта:
[ 17.185149] Freeing initrd memory: 101764K
При MODULES=dep:
[ 18.404971] Freeing initrd memory: 13024K
Т.е., в целом, если памяти хватает, то можно и оставить как есть. Минус – дольше загрузка (особенно на старых системах) и больше занятое место. Но если не планируется грузить систему на разном железе (а для domU в Xen это неактуально) – то можно сделать оптимизацию.
Update: забыл дополнить: в процессе выяснилось, что pygrub в процессе запуска размещает ядро и initrd в /var/run/xen/pygrub/ для запуска машины.
https://wiki.xenproject.org/wiki/Booting_Overview