Hi Wouter,
On Mon, May 29, 2023 at 02:20:09PM +0200, Wouter Verhelst wrote:
> I am exploring the possibility to write an autopkgtest for the initramfs
> stuff that I wrote for nbd-client.
Please see my other mail regarding the use of debvm in autopkgtests.
Let's not duplicate that topic here. I note that this fully applies in
the exact way to the projected use of mmdebstrap below.
> In order to do so, I want to run a client VM that has no root hard disk
> configured, but is configured to attempt to mount the VM image over the
> network, using NBD. This is accomplished by way of a few kernel command
> line parameters.
>
> I tried running
>
> debvm-run -- -append 'nbdroot=192.168.88.103,root_export,nbd0'
May I suggest that this is a quite unusual use case and that debvm may
not be the right hammer for your job? While debvm gives you a complete
rootfs, you seem to be satisfied with a kernel an an initrd. How about
peeking at debvm's source and extracting the useful bits from it? In
effect you can skip much of what debvm does and construct a manageable
mmdebstrap invocation directly. The following draft is entirely
untested:
mmdebstrap \
--variant=apt \
unstable \
/dev/null \
--include=linux-image-"$(dpkg --print-architecture)" \
--customize-hook="download /initrd ./initrd" \
--customize-hook="download /vmlinuz ./vmlinuz"
> I would like to see an option to tell debvm-run not to mount the
> filesystem image but to let the user handle that. However, the
> extracting of the kernel and initramfs which debvm-run does would still
> be necessary; it's just that I want to fiddle with how we get to the
> filesystem.
Given the images, I think you can pass them to qemu directly. Do you
agree that for this use case, using the underlying tools directly does a
better job?
Helmut
