Systemrescuecd кастомизация

Понадобилось скастомизировать (и кастомизировывать далее по мере обновления офф. образа) сисреск. Процедура вполне понятна и проста, но крайне неудобна:

Распаковка и «управление» кастомизацией как бы должны производиться из-под загруженного сисреска (что подразумевает загрузку в виртуалке), а собственно работа с файлами, разумеется, будет удобнее с хоста. Однако способа распаковывать из-под виртуалки так, чтобы это непосредственно отображалось на ФС хоста, я не нашел.

Для виртуализации я использую Virtialbox, потому как удобнее это на хосте (можно qemu/kvm, но разницы в отношении проблематики я не вижу). Единственный годный и простой способ – монтировать внутри виртуалки штатную шару Virtialbox, недоступен ввиду отсутствия поддержки Virtialbox в сисреске.

Были попробованы (или обдуманы) следующие альтернативы:
1. монтирование самба шары. не катит, permission denied. логично, скрипт распаковки должен иметь возможность управлять ими вплоть до uid=0
2. предлагается (упоминается в офф руководстве) использовать nfs, но хз, для начала см. выше, а далее – разворачивать nfs сервер только для одной задачи? оверкилл.
3. попробовал .qed образ и монтирование его с помощью qemu-nbd. как бы должно работать, однако на практике оказывается, что можно без проблем (в смысле без сообщений об ошибках) смонтировать образ и в виртуалку и через qemu-nbd одновременно, проблемы начинаются после – образ разрушается. логично конечно, но вручную следить за тем, чтобы оно то было смонтировано то нет – муторно.
4. решения а-ля «образ ФС в файле» вероятно будет страдать как в п.3. да и выгоды особой нет, все равно это тоже муторно.
5. работать через ssh c виртуалкой – тоже неудобняк, ибо надо настраивать dhcp для виртуалки, и потом каждый раз после ребута passwd или в параметрах ядра это прописывать. known_hosts опять же будет ругаться.

в общем, хотелось бы простой альтернативы штатной шаре virtualbox в терминах доступности из-под сисреска.